Hi Brendan, python-uhd is well suited for this kind of use-case and these sample rates. python-uhd is written wholey in C++. It spawns Receive and Transmit worker threads in the background to handle the high throughput "pulling", "pushing" and looping of samples. So, if python-uhd can't keep up, then neither can the C++ API.
Depending on the Receive use-case, you can: (1) continuously stream samples. The Receiver worker thread will continuously call UHD's recv() and place the results in the Results queue. The C++ worker thread will do a much better job than Python in keeping up with the stream of samples. Python can then pop results from this queue. Samples will never be dropped, and given your sample rate, overflows should not happen. (2) sub-sample blocks of streaming samples. The Receiver worker thread will continuously call UHD's recv() and place results in the Results queue. IF results are not pop'd by Python in a timely manner, the memory of these old, "stale" sample blocks will be recycled. (3) one-shot and done. The Receive worker thread calls recv() once, puts the results in the queue and shuts down the stream. I think (2) sounds like your use-case? You want guaranteed time-contiguous blocks of samples, but you want to "sub sample": discarding some blocks of samples and claiming others. I had a B210 lying around and just tried this. 40 Msps on 1 channel. Using UHD v3.15.0.0. Using a sample block size of 1048576. On my laptop with i7-7820HQ. No optimizations, Ubuntu running i3 Window manager with other apps open. Python was utilizing 40% of 1 core @ 1.8 GHz. Not sure why that 1 core was not getting Turbo'd. Might be because I'm on battery - no idea. However, if you want this to be bulletproof, I recommend running this on a Linux host without GUI and following the Ettus "Host Performance Tuning Tips and Tricks". If an overflow does occur, python-uhd will throw an exception and halt the stream. Cheers, Christian On Thu, Apr 15, 2021 at 8:33 PM <[email protected]> wrote: > Hi Christian, > > I’m developing applications for two different platforms at the moment: > > 1. > > HP Omen laptop, Intel Core i7-8750H CPU @ 2.20GHz × 12, 32GB RAM, > 512GB SSD > 2. > > Raspberry Pi 4 Model B, 8GB RAM, 128GB SSD > > In both cases the B210 is connected to the host via USB 3.0. Each host has > a 1GB RAM disk. > > My target sampling rates are as follows: > > - > > 40 Msps (minimum) on one channel, wire rate = sc16 > - > > 20 Msps (minimum) on two channels, wire rate = sc16 > - > > Number of samples: Currently 2,000 per channel. Might be nice to > increase this to around 50,000 in future. > > (I realise the Raspberry Pi is woefully underpowered for this application, > but I am interested to see how far I can push it.) > > Note that I was actually getting OK results with the Ettus-provided Python > API, but unfortunately it has a bug whereby the metadata object that is > returned with each data packet doesn’t always accurately record overflow > events when they occur. This means I don’t have a reliable way of checking > the integrity of my received data packets. (The C++ API does not appear to > suffer from this problem.) > > How does your python-uhd API perform in this regard? > > Brendan. > > > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
