Some students built an HF inverting SSB transponder simulator. (4 diodes, and a siggen at 58 MHz) so they can then use two FT-817’s on the 21.4 MHz uplink and 29.4 MHz downlink) for our next satellite: http://aprs.org/hfsat.html )
Now we want to use an USRP 2922 SDR as the programmabel oscillator around 58 MHz so we can simulate Doppler.
Can anyone whip out some code to make the oscillator follow a Doppler Ramp in freuqncy from say 58.100 to 58.900 MHz over a ten minute pass. That should be easy enough for one-observer. Can just be linear for now (simulating a low pass).
But then once that is done, we need the driver to then FLIP the Doppler shift instantly in the opposite direction to simulate the shift seen by another observer at the other end of the pass. This is another layer of complexity, but we will simply have a push button input to shift between the two states when one station or the other is transmitting.
But for now, the students just need some handholding to get the basic SDR acting as a signal gen at 58 MHz and how to input the freqncy ramp to it.
Thanks
Bob, WB4APR
El 17/04/17 a las 16:37, Robert Bruninga escribió:
Can anyone whip out some code to make the oscillator follow a Doppler Ramp in freuqncy from say 58.100 to 58.900 MHz over a ten minute pass. That should be easy enough for one-observer. Can just be linear for now (simulating a low pass).
Hi Bob,
You can take a look at gr-gpredict-doppler.
https://github.com/wnagele/gr-gpredict-doppler
Together with one or two (for the case of two observers) instances of Gpredict, it can do what you want.
73,
Dani.
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
Much easier to use an HP signal generator and drive it via the GPIB port. Less noise, more accurate, etc..
A nit to program across GPIB. Slightly more complex than talking to a TNC.
Norm n3ykf
On Mon, Apr 17, 2017 at 10:37 AM, Robert Bruninga bruninga@usna.edu wrote:
Some students built an HF inverting SSB transponder simulator. (4 diodes, and a siggen at 58 MHz) so they can then use two FT-817’s on the 21.4 MHz uplink and 29.4 MHz downlink) for our next satellite: http://aprs.org/hfsat.html )
Now we want to use an USRP 2922 SDR as the programmabel oscillator around 58 MHz so we can simulate Doppler.
Can anyone whip out some code to make the oscillator follow a Doppler Ramp in freuqncy from say 58.100 to 58.900 MHz over a ten minute pass. That should be easy enough for one-observer. Can just be linear for now (simulating a low pass).
But then once that is done, we need the driver to then FLIP the Doppler shift instantly in the opposite direction to simulate the shift seen by another observer at the other end of the pass. This is another layer of complexity, but we will simply have a push button input to shift between the two states when one station or the other is transmitting.
But for now, the students just need some handholding to get the basic SDR acting as a signal gen at 58 MHz and how to input the freqncy ramp to it.
Thanks
Bob, WB4APR _______________________________________________ Sent via AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
agreed. Phase noise and such will be much better from HP products.
If thats the setup scenario, could still use pyephem married up to the driver code for the GPIB interface to generate the doppler profiles.
-Zach
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 12:37 PM, Norm n3ykf wrote:
Much easier to use an HP signal generator and drive it via the GPIB port. Less noise, more accurate, etc..
A nit to program across GPIB. Slightly more complex than talking to a TNC.
Norm n3ykf
On Mon, Apr 17, 2017 at 10:37 AM, Robert Bruninga bruninga@usna.edu wrote:
Some students built an HF inverting SSB transponder simulator. (4 diodes, and a siggen at 58 MHz) so they can then use two FT-817’s on the 21.4 MHz uplink and 29.4 MHz downlink) for our next satellite: http://aprs.org/hfsat.html )
Now we want to use an USRP 2922 SDR as the programmabel oscillator around 58 MHz so we can simulate Doppler.
Can anyone whip out some code to make the oscillator follow a Doppler Ramp in freuqncy from say 58.100 to 58.900 MHz over a ten minute pass. That should be easy enough for one-observer. Can just be linear for now (simulating a low pass).
But then once that is done, we need the driver to then FLIP the Doppler shift instantly in the opposite direction to simulate the shift seen by another observer at the other end of the pass. This is another layer of complexity, but we will simply have a push button input to shift between the two states when one station or the other is transmitting.
But for now, the students just need some handholding to get the basic SDR acting as a signal gen at 58 MHz and how to input the freqncy ramp to it.
Thanks
Bob, WB4APR _______________________________________________ Sent via AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
Sent via AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
participants (4)
-
Dani EA4GPZ -
Norm n3ykf -
Robert Bruninga -
Zach Leffke