On 24/02/2023 03:40, Peter Featherstone (XENINT) wrote:
Hi Marcus,
/To clarify. You are in a loop, reading exactly 16K of data, then
going to sleep for 5 seconds, and you have a
STREAM_MODE_START_CONTINUOUS stream?///
Exactly that.
So do you reckon it’s possible to get no OVERFLOW errors in this
situation?
I have to admit, after a while, the overflow messages start coming in,
but it takes like 40 seconds. I can’t imagine the internal buffers are
that big, but I could be wrong. Is there a way to set the internal
buffer sizes?
Is there a way to manually provide buffers to the underlying
transport? Rather than libuhd do its own internal buffering and users
not really knowing how big they are or when they overflow, we could
manually provide a buffer and have a callback notification when it’s
full. Maybe there could be a set of buffers provided, a bit like how
libiio works.
(Or even better, use C++ Asio style API. All buffers are manually
provided, and users know where they stand. It looks like libuhd uses
asio under the hood anyway. May as well use it for the API too. Then
you can use all of Asio super powers without any extra work, like
coroutines, futures, callbacks, etc. Anyway, that’s a tangent.)
I appreciate the help and the clarifications.
Thanks,
TBH, given that the architecture is driven by "zero copy as much as
possible", I'm not sure how that interacts with the
user-provided buffer, and that you appear to be able to accumulate a
LOT of samples before overrun occurs.
Changing the API at this point, 16+ years on, with thousands of deployed
applications in the field is unlikely to happen.
Peter
*From:*Marcus D. Leech <[email protected]>
*Sent:* 23 February 2023 17:21
*To:* Peter Featherstone (XENINT) <[email protected]>
*Subject:* Re: [USRP-users] Re: libuhd - read IQ samples without
discontinuities
On 23/02/2023 10:42, Peter Featherstone (XENINT) wrote:
HI,
No I want to receive continuously without gaps.
However, I have a suspicion that sometimes you don’t get OVERFLOW
errors when you should.
My thought was that if I stream in continuous mode and don’t get
any overflow messages, then all my received IQ would be continuous.
However, I did an experiment where I artificially added sleep
statements to force overflows, but they don’t happen. I wait for
5s at 1 MHz sample rate, therefore 5 million samples should have
overflowed, but I get no messages.
So I’m questioning whether this mode of streaming actually
guarantees continuous receive.
peter
My problem is that I don’t get any OVERFLOW errors
To clarify. You are in a loop, reading exactly 16K of data, then
going to sleep for 5 seconds, and you have a
STREAM_MODE_START_CONTINUOUS stream?
Parts of UHD run asynchronously in a separate thread, and there's a
large buffer pool available to the reader thread.
HOWEVER, if you're only reading 16K, those buffers would get blown
out fairly quickly.
MY experience is that B210 delivers uninterrupted data in continuous
streaming, and when it can't, it declares an
OVERFLOW, and prints an "O" on the console. But there can be an
awful lot of data "in flight". The architecture
isn't a polling architecture, per se, so when you issue a recv()
call, that doesn't imply that the drivers go to the hardware
and ask for exactly that amount of data. Instead, the hardware is
told to stream samples, and the underlying libusb
bulk-transfer mechanisms are used to provide a continuous collection
of buffers with samples in them, and the
user-side recv() call is vacuuming out those buffers.
*From:*Marcus D. Leech <[email protected]>
<mailto:[email protected]>
*Sent:* 23 February 2023 15:34
*To:* [email protected]
*Subject:* [USRP-users] Re: libuhd - read IQ samples without
discontinuities
On 23/02/2023 04:27, Peter Featherstone (XENINT) wrote:
Hi,
I’m trying to read samples from my B210 as fast as possible
without gaps in the IQ.
I’m using a sample rate of 1e6 Hz and read 5s of IQ.
As an experiment, I read 16K samples at a time in a loop.
At each iteration I sleep for 5 seconds.
I was expecting to see loads of ERROR_CODE_OVERFLOW error
codes, but I don’t.
Is it the case that that error is only “thrown” when you can’t
write to a buffer quick enough, but not necessarily if you’re
waiting too long between successive reads in a continuous RX
stream?
Many thanks,
*Peter*
_______________________________________________
USRP-users mailing list [email protected]
To unsubscribe send an email [email protected]
If you want to capture samples discontinuously, this is not the
way to do it.
Use "NUM_SAMPS_AND_MORE" in creating your stream:
https://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html
This particular stream mode tells the device to send you the
number of samples requested and to expect a future
stream command to fetch more samples.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
