Hi Sylvain,
Thank you for your help! It solved my problem.
Just for curiosity:
The .bit-file is exactly the same as the .bin-file, except that the
.bit-file has an additional header, right? In my case (Vivado 2017.04),
the header of the .bit-file is 124 Bytes while the uhd_image_loader
assume
Hi,
> Just for curiosity:
> The .bit-file is exactly the same as the .bin-file, except that the
> .bit-file has an additional header, right? In my case (Vivado 2017.04),
> the header of the .bit-file is 124 Bytes while the uhd_image_loader
> assumes a header size of 116 Bytes. Depends this header
Hi,
> Brian, I really only want to send data when appropriate. I don't have the
> code in front if me at the moment, but I can have tvalid high while I wait
> for tready, right.
Actually tvalid high with tready low is completey expected. Because
you CANNOT have tvalid depend on the status of tr
Hi
We have a Setup with single x310 and 2 twinrx
We use Ubuntu 16.04
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.0.1-0-ga1b5c4ae
We have an Rx application
We sync all channels(ch0-3) to ch0 lo.
We use internal clock 1pps
We are trying to sample 4 channels,
each time for a defin
Martin, Michael,
Sorry for the long delay in responding. I hadn't been monitoring the
user's list this past week and the replies you sent did not come directly
to my inbox. In any event, I compiled the latest MPM and it seems to work
fine. Thank you.
Now, to the secondary issue I mentioned in t
Hi all,
I was trying this loopback trick (
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/). In step 2, I
did radio_ctrl->set_rx_streamer(true, 0) in UHD. (0/Radio_0 is my RX radio,
which radio_ctrl points to.)
In step 3, a steam_cmd is issued to the RX radio. But, what streamer_args
do
Hi Rob,
Excellent feedback as always. Thank you. We will look into the RX burst
behavior using STREAM_MODE_START_CONTINUOUS, but it may take some time.
The flush routine should have a timeout for the recv() call and be looking
for md.end_of_burst to exit, but I'm sure there is more to the issue
Thanks Michael,
Are you saying that when running with STREAM_MODE_START_CONTINUOUS, I can
expect a "md.end_of_burst==true" shortly after issuing the
STREAM_MODE_STOP_CONTINUOUS? If so, that seems like a much better method
for flushing all of the samples following the stop command.
In any event, I