I am trying to develop a satellite ground station using the PSK
demodulator
block. This works fine when tuned accurately. However, with low
satellites
there is quite a bit of Doppler at VHF / UHF and there is also some
frequency drift with satellite temperature as it enters or comes out of
eclipse. This is a problem as the signals are relatively narrow in
bandwidth
compared to the Doppler and drift. I am wondering how to track this
Doppler
in Gnuradio. I have tried a PLL block and while this works it isn’t
quite
right unless the signal is very strong. It can also get fooled by one of
the
many spurious signals encountered on the bands.
To some extent the Doppler can be predicted and compensated for, but
only
when the orbital parameters are known accurately. Even a few seconds
error
at TCA can make quite a difference.
Is there a preamble/training sequence you can search for? If so, you can
use that to get the initial frequency offset estimate to correct and
then
use the PLL to track the fine phase correction.
Not really, though there is an AX25 style header. Far from ideal
01111110 flags.
Mike
From: Colby B. [mailto:[email protected]]
Sent: 03 September 2014 03:11
To: Mike W.
Cc: GNU Radio D.ion
Subject: Re: [Discuss-gnuradio] PSK demodulator and Doppler
I am trying to develop a satellite ground station using the PSK
demodulator block. This works fine when tuned accurately. However, with
low satellites there is quite a bit of Doppler at VHF / UHF and there is
also some frequency drift with satellite temperature as it enters or
comes out of eclipse. This is a problem as the signals are relatively
narrow in bandwidth compared to the Doppler and drift. I am wondering
how to track this Doppler in Gnuradio. I have tried a PLL block and
while this works it isn’t quite right unless the signal is very strong.
It can also get fooled by one of the many spurious signals encountered
on the bands.
To some extent the Doppler can be predicted and compensated for, but
only when the orbital parameters are known accurately. Even a few
seconds error at TCA can make quite a difference.
Is there a preamble/training sequence you can search for? If so, you can
use that to get the initial frequency offset estimate to correct and
then use the PLL to track the fine phase correction.
My solution involved the frequency translating block and a third party
application. As part of the initial channel filter, I set the the
“Center
Frequency” attribute to -40000+fftshift*rx_shift_factor (assuming my LO
tuned to +40 KHz from the carrier). The satellite tracking program,
PREDICT, provides a Doppler shift calculation assuming a 100 MHz
carrier.
rx_shift_factor is the satellite carrier frequency divided by 100 MHz. I
then polled PREDICT, which provides a UDP server interface and then in
Python called set_fftshift method on the flowgraph object generated by
gnuradio-companion. In turn, this would update the taps of the FIR
filter
to provide a desired frequency shift.
As for temperature drift, I assumed that with a strong enough signal,
the
inbuilt Costas loop would be able to bring the signal back to baseband.
The drawback of this solution is that it’s not fully contained within
gnuradio-companion, and like you said, requires the orbital elements to
be
known. One solution that uses the PLL block is here: https://www.cgran.org/wiki/ESTCube-1Receiver
As for temperature drift, I assumed that with a strong enough signal, the
inbuilt Costas loop would be able to bring the signal back to baseband.
The drawback of this solution is that it’s not fully contained within
gnuradio-companion, and like you said, requires the orbital elements to be
known. One solution that uses the PLL block is here: https://www.cgran.org/wiki/ESTCube-1Receiver
It might not be completely contained in GRC, but it’s a clever solution.
Another thing to look into is the fll_band_edge block. This will only
work,
however, if the signal is pulse-shaped. Specifically with an RRC filter
by
design, but we can modify it for other pulse shapes as well. This only
does
coarse frequency correction, but it’s lock in bandwidth is much wider
than
that of the Costas loop block. You’d still want to follow this up with
the
Costas loop for fine frequency and phase tracking.
One thing, too, is that this block is fairly expensive computationally.
It’s calculating two FIR filters, which should be replaced by fast
convolution filters. And I think that we could even combine this into a
single filter operation.
Is there a preamble/training sequence you can search for? If so, you can use
that to get the initial frequency offset estimate to correct and then use the PLL
to track the fine phase correction.
I use predict, the xmlrpc server, and it bit of glue code for twiddling
the FIR filter’s offset for my Funcube and NOAA receivers to account
for doppler.
Allows me to have tighter BPFs (well LPF’s really), although does mean
I need to remember to update the TLE’s from time to time!
Biggest problem I have is Funcube-1’s beacon has thermal drift as
she comes out of eclipse that goes the opposite way…Been trying
to use a Freq_Det block to help, but not had the time to experiment
recently
Iain
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.