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

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-leave@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...