[amsat-bb] SDR transmitter asa Doppler dig-gen

[Zach Leffke]

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