On 03/14/2018 02:45 AM, Brandon Piner via USRP-users wrote:
I have found that it starts happening with low sample rates around 2
Msps and then stops overflowing. It happens all the time with higher
sample rates.
I tried to rule out my code from this by having it run in a thread
that just reads from the device and then discards the data afterwards.
What happens with one of the example apps, like rx_samples_to_file,
writing to /dev/null ?
On 2018-03-08 17:42, Marcus D. Leech via USRP-users wrote:
On 03/08/2018 08:33 AM, Brandon Piner via USRP-users wrote:
To whom it may concern
I have been implementing a transmitter and receiver application
using the B200 mini with UHD-3.9.7. The transmitter seems to be
working well. The strange behavior seems to be happening when I try
using the receiver.
1. The predominant issue I am having is that I keep getting an
overflow after X samples were read. The specific number of
samples ("X") before an overflow seems to be linked to the
samples per packet "spp" or the "receive_frame_size" parameter.
If I leave the "spp" and "receive_frame_size" as default then it
seems that the max samples per buffer per packet is 2044. So
each ->recv of samples returns 2044 samples. I can call ->recv
30 times and 2044 samples are returned. On the 31st time calling
->recv I only 389 samples along with some timestamp mismatch of
approx 65 uS. The 32nd read flags an overflow and 0 samples are
read. This "cycle" reads 61709 samples in total. Seems like it
is filling a flat buffer and not a circular buffer. Is this the
expected behavior of the device? How can I get it to not overflow?
Is the above sample-rate linked, or does it happen regardless? If it
happens regardless, then I suspect that you have an
off-by-some-amount error
somewhere in your code that is causing buffers to become
exhausted--you're not vacuuming out all available data.
1.
2. The other issue is with starting up a receive stream. I
documented it here
https://github.com/EttusResearch/uhd/issues/68#issuecomment-369596794
. Not sure if anyone can assist with that. My current workaround
is to destroy the entire sptr to the USRP and create a new
pointer at the time that I start the receive stream.
Hope someone can provide me with some insight!
Kind regards
Brandon
------------------------------------------------------------------------
Disclaimer: http://www.peralex.com/disclaimer.html
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------------------------------------------------
Disclaimer: http://www.peralex.com/disclaimer.html
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
