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

[Michelle Thompson]

The parameter update issue is a general-case design issue. It is important.
Please think about it some more.

RTP/multicast and Opus features are things I want to fold in to our GNU
Radio implementation.

-Michelle W5NYV



On Mon, Apr 23, 2018 at 10:37 AM, Phil Karn via Ground-Station
<ground-station at lists.openresearch.institute> wrote:
>
> 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
>
>
> _______________________________________________
> Ground-Station mailing list
> Ground-Station at lists.openresearch.institute
> http://lists.openresearch.institute/mailman/listinfo/ground-station
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20180423/3fa20c03/attachment.html>