Hi Bob,
I don't have whip out level software, but can offer a few rabbit holes for the students to go down. I did a similar project for my graduate SDR class a few years ago where I built a 'satellite simulator' using USRPs. Trust Me you don't want that code (I was new to all this at the time), but below are my two cents from lessons learned and new things since then.
1. The USRP 2922 SDR from national instruments is an Ettus Research (now owned by NI) USRP with an SBX daughtercard installed. The RF output of this device is between 400 MHz and 4.4 GHz. So if you are looking to use it as a programmable LO, it likely won't do. (also, kind of moot, but if you buy direct from Ettus Research, it is cheaper). What I would recommend is an Ettus Research N210 (https://www.ettus.com/product/details/UN210-KIT, $1896) and a different daughtercard that will work at the required Frequency, like a BasicTX that operates from 1-250 MHz (https://www.ettus.com/product/details/BasicTX, $83). While your at it, you might as well get the BasicRX so you can monitor the spectrum with the same device (has independent tuning between TX and RX, and you can install both daughtercards in one N210).
2. If you are using USRPs you are probably using GNU Radio (Awesome!). As Dani mentioned, there is a gr-gpredict-doppler out of tree module that can be linked with Gpredict to control tuning in GNU Radio. This is for sure probably the simplest most direct way to get up and running, so I second that idea (feel free to ignore my number 3). For my graduate class project, I used the UDP server feature of plain ole 'predict' (actually 'predict-g1yyh') to do achieve basically the same goals. The problem I ran into with this type of interface was time (like UTC time). At the time I didn't understand how to properly use predict via the UDP server function to query it for different time stamps other than 'now.' End result was I could only run simulations when an actual satellite was overhead, pretty clunky. Gpredict has a pretty simple interface for controlling time though (to move the simulation into the future or back into the past), and I'm sure it can be done in predict via the UDP interface, I was just new to everything, so lots of 'student operator error.' I mention it only as a 'watch out for this one' type thing.
3. One way to think of GNU Radio is that the 'flowgraph' or 'modem' is just a python class, which can be imported and controlled by large python programs (you can start/stop the flowgraph, update parameters, etc.). So for a bit finer control, and if I could do it all over again the way I would probably go, is another option called 'pyephem' (http://rhodesmill.org/pyephem/). This handy little python module is capable of importing TLEs and executing the SGP4 algorithm for orbital propagation. In addition you can feed it ground station coordinates and times (UTC) and then query it for az/el/range/range rate (doppler) information. Its basically a python version of the 'engine' that runs under the hood of predict or gpredict. So for a bit finer resolution, and to make a single compact python program that doesn't rely on an external program (only one 'thing' to execute and control), you could use pyephem to compute the doppler values and then feed that to GNU Radio. To be clear though, this is not a GNU Radio out of tree module, it is a standalone python module, and some coding would be required to merge the two (I would run pyephem in one thread or process with callbacks to control the GNU Radio parameters).
4. Last little nugget, when you install GNU Radio, it comes with a handy little set of executables. One of the commonly used ones is 'uhd_find_devices' which locates connect USRPs (IP or USB based connections) and returns basic information about them (IP addr, serial numbers, installed daughtercards, etc). If 'uhd_find_devices' works and returns info, then when you execute the flowgraph it should be able to locate the device. Another common one is 'uhd_fft' which is a quick way to get a spectrum analyzer like display up and running. The other lesser known tool is 'uhd_siggen' or 'uhd_siggen_gui.' This little tool lets you quickly generate transmit signals. So for a 'static test' to make sure the USRP is working as an LO (right power levels, frequency, etc.) you can use this to get a quick feel for whether or not it will work for your application. It has a bunch of sliders for controlling transmit gain and center frequency so you should be able to 'manually' test out your system and verify things are working before diving into the complexities of custom flowgraphs with the doppler simulations.
Hope this helps. Cool Stuff!
God Luck and 73s,
-Zach, KJ4QLP
Research Associate Aerospace Systems Lab Ted & Karyn Hume Center for National Security & Technology Virginia Polytechnic Institute & State University Work Phone: 540-231-4174 Cell Phone: 540-808-6305
On 4/17/2017 10:37 AM, Robert Bruninga wrote:
USRP 2922 SDR