[hpsdr] PSK31 Demodulation and Standardization of Interface

[Jeremy McDermond]

I'm just throwing out some thoughts here.

==PSK31 and other digital modes==

I don't think we really want baseband audio into a PSK31 decoder if we can avoid it.  I think that FLDIGI and other people pull that baseband because it's all they can get.  PSK31 decoding shouldn't really be any different than CW Skimmer.  You want to see a waterfall, just like the default in most of our clients, and you want to click on a signal and see it decoded.  It's really no different than what you're trying to do with SSB.  You want to set a narrow filter around the signal (50 Hz or so).  You also want to watch the Q data, because all you're looking for is whether the phase has shifted since the last time you sampled (1/32nd of a second).  A phase shift should be fairly trivial to detect if you're seeing the raw I/Q data.  I have ideas of integrating a native PSK31 demodulator in MacHPSDR that will not require anything like cocoaModem or anything.  I think that something could be done similarly with RTTY.  Do I have a fundamental concept error here?

==Standardization of Interface==

I keep thinking about things about the "on the wire" interface between these components.  I guess I have some issues here because I really feel like we're re-inventing the wheel.  We should really be looking at RTSP and RTP for standards.  RTSP is your "command and control" and is extensible by "set" statements.  You can extend it to do anything you want really.  RTP is the transport which can ride over UDP, and the setup is controlled by the RTSP connection.  RTP is flexible enough that it can send different types of payloads.  We would have to set up a RTP type for "OpenHPSDR I/Q data", but that part of the spec is extensible.

There are some advantages to doing it this way in that firewalls and other network devices understand the protocol since it's essentially what's used as a streaming server standard on something like Darwin Streaming Server.  We can also do interesting things like proxy servers that are designed to pass RTP/RTSP stuff.  Also, for the straight audio stuff, you could actually have regular streaming clients pay attention to the server.  I'm planning on trying to experiment with this in my spare time.  I'm just really hesitant to come up with an entirely new spec just to repeat something that seems to be more flexible.

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com