When receiving signals from a satellite, it can be important to correct for the Doppler shift in the signal. Normally, I use Gpredict to track satellites and compute the Doppler shift. Gpredict can control the frequency of a receiver using Hamlib to track the Doppler shift. When using an SDR receiver, there are several possible ways of using Gpredict’s frequency control.
Normally, the SDR software doesn’t support Hamlib control in a way that it’s useful and easy to use for this purpose. This is the case with Linrad, which is the software I use, and probably with many other popular SDR softwares. An easy solution is to let Gpredict completely control the frequency of the SDR receiver through Hamlib and prevent the SDR software from controlling the frequency. With the FUNCube Dongle Pro+, which is the receiver I normally use, this is easy to do. It can be controlled without problem with recent versions of Hamlib, and if you set the dongle in Linrad as an “Undefined” card instead of a FUNCube Dongle, then Linrad will not try to control its frequency.
The problem with this solution is that each time that the frequency gets updated, it does so in a non phase continuous manner, because the PLL of the receiver has to lock on to the new frequency, effectively losing reception for just a tiny amount of time. This supposes no problem for SSB, CW or FM reception, because your ears just don’t notice. However, if you want to receive any digital signal or SSTV, the frequency change usually messes with the decoder software, which loses sync and suffers decoding problems. An alternative solution is to leave the receiver frequency fixed and correct for Doppler shift in software.
It turns out that it’s quite easy to do this in GNURadio. By using gr-grpedict-doppler, one can interface Gpredict’s frequency control with a GNURadio flowgraph. I have made a really simple flowgraph that it’s supposed to sit between the FUNCube Dongle Pro+ and Linrad and do it’s Doppler correction job. Other SDR receiver hardware and software can be used with this flowgraph with the appropriate setup.
To give you an idea of how this is used, I’ll quickly describe my setup. I have set a radio device in Gpredict using port 4534 to control gr-gpredict-doppler. I have the Linux module
snd-aloop loaded, and this gets device
hw:1. Windows users can probably use some virtual audio cable software. I have my FUNCube Dongle Pro+, which gets device
hw:2. The GNURadio flowgraph is set to read from the dongle at
hw:2,0 and write to the audio loop at
hw:1,0,0. Linrad is set to use an ALSA input at
hw:1,1 of type “undefined” (this will read from the other end of the audio loop).
When I want to receive a satellite, I first decide on the centre frequency to use. I have to take into account that I must be able to fit the desired signals into the passband of the dongle, which is 192kHz around the centre frequency. The centre frequency has a DC spike, so the desired signals should not fall on top of it. Also, keep in mind that for a typical LEO satellite the signals will move throughout the pass about +/-3.3kHz if on the 2m band and +/-10kHz if on the 70cm band. I have to take this into account and prevent the signals from going out of the passband or crossing over the centre frequency DC spike as the Doppler shifts them in frequency.
Once I have decided on an centre frequency, I set that frequency into Gpredict, into the GNURadio flowgraph and into the dongle using Qthid. Then I run the flowgraph, engage Gpredict radio control using a 100ms update interval and run Linrad. I also set the correct centre frequency in Linrad (this is only to make the frequency readings in Linrad accurate). This is all that is needed for the setup. Signals of any type, including digital signals can be received without problem.
This kind of techniques can also be used on the transmit side. An application that comes to mind is the PSK31 transponder on PSAT. This transponder can receive several PSK31 signals in a 3kHz passband in the 10m band and downlink that band through FM on the 70cm band. The 10m band is used on the uplink because the Doppler shift is much less than on the VHF and UHF bands. Even so, a usual PSK31 decoder will fail to track signals that drift more than about 1Hz/s, and the 10m Doppler will be more than than in may occasions. Therefore, it is quite useful to use Doppler control on the uplink. This has to be done in a phase continuous manner for the reasons already mentioned.
Fortunately, the total Doppler shift on 10m is only about 1.4kHz. This is smaller than 2.7kHz, which is the passband that an SSB transceiver usually has. Therefore, the Doppler control can be done in software, keeping the SSB transmitter’s frequency fixed and doing all the Doppler correction in the audio frequency. There is a program called DopplerPSK which does precisely that: it is a transmit-only PSK31 software that corrects for the transmit audio frequency in a phase continuous manner. To date, it is the only software I know that is capable of doing this. Using a simple GNURadio flowgraph similar to the one that has been describe here, one could also use his favorite PSK31 software (fldigi perhaps) for Doppler corrected transmission. The flowgraph would just sit between the PSK31 software and the audio output connected to the transceiver, and shift the audio frequency to correct for Doppler. I will probably be testing this in the future, when I have access to my HF station.