Just as an additional update - I was able to test with UHD 4.1 and there
is no issue - seems to be something with UHD 3.15 then.

Hi Brian,

No - only intention would be to receive for 10 seconds and save data. What
would you suggest?

On Mon, Aug 9, 2021 at 2:12 PM Jonathan Tobin <Tobin@augustusaero.com
mailto:Tobin@augustusaero.com> wrote:

 Just as an additional update - I was able to test with UHD 4.1 and
 there is no issue - seems to be something with UHD 3.15 then.

Just chiming in here to ensure you understand that your test of
receiving 625M samples using that particular program will keep all
those samples in memory for all the channels while you receive.

In other words, 10GB of RAM (625M samples * 4 bytes/sample/channel * 4
channels) will be used just to hold your received signal.

Is this what you really intend to do?

The error you received before was a 32-bit/4GB limit I am pretty sure
(26843545544 = 4294967280 ~= 2^32).

Brian

On Tue, Aug 10, 2021 at 9:39 AM Jonathan Tobin <Tobin@augustusaero.com
mailto:Tobin@augustusaero.com> wrote:

 Hi Brian,

 No - only intention would be to receive for 10 seconds and save
 data. What would you suggest?

Modify the program to write out to a file on a high performance drive
and receive smaller parts at a time from UHD.

Brian

To follow up,

This seems to be the limit now that I have updated to UHD 4.1.0.1:

[ERROR] [0/Radio#0] Requesting too many samples in a single burst!
Requested 18446744028430598144, maximum is 281474976710655.

This occurs with the key arguments: --rx-rate 4.8e6 --rx-subdev "A:0
A:1 B:0 B:1" --rx-channels "0,1,2,3" --nsamps 2880000000

The nsamps value is for 10 minutes of recording (sample rate * 60
seconds * 10 minutes).

Thanks,
Jonathan

On 08/10/2021 05:07 PM, Jonathan Tobin wrote:

To follow up,

This seems to be the limit now that I have updated to UHD 4.1.0.1:

[ERROR] [0/Radio#0] Requesting too many samples in a single burst!
Requested 18446744028430598144, maximum is 281474976710655.

This occurs with the key arguments: --rx-rate 4.8e6 --rx-subdev "A:0 A:1
B:0 B:1" --rx-channels "0,1,2,3" --nsamps 2880000000

The nsamps value is for 10 minutes of recording (sample rate * 60 seconds

• 10 minutes).

Thanks,
Jonathan

Right.  Because that example program uses the NUM_SAMPS_AND_DONE
streamer type, which requires that the RADIO keep track of the
number of samples you're interested in.  That was extended from 32-bits
to 48 bits.

You'll note that txrx_loopback_to_file will simply run continuously if you
dont specify --nsamps, because it uses two different streaming modes:

// setup streaming
uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)
?
uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS
:
uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);

You can then just interrupt it when you're done or add some code to see if
you have enough samples, even when you're running continuously
or see if enough time has elapsed, etc, etc.

Contrast with rx_multi_samples:

// setup streaming
std::cout << std::endl;
std::cout << boost::format("Begin streaming %u samples, %f seconds in
the future...")
% total_num_samps % seconds_in_future
<< std::endl;
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);

Same comment as above.  You can modify this to run continuously, and then
have the sample-gather loop exit when it is satisfied that it has
enough samples--either because enough time has elapsed or a sample
counter has reached a certain value.

The UHD API is diverse.  There's no possible way that the handful of
example programs can possibly satisfy every use case, and that's simply
not design intent.  Some programming may be required.

USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com

It's too bad that Ettus did not implement the STOP_CONTINUOUS as a
timed command.  Had they done so, it would have been possible to send
a START_CONTINUOUS followed immediately by a STOP_CONTINUOUS (with
time stamp) such that the radio would automatically stop on the
correct sample. That being the case, the long captures require the
user to stop the radio after receiving the desired number of samples
and then flush / discard the rest.
Rob