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

[Michelle Thompson]

OK, I think I understand what you're saying here.

Thank you for the clear demonstration of the value of RTP multicast.

I think it can be translated, almost literally, into GNU Radio blocks. I
don't see anything quite like it as a block in GNU Radio right now.

We spent some of yesterday working with codec2 blocks in the lab. I don't
see Opus on the list of codecs in GNU Radio. I think it would be a great
addition.

-Michelle W5NYV



On Thu, Apr 26, 2018 at 11:47 AM, Phil Karn <karn at ka9q.net> wrote:

> On 4/25/18 10:00, Michelle Thompson wrote:
> > The ideal is to robust in the case of any (unpredictable) parameter
> update.
> >
> > Current design seems to assume voice.
>
> It doesn't assume anything. Only limitation is bandwidth, like any
> receiver.
>
> > Relying on RTP to paper over the missing data works for voice.
> >
> > It dos not work for other classes of signals.
>
> Not true. I'm specifically designing this to feed digital demodulators
> and signal recorders as well as audio monitors. The actual output of
> 'radio' is an uncompressed 16-bit PCM stream, which any digital
> demodulator would read directly; the Opus-compressed streams are for
> consumption by the human ear only.
>
> The most important thing for digital demodulation is to maintain a
> correct sample count despite packet losses so the demodulator doesn't
> see a sudden unexpected timing jump. I also want to maintain proper
> timing in a recording despite silence suppression (.g., a closed FM
> squelch).
>
> RTP's timestamp field is specifically for this purpose. I can emit the
> appropriate number of zero samples or flag an erasure or whatever the
> demodulator prefers. The timestamp can jump either because of a lost RTP
> packet or because of silence suppression but you can easily tell the
> difference; if a packet is lost there will be a gap in the sequence
> number but not in the case of silence suppression.
>
> I expect RTP packet loss or out of order delivery to be rare since the
> high data rate of uncompressed PCM will mean that demodulators are
> usually run on the same LAN as the receiver.
>
> All that stuff I put into 'monitor' for audio playout delay control is
> totally specific to audio monitoring by a human. It is not used for
> recording or digital demodulation since the RTP streams are read by
> different programs. The digital demodulators process RTP differently as
> they're not so concerned about minimizing delay. The 'iqrecord' program
> is especially easy; it simply uses the timestamp to seek into the file
> it's writing.
>
> I've already written a AFSK/AX.25 demodulator that reads the PCM output
> stream and emits AX.25 frames for other applications to process. Works
> great.
>
> > Being able to vary block size on the fly allows us to tune for latency.
>
> I still don't understand the concern here. I have been using this stuff
> almost continuously for months, for HF audio, VHF audio and AX.25
> packet. I have yet to feel the need to vary the filter blocksize on the
> fly. 20ms seems to suffice for everything, but of course it can be
> changed by restarting the receiver. If a real need to change it on the
> fly appears, I'll do it.
>
> > 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.
>
> My goal here is to prove the concept of multicast RTP for SDR module
> interconnection. My actual code is secondary, though I hope people will
> find it useful.
>
> Phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20180427/43b7d8b3/attachment.html>