<div dir="ltr">The parameter update issue is a general-case design issue. It is important. Please think about it some more. <br><br>RTP/multicast and Opus features are things I want to fold in to our GNU Radio implementation. <br><br>-Michelle W5NYV<br><br><br><br>On Mon, Apr 23, 2018 at 10:37 AM, Phil Karn via Ground-Station <ground-station@lists.openresearch.institute> wrote:<br>><br>> A few days ago Michelle forwarded me some comments and I replied to her,<br>> but I haven't seen the thread here yet. So, cutting and pasting:<br>><br>> [comment]<br>><br>> Figuring how to do on-the-fly uninterrupted parameter updates was one of<br>> the best parts of DttSP. Punting on that is not helpful. Without solving<br>> that, it will never fly for interactive work.<br>><br>> It might work as a headless appliance hung off of selectively extracted<br>> channels from a multi rate trunk. The parameter update problem will<br>> probably required completely reworking the filtering apparatus.<br>><br>> [response]<br>><br>> The filter response can be changed with the tuning knob or keys at any<br>> time, just like the radio itself can be tuned. Even the Kaiser parameter<br>> can be varied in real time. The only parameters that currently cannot be<br>> changed on the fly are the filter blocksize and FIR length, mainly<br>> because I haven't felt much need for it. I most often set the blocksize<br>> L=3840 samples (20 milliseconds) and the FIR length M=4353 samples, for<br>> a FFT length of L+M-1 = 8192 samples.<br>><br>> The 20 millisecond block length matches the default Opus encoder frame<br>> duration, though both can be changed. This is long enough to give<br>> excellent selectivity but short enough that the latency isn't really<br>> noticeable. Digital demodulators downstream of the receiver are of<br>> course free to use whatever filters they want.<br>><br>> Because of the 4:1 decimation, the IFFT is length 2048.<br>><br>> [additional response]<br>><br>> I tried to make as many receiver parameters changeable in real time as<br>> possible. Especially frequency, as one of my major goals was to do<br>> open-loop Doppler correction as well as I possibly could so it wouldn't<br>> disturb coherent demodulation of BPSK. This requires a close look at the<br>> tuning algorithm and how it would affect carrier tracking in the modem.<br>><br>> I think I succeeded. You do have to make sure that the signal will<br>> remain somewhere in the FCD passband so you don't have to retune it<br>> during the pass and suffer the synthesizer transient.<br>><br>> I eventually put Doppler correction it a separate complex oscillator and<br>> mixer that (when used) immediately follows the oscillator/mixer used for<br>> tuning the FCD I/Q passband. So the user sees and tunes the actual<br>> frequency emitted by the satellite at rest (i.e., the AMSAT One True Way<br>> of Doppler correction).<br>><br>> The Doppler oscillator is programmed with a phase rate and a phase<br>> rate^2. Each iteration works like this:<br>><br>> sample *= osc_phase;<br>> osc_phase *= phase_step;<br>> phase_step *= phase_step_step;<br>><br>> This produces a frequency sweep at a given rate from a given starting<br>> point. The external tracking program, read through a pipe, feeds<br>> velocity vs time data. The code inside ka9q-radio periodically computes<br>> the doppler shift using the actual radio frequency and sets both<br>> phase_step and phase_step_step so the oscillator frequency will match<br>> the computed doppler at the beginning and end of the interval. I.e., its<br>> a piece-wise fit to the frequency function. The oscillator is of course<br>> continuous phase.<br>><br>> I actually went the next step and derived the analytic equation for<br>> apparent satellite acceleration (i.e., frequency rate). (Thanks to Bob<br>> for help on this during the 2016 AMSAT symposium at sea in the Gulf of<br>> Mexico.) Acceleration in a rotating frame is pretty hairy, and one of<br>> the terms was the actual gravitational acceleration on the satellite.<br>> This gets complicated since the simple Newton inverse-square has to be<br>> modified for the oblateness of the earth. It was an interesting exercise<br>> but I eventually gave up and fell back to acceleration by finite<br>> differencing the NORAD model output (which already handles perturbations<br>> from earth oblateness). You can make the error arbitrarily small by<br>> reducing the time step, and the greatest source of error will probably<br>> be the orbital elements anyway.<br>><br>> So for demodulator PLL purposes, the carrier phase and frequency are<br>> continuous with time but frequency rate (second time derivative of<br>> carrier phase) will change in a stepwise fashion. If this is ever a<br>> problem (and I don't think it will be) I could always add a third<br>> complex multiply to the spindown operation, i.e.,<br>><br>> phase_step_step *= phase_step_step_step;<br>><br>> That would make the frequency time-continuous with step changes in jerk,<br>> i.e., time derivative of acceleration.<br>><br>> (Trivia question for those who've actually read this far. Jerk seems to<br>> be important to elevator design engineers. Why?)<br>><br>> 73 Phil<br>><br>><br>> _______________________________________________<br>> Ground-Station mailing list<br>> Ground-Station@lists.openresearch.institute<br>> <a href="http://lists.openresearch.institute/mailman/listinfo/ground-station">http://lists.openresearch.institute/mailman/listinfo/ground-station</a><br>><br></div>