Hello!
Now, I am trying to save data from multiple USRPs.
Even though there is a file "rx_multi_samples.exe", as you know, it does
not provide saving data.
Is there anyone who can let me know how to deal with this problem?
--
*Kwansik Park*
School of Integrated Technology, Yonsei University
Yons
On 09/21/2018 12:12 AM, Chintan Patel wrote:
Marcus,
Thanks. So, if I have the right PCIe driver and setup, can I use the
X310 without GigE port being connected? In other words, when using
PCIe is both the data and control plane carried over PCIe?
Thanks
Chintan
Yes, absolutely.
On Thu,
Hey Leo,
Glad to hear you were able to work things out. One quick note about the
code I attached previously. Located a minor typo/bug that you'll want to
fix if you want to actually transmit useful data.
> 219 radio_ctrl->set_rx_frequency(freq, radio_chan);
>
should be:
> 219 radi
On 09/20/2018 06:00 PM, Yun Li wrote:
Hi Marcus,
My code is like this:
uhd::stream_args_t stream_args("fc32"); //complex floats
stream_args.channels = { 1, 3 }; // vector of channel ids
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
...
In this case, can I expect the stre
Hi Marcus,
My code is like this:
uhd::stream_args_t stream_args("fc32"); //complex floats
stream_args.channels = { 1, 3 }; // vector of channel ids
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
...
In this case, can I expect the streaming channel index 0/1 in UDP packet
co
On 09/20/2018 04:14 PM, Yun Li wrote:
Hi Marcus,
Thanks for the clarification. We do have a need to map the streaming
channel index back to the channel id. Is there a fixed mapping
formula? For example, if we are streaming channel 1 and 3, then 0 in
the UDP means channel 1 and 1 in the UDP me
Hi Marcus,
Thanks for the clarification. We do have a need to map the streaming
channel index back to the channel id. Is there a fixed mapping formula? For
example, if we are streaming channel 1 and 3, then 0 in the UDP means
channel 1 and 1 in the UDP means channel 3 and so forth?
Thanks.
Yun
On 09/20/2018 03:26 PM, Chintan Patel via USRP-users wrote:
Hello,
Some high-level questions on the X310 architecture and implementation
related to the GigE/PCIe support.
The X310 allows host connectivity using 10G or PCIe connections. Is it
implied that if the Ethernet interfaces are being
On 09/20/2018 03:58 PM, Yun Li via USRP-users wrote:
Hi there,
We are capturing UDP packets while streaming multiple channels (RX
channel 1 and 3 in particular) from N310 (UHD_3.13.0.2-1-g78745bda).
Looking at UDP packets, it seems that the channel id field in the VRT
header is actually set t
Hi there,
We are capturing UDP packets while streaming multiple channels (RX channel
1 and 3 in particular) from N310 (UHD_3.13.0.2-1-g78745bda). Looking at UDP
packets, it seems that the channel id field in the VRT header is actually
set to 0 and 1. I expect the value would be 1 and 3. Is there a
Hello,
Some high-level questions on the X310 architecture and implementation
related to the GigE/PCIe support.
The X310 allows host connectivity using 10G or PCIe connections. Is it
implied that if the Ethernet interfaces are being used to connect to the
host, the PCIe is not being used? In the F
Rather than a try/catch block, I just changed my code from
usrp->set_time_source(val,mboard);
to
if (usrp->get_time_source(mboard)!=val)
usrp->set_time_source(val,mboard);
This seems to handle it for me. I also did the same for
usrp->set_clock_source() because I was experiencing some long d
Yes. I can do that.
On Thu, Sep 20, 2018 at 12:14 PM Michael West
wrote:
> Hi Rob,
>
> Thanks for letting us know. We will look into that. It is hard to tell
> from the error if MPM is doing the work and the RPC call is just timing out
> or it is failing to execute in MPM altogether. We will
Hi Rob,
Thanks for letting us know. We will look into that. It is hard to tell
from the error if MPM is doing the work and the RPC call is just timing out
or it is failing to execute in MPM altogether. We will try to reproduce it
and see what is going on. In the meantime, is it possible for yo
With the latest 3.13 release and the N310, I get an exception when calling
usrp->set_time_source(). It seems that this should just be a warning (or
nothing at all if the requested source is equal to the current source). I
realize that with the N310, it is necessary to set the time source in the
a
Hey Ryan,
Thanks a lot! I actually ended up doing pretty much the exact same things
you described, and came up with a piece of code very similar to yours.
Yours is neater though, so I will keep it ;-).
Regards,
Leo
On Wed, Sep 19, 2018 at 7:52 PM Ryan Marlow wrote:
> Hey Leo,
> I haven't seen
I sent this email out a little prematurely.
The stock software works fine with the non-RFNoC flowgraph I have.
Some difference are:
Stock
gnuradio-config-info -v =
3.7.13.4
uhd_usrp_probe = [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400;
UHD_3.11.0.1-0-unknown
My cross-compile
gnu
I have a cross-compile setup for my E312 that is working fine. If I run a
benchmark_rate using my compiled UHD and bitfile, it works as intended. I see
about 10MHz throughput from the FPGA to the ARM before I start dropping
samples, that is about right based on my readings.
Now, if I use all
18 matches
Mail list logo
