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

[Michelle Thompson]

The ideal is to robust in the case of any (unpredictable) parameter update.

Current design seems to assume voice.

Relying on RTP to paper over the missing data works for voice.

It dos not work for other classes of signals.

Being able to vary block size on the fly allows us to tune for latency.

We have an opportunity to craft some very useful code that takes full
advantage of modern SDRs and current DSP techniques. There are a lot of
other parameters besides filter stuff.

The challenge to you, and everyone else here, is to craft a general, not a
specific, solution.

Please give this some thought.

Let's see what we can all do about it, together.

-Michelle W5NYV



On Mon, Apr 23, 2018 at 11:26 PM, Phil Karn <karn at ka9q.net> wrote:

> On 4/23/18 17:41, Michelle Thompson wrote:
> > The parameter update issue is a general-case design issue. It is
> > important. Please think about it some more.
>
> I think there's been some misunderstanding. **EVERY** filter parameter
> can **ALREADY** be updated as frequently as once per FFT block, which is
> typically 20 ms. That includes the frequency response and window shape
> factor.
>
> The only thing that can't (yet) is the length of the FFT block itself.
> That requires so much reinitialization, and I had so little need for the
> feature, that I just restart the program when I have to do it. Which is
> about never.
>
> Frequency mixing is in the time domain, so it can change on a per-sample
> basis. Which it does when Doppler steering is in effect.
>
> Remember, it's all just RTP streams. If the program restarts fast
> enough, you may not even notice the interruption (though the RTP stream
> ID will change unless you make it the same). One easy way to implement
> this is to simply have the program exec() a new copy of itself with the
> new parameters. I'll probably hook this onto a command to load a state
> file (which normally happens only at startup).
>
> I'm writing this package mainly as a proof-of-concept for RTP and
> multicast in distributed SDR implementations. If my actual code is
> useful to somebody, so much the better.
>
> It was the same with my TCP/IP software in the mid-late 1980s; I wrote
> it as a proof-of-concept for those protocols over ham packet radio, and
> it turned out that the software had other uses. Until it was replaced by
> Linux, which is what should have happened.
>
> > RTP/multicast and Opus features are things I want to fold in to our GNU
> > Radio implementation.
>
> Since this invokes interoperability issues, this is where we need to
> nail things down.
>
> The RTP AVP (Audio-Video Profile) already defines static payload types
> for 48 kHz 16-bit PCM, one for mono and one for stereo. The samples are
> sent in big-endian order (like all IETF standards) despite big-endian
> CPUs being nearly extinct. I flip the bytes on both ends just to be sure
> I'm compatible.
>
> Opus is a more of a problem. After assigning a whole bunch of static
> payload types to now-obsolete codecs, the powers-that-be decided to stop
> assigning payload types altogether and require that they be dynamically
> established with the Session Description Protocol (SDP). (As the saying
> goes, every problem in computer science can be solved with yet another
> layer of indirection).
>
> Unfortunately, this happened before Opus was standardized, so even
> though the IETF wants to promote Opus as *the* standard audio codec,
> they've made it harder to use than the old fashioned codecs it's
> supposed to replace.
>
> So to force VLC on my iPad to play it, I have to write a short SDP text
> file, serve it up on some local web server, and  point VLC at it. Then
> it will join the multicast stream and decode Opus. All that extra work
> and points of failure just to set one number that shouldn't need to be set.
>
> My 'monitor' program doesn't need SDP because I use the fixed value of
> 111 on both ends. It *seems* be some sort of unofficial convention, so I
> chose it.
>
> Lastly, there's I/Q data. I know about VITA-42 (?) but I took one look
> and the horrible CCITT/ISO/OSI flashbacks to the 1980s began. (Bob knows
> of what I speak.)
>
> This is totally nonstandard so obviously there won't be a static payload
> type for it. But that's actually less of a problem because we're not
> trying to interoperate with anybody; we control both ends and consenting
> Internet hosts can do whatever they want. My RTP format looks like this:
>
> RTP Header (standard), PT = 97 (arbitrary, in dynamic space)
> custom SDR status header
> 16-bit I sample
> 16-bit Q sample
> 16-bit I sample
> .......
>
> The samples are in little endian format because, again, they don't have
> to be big-endian. The custom SDR header looks like this:
>
> struct status {
> long long timestamp;
> double frequency;
> uint32_t samprate;
> uint8_t lna_gain;
> uint8_t mixer_gain;
> uint8_t if_gain;
> uint8_t pad;
> };
>
> Essentially the same format is used in unicast UDP packets back to the
> I/Q sender to control the device (though some fields can't be changed.)
>
> The timestamp is a little-endian integer count of nanoseconds since the
> GPS epoch of January 6, 1980 at 00:00:00 UTC. This will wrap in 584
> years from 1980. This timestamp comes from the original source, so you
> can play back an I/Q recording and see the original time in the 'radio'
> display. That's its main use; internal SDR timekeeping is all done by
> counting samples, so it is only as accurate as the FCD A/D clock.
>
> I feel *very* strongly that UTC should not be used for internal
> timestamps. Nor can UTC be correctly represented as a single number, as
> UNIX traditionally tries to do. That's fundamentally broken.
>
> After I did this, I discovered that NTP has its own internal time format
> consisting of two 32-bit integers counting full and fractional seconds
> since Jan 1, 1900 UTC, which is almost 60 years before UTC even existed,
> and long before atomic clocks that could nail down such an early epoch.
> It will roll over in 2036. And NTP follows UTC, so it jumps every time
> there's a leap second. In other words, I think Dave Mills made a major
> mistake here, and I even told him at the time. But he actually enjoyed
> watching the transient response of hundreds of NTP hosts to an abrupt
> jump in time.
>
> Because my timestamps are in GPS time, you can get it from a local GPS
> receiver, which indicates the UTC-GPS offset, or from UNIX system time
> (via NTP) and a leap second table -- which I've already done. I prefer
> the first approach. GPS receivers are now cheap commodity devices.
>
> The frequency is a double precision float giving the center frequency of
> the I/Q stream, i.e., the local oscillator frequency in a zero-IF
> receiver front end.
>
> The sample rate is the *nominal* A/D sample rate, uncorrected for any
> oscillator error (which the sender doesn't know anyway; that's corrected
> by the I/Q consumer, e.g, 'radio').
>
> lna_gain, mixer_gain and if_gain are specific to the FCD, though I
> believe a bunch of zero-IF SDR front ends are using the same tuner chip.
> The first two take the values '1' or '0' to indicate whether the
> corresponding amplifier is on or off.
>
> if_gain is an integer between 0 and 59 giving the gain of the baseband
> amplifiers in dB between the quadrature mixers and the A/D converters.
> The FCD already has so much front end gain that I always leave this at
> zero, as recommended.
>
> These values can change at any time, which is why they're included in
> every packet. In fact, 'radio' won't even start up until it gets the
> first I/Q RTP packet because it doesn't yet know the A/D sample rate,
> and virtually every initialization needs that.
>
> The FCD has a wide dynamic range so 'radio' doesn't even have a way to
> set them right now, though the protocol allows for it. The 'funcube'
> program that talks directly to the FCD will change the LNA and IF gain
> settings as a strictly defensive measure when an overload is detected.
> This happens in two steps: first IF gain is reduced, then if more
> reduction is still needed, LNA is turned off. If either is off when the
> level falls below a lower threshold, they're turned back on in reverse
> order. I only see this happen on local TV and radio stations.
>
> I strongly resisted putting hardware-specific fields in here. I really
> wanted the header to convey the actual conversion gain in dB (i.e., the
> output level in dBFS for an input level in dBm) but that turned out to
> be impossible. I measured the gain of the FCD and it varies enormously
> over its coverage range. The mixer amplifier is always 19 dB, and the IF
> gain steps do seem accurate, but the LNA can range from hardly more than
> 1 dB up to over 20, and the big bank of switchable preselectors didn't
> help matters.
>
> Phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20180425/bd280426/attachment.html>