On 01/05/2025 14:28, Pedro Pertusso wrote:
Hi,
I’m using a USRP B200 mini to receive the GOES Rebroadcast (GRB)
signal at 1.6866 GHz. Before recording, I ran a benchmark using the
/benchmark_rate/ script at a rate of 13 MHz, which completed without
any dropped samples. The command I used was:
sudo ./benchmark_rate --args "type=b200" --rx_rate 13e6 --duration 600
--rx_spb 4096 --ref internal --priority high
Following the benchmark, I attempted to record the signal at a rate of
13 MHz using the /rx_samples_to_file/ script with the following command:
./rx_samples_to_file --rate 13000000 --freq 1686600000 --file
GRB_recording.dat --duration 600 --type short --spb 4096 --gain 37
--ref internal --wirefmt sc16
Unlike the benchmark, this resulted in several overflows. These
overflows occurred in bursts (typically 3 to 4 at a time) and appeared
roughly every 1 to 2 minutes.
I’m running this setup on a ThinkPad T14 Gen 4 running Debian 12 with
an Intel i7-1355U, 32 GB of DDR5 RAM, and a 1 TB NVMe SSD. The USRP is
connected via USB 3.0 Micro-B. During recording, CPU usage remains
below 25%, and I haven’t identified any resource bottlenecks.
While reviewing the USRP documentation, I came across two parameters
that might help: /recv_frame_size/ and /num_recv_frames/. I haven’t
had the chance to test them yet, but I was planning to try something like:
--args "recv_frame_size=8192,num_recv_frames=1024"
Any help or guidance would be greatly appreciated!
Best regards,
Pedro
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
The "num_recv_frames" parameter MIGHT help.
But your main issue might be that your recording mechanism simply can't
keep up.
At 13Msps, recording "shorts", you're recording 4 bytes per sample, or
52Mbyte/second. It may be that your system can't
sustain write rates that high for extended periods.
Your NVME interface and USB interface may be sharing an underlying PCIe
subsystem, and thus contending for resources. CPU
utilization is not the whole story in this kind of work...
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
