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 <christ...@kumunetworks.com> 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 -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
