5
$\begingroup$

Doppler shift mitigation has been studied extensively in the literature. In my implementations of satellite receivers (using GNU Radio), I use predicted Doppler shift from a software (GPredict) to compensate for Doppler shift. After that, I use a Frequency-Locked Loop (FLL) for course carrier synchronization. This approach works very well. However, I have been trying to implement new carrier frequency synchronizers that will enable operations without the help of an external software. When I looked at the literature again (Umberto Mengali book, chapter 3), carrier frequency recovery is divided into two cases:

  1. When the frequency offset is much lower than the symbol rate (< 10%?)
  2. When the frequency offset is in the order or the symbol rate

The two cases listed above are pretty straightforward to implement (I'm in the process of doing so). However, there are other cases, such as those at S-band which use "low rate telemetry" in the order of a few 10s of kilobytes. The Doppler shift is many orders of magnitude higher than the symbol rate. Can anyone suggest any algorithm that can work in this case? All I want to avoid is the use of an external software.

Thanks.

|improve this question
$\endgroup$
  • 1
    $\begingroup$ Why not integrate the orbital data into your software then? I can't imagine any blind estimation algorithm will perform nearly as well as an informed one, especially with something so predictable as satellite orbits. $\endgroup$ – Phil Frost - W8II Apr 20 '18 at 13:56
  • $\begingroup$ @PhilFrost-W8II That a good point. However, predictive models work well in nominal cases. There are some other cases, for example during Launch and Early Orbit Phase (LEOP) where predictive models are not good enough. $\endgroup$ – Moses Browne Mwakyanjala Apr 20 '18 at 14:23
  • $\begingroup$ What degree of Doppler shift should be expected (e.g. ppm/s)? What type of modulation? $\endgroup$ – Glenn W9IQ Apr 21 '18 at 9:54
  • $\begingroup$ @MosesBrowneMwakyanjala I'm pretty sure that if your Doppler during launch isn't predictable enough for rough correction, you will not go to space today. But: There are approaches for your described case. Let me write something down. $\endgroup$ – Marcus Müller Apr 21 '18 at 15:05
  • 1
    $\begingroup$ By the way, I'd recommend moving this kind of questions to dsp.stackexchange.com – they are on scope here as general radio technology questions, but go very deeply in the direction of signal processing, so you might find more knowledgeable people over there. $\endgroup$ – Marcus Müller Apr 21 '18 at 18:37
3
$\begingroup$

You can actually implement something like that as a rake-style receiver: Simply put up an array of (partially overlapping) more narrowband receivers and let them run in parallel until one "locks" onto a signal, and then follow that (typically: higher-order costas loop; and: I can heartily recommend fred harris' slides and recording from GRCon'17 on band-edge filtering; also, I recommend watching Andy Wall's Talk on Symbol Clock Recovery and Improved Symbol Synchronization Blocks, slides).

Now, assume you get an initial lock, what to do now?

Obviously, your control loop needs not only correct stationary phase (first-order costas loop would do that), but also frequency offset (which is nothing but a linear phase shift over time; second order costas), and, to make matters worse, possibly even a shift in frequency over time (that's why I said "higher-order costas" above).

You can of course go ahead and just do a "blind" high-order phase control loop; but that would never be as good as something as something able to predict the frequency development over time. Basically, what you'd want to do is to find the signal, observe how its phase develops on short term, and infer the "Doppler trajectory", which is the result of the satellite/receiver geometry. Then, you'd base your corrections on that prediction, and only use the control loops to get rid of residual error.

That can get very interesting in effect – what you'll basically be doing is building kind of the frequency-over-time-equivalent to a matched filter.

Another observation: If you've got a beamforming receiver setup, that geometrical prediction would directly allow for adjusting the relative phase shifts of the individual receive chains – which would both have an effect on the beam pattern and the described frequency / phase correction. The same idea applies if you have a directive antenna – say a dish – that mechanically follows the path of the satellite!

|improve this answer
$\endgroup$
  • $\begingroup$ Thanks for the response @MarcusMuller. I was just curious about phase correction using a high order (3?) Costas loop. In some CPM schemes like FSK (GFSK), a limiter + differentiator is used, which eliminates the static phase error (the derivative of the phase component becomes zero) and hence no phase correction is done. In gnuradio, this goes as "iq-receiver (usrp,rtl etc)--> filtering --> quadrature-demodulator --> timing recovery (M&M, Polyphase)--> Line decode --> packet extraction". How can I use the technique you described in this case? $\endgroup$ – Moses Browne Mwakyanjala Apr 25 '18 at 9:42
  • $\begingroup$ very likely before the quadrature demod or before the filter, you'd have a costas loop block. $\endgroup$ – Marcus Müller Apr 25 '18 at 11:45
0
$\begingroup$

This is a great Q&A. It is fun to think about all this, and I have learned a lot by reading the various ideas here.

So let me toss in my 2 cents worth, speaking as a former Commo who had to deal with Doppler on a routine basis.

Instead of predictive modeling we simply went out and figured out what worked.

Back at Fort Richardson we would track a few of the Oscars with hand-held Alaskan Arrow antennas. (They can not only be aimed but also rotated to peak the signal based on polarization) Whether at the Center or out in the field, the procedures were the same.

This was grunt-work field comms.

It all had to fit in a backpack and be ready for use in minutes. Our "2" man would give us the pass predictions for the day.

Our mantra was MIW - Make It Work.

So we would use CHIRP to pre-program the Yaesu VX-8DR radios with three NFM channel pairs for each bird. The Alaskan Arrow has a diplexer (their word) so one radio can work both VHF and UHF alternately.

  • AOS: 5 KHz Above Center - for when it pops up moving towards us

  • CTR: Center Frequency (145.800 simplex for the ISS, for instance)

  • LOS: 5 KHz Below Center - for when it is moving away ready to vanish

It was important for the radio man to have a quick way to simply rotate the channel selector to track the Doppler shift for the very few minutes we would get at 61 Degrees latitude.

Sometimes I would do it all alone, handling the radio in one hand and the antenna in the other.

At our latitude it was important to use the full-length Alaska Arrow to get the most gain so I mounted mine to a microphone stand.

Our comm windows were short. But we Made It Work.

So, even though there was not a lot of math involved at the level I see here in this Q&A, this was the end result - it worked reliably.

We could talk to our own field units and sometime even reach California ham operators.

Adjusting for Doppler was not optional in the least. Very important part of the setup.

To get Full Duplex, it is definitely a two-man job. Two radios and a hand-held antenna. The Alaskan Arrow allows you to bypass the diplexer and simply connect the UHF radio to one set of elements and the VHF radio to the other.

Of course, Full-Dup has not been supported by ARISS for voice, in my experience. It is usually just VHF-Simplex.

We always just listened for them. Too much QRM for us to try to compete.

For all the birds it is not polite to try to overpower others so we stayed strictly at 5 Watts output (with high-gain antennas). We found that in general hams are usually polite on OSCARs. Most QRM is accidental.

Now that I live Outside, in the contiguous states, the comm windows would be longer, so perhaps I would use 5 channels with 5 KHz spacing.

|improve this answer
$\endgroup$
  • $\begingroup$ I am looking forward to the day when we finally have a GEO (geosynchronous) Oscar. I suspect it will need to be packet store-and-forward in order to handle the expected workload. $\endgroup$ – SDsolar Apr 23 '18 at 1:21

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.