Hi Brendan, Thank you for your interest!
Our use-cases related to production test and general lab-use are mostly signal generator like with some receive: 2-3x 100 Msps Transmitters continuously playing back a 5G or WIFI waveform with simultaneous 2x 100 Msps receive. These setups are rock solid in terms of reliability - transmitters humming along for days without any underruns, no receive overflows. Most systems have been upgraded over the years - now mostly Intel 9700k's with Intel x710-DA2 NICs. The research use-cases are typically to prototype a system that would eventually be turned into a custom PCB... with data-converters, FPGA, etc. In those use-cases, we do a fair amount of MIMO channel estimation. Anywhere from 4 to 8 concurrent 100 Msps receive - typically using 2-4 USRP X300s directly connected to 1 host. python-uhd's receive() yields numpy ndarray's, but everything is zero-copy under the hood. (I am recv()'ing into the same buffer that will eventually be owned and freed by the ndarray.) When possible, we keep sample block sizes large, so we don't see any receive overflows in UHD, but of course, if the application permits, our DSP will selectively drop samples to keep up. Answers to your questions 1. Exactly - the official Python API didn't exist at the time. 2. Like I eluded above, we frequently and reliably pull 8x 100 Msps for doing 4x4 MIMO channel estimation through this Python API. Good single-threaded CPU performance and reasonable memory bandwidth are important - these are 9700k based systems turboing few cores into low 5 GHz. NIC(s) must be connected through the CPU's PCIe lanes, not something MUX'd through the southbridge.... not a Raspberry PI. They run Arch Linux. 3. That's a great question. I've never actually tested it. When I build UHD, I always pass "-DENABLE_PYTHON_API=OFF". I do this for all UHD releases I test against, and old UHD releases just ignore it. I always suspected a potential namespacing issue, but never tried it. Perhaps I will soon. We're always using either a specific UHD release, a modified UHD code base, or a legacy UHD release that predated the Python API. 4. Yes, I have plans to support v4.0.0.0 shortly. The procedure and testing is mostly automated. Many thanks, Christian On Mon, Apr 12, 2021 at 9:56 PM Brendan Horsfield < [email protected]> wrote: > Hi Christian, > > Thanks for the GitHub link, I'll definitely check it out. My current > interest is in receiving signals, not transmitting them, but I can imagine > some future scenarios where a signal generator capability might be handy. > > A couple of questions: > > - Is there any reason why you chose not to use the "official" Python > API provided by Ettus? Was it simply because the Ettus version hadn't been > created at the time you started this project? > - How robust is the receiving function in your Python implementation > in the face of overflows/timeouts/dropped samples etc when receiving data > from the USRP? Does it detect these failure modes and provide some kind of > feedback to the calling method? > - My current UHD driver was built from source with the Ettus Python > API included. If I want to use your implementation, will I have to rebuild > my UHD driver to exclude the Ettus API? > - Do you have any plans to update your repository for UHD v4.0.0.0? > > Regards, > Brendan. > > > On Mon, Apr 12, 2021 at 9:24 PM Christian Hahn <[email protected]> > wrote: > >> Hi USRP-users, >> >> This is not a question. Just a call for general discussion. Sharing how >> we use USRPs. Wondering how others do too. Thanks >> >> I wanted to share this repository with anyone that wants to use older UHD >> releases with Python. This repository started off as an internal company >> tool in 2015 and I threw it up on Github in 2017. At the time, I was swept >> away with how flexible USRPs were, but wanted a more agile means to >> automate them - enter Python. At work, we use a fleet of X300s, N310s and >> B210s for production test and research. For various reasons, we cannot >> always use the latest UHD versions. For example, in some of our legacy >> production test fixtures we are still using v3.9.7. >> >> https://github.com/christian-hahn/python-uhd >> >> In conjunction with this repository, we have a higher-layer software >> stack that wraps python-uhd and makes it appear "vector signal >> generator"-like. We maintain temperature compensated calibration for all >> of our USRP X300s from 50 MHz to 6 GHz that offers a relative accuracy of >> 0.05 dB and an absolute accuracy of < 0.2 dB. This service runs on a >> modest desktop besides each pair of USRP X300s, exposes a REST API and >> basically abstracts them to look like any old Keysight-like MXG signal >> generator. You give it a waveform, a center frequency, output power and it >> handles the rest. >> >> I am curious. Do others use USRPs in similar signal generator like >> use-cases? For production test? Would anyone be interested in using them >> as such? Should I work to clean-up and open source the signal-generator >> like service? It may be tricky to handle the calibration, but I could >> probably include a 'best guess' model for a X300+UBX-160 combination. >> >> Cheers, >> Christian >> _______________________________________________ >> 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]
