[Ground-station] responses to more comments on ka9q-radio

[Phil Karn]

A few days ago Michelle forwarded me some comments and I replied to her,
but I haven't seen the thread here yet. So, cutting and pasting:

[comment]

Figuring how to do on-the-fly uninterrupted parameter updates was one of
the best parts of DttSP. Punting on that is not helpful. Without solving
that, it will never fly for interactive work.

It might work as a headless appliance hung off of selectively extracted
channels from a multi rate trunk. The parameter update problem will
probably required completely reworking the filtering apparatus.

[response]

The filter response can be changed with the tuning knob or keys at any
time, just like the radio itself can be tuned. Even the Kaiser parameter
can be varied in real time. The only parameters that currently cannot be
changed on the fly are the filter blocksize and FIR length, mainly
because I haven't felt much need for it. I most often set the blocksize
L=3840 samples (20 milliseconds) and the FIR length M=4353 samples, for
a FFT length of L+M-1 = 8192 samples.

The 20 millisecond block length matches the default Opus encoder frame
duration, though both can be changed. This is long enough to give
excellent selectivity but short enough that the latency isn't really
noticeable. Digital demodulators downstream of the receiver are of
course free to use whatever filters they want.

Because of the 4:1 decimation, the IFFT is length 2048.

[additional response]

I tried to make as many receiver parameters changeable in real time as
possible. Especially frequency, as one of my major goals was to do
open-loop Doppler correction as well as I possibly could so it wouldn't
disturb coherent demodulation of BPSK. This requires a close look at the
tuning algorithm and how it would affect carrier tracking in the modem.

I think I succeeded. You do have to make sure that the signal will
remain somewhere in the FCD passband so you don't have to retune it
during the pass and suffer the synthesizer transient.

I eventually put Doppler correction it a separate complex oscillator and
mixer that (when used) immediately follows the oscillator/mixer used for
tuning the FCD I/Q passband. So the user sees and tunes the actual
frequency emitted by the satellite at rest (i.e., the AMSAT One True Way
of Doppler correction).

The Doppler oscillator is programmed with a phase rate and a phase
rate^2. Each iteration works like this:

sample *= osc_phase;
osc_phase *= phase_step;
phase_step *= phase_step_step;

This produces a frequency sweep at a given rate from a given starting
point. The external tracking program, read through a pipe, feeds
velocity vs time data. The code inside ka9q-radio periodically computes
the doppler shift using the actual radio frequency and sets both
phase_step and phase_step_step so the oscillator frequency will match
the computed doppler at the beginning and end of the interval. I.e., its
a piece-wise fit to the frequency function. The oscillator is of course
continuous phase.

I actually went the next step and derived the analytic equation for
apparent satellite acceleration (i.e., frequency rate). (Thanks to Bob
for help on this during the 2016 AMSAT symposium at sea in the Gulf of
Mexico.) Acceleration in a rotating frame is pretty hairy, and one of
the terms was the actual gravitational acceleration on the satellite.
This gets complicated since the simple Newton inverse-square has to be
modified for the oblateness of the earth. It was an interesting exercise
but I eventually gave up and fell back to acceleration by finite
differencing the NORAD model output (which already handles perturbations
from earth oblateness). You can make the error arbitrarily small by
reducing the time step, and the greatest source of error will probably
be the orbital elements anyway.

So for demodulator PLL purposes, the carrier phase and frequency are
continuous with time but frequency rate (second time derivative of
carrier phase) will change in a stepwise fashion. If this is ever a
problem (and I don't think it will be) I could always add a third
complex multiply to the spindown operation, i.e.,

phase_step_step *= phase_step_step_step;

That would make the frequency time-continuous with step changes in jerk,
i.e., time derivative of acceleration.

(Trivia question for those who've actually read this far. Jerk seems to
be important to elevator design engineers. Why?)

73 Phil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xF14E4354ED463446.asc
Type: application/pgp-keys
Size: 3301 bytes
Desc: not available
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20180423/19f010eb/attachment.key>