Enhancement: more than one baud rate

[kb9mwr]

It would be nice to see a software TNC that can support more than one over the air baud rate at the same time. A couple of us have been thinking about trying to go a little more faster than the good old 1200 baud (as 4800 sounds easily doable), the problem is then you have alienated yourselves from everyone else.

Something where a decoded X baud packet can be automatically responded to at that corresponding rate, and thus supporting more than one rate.

[wa7nwp]

The NWDR Draws folk have been using DIREWOLF for multiple speeds for several years now. They claim it should work even up to 19200....

On Tue, Jul 7, 2020, 1:40 PM kb9mwr notifications@github.com wrote:

It would be nice to see a software TNC that can support more than one over the air baud rate. A couple of us have been thinking about trying to go a little more faster than the good old 1200 baud (as 4800 sounds easily doable), the problem is then you have alienated yourselves from everyone else.

Something where a decoded X baud packet can be automatically responded to at that corresponding rate, and thus supporting more than one rate.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wb2osz/direwolf/issues/286, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJJ5357UBOGF6JE3TWJGTLR2OB4DANCNFSM4OTSKFYA .

[dranch]

I looked on NW Digital's website but it seems they migrated their wiki to a Groups.IO hosted interface. I cannot find their steps of how to support different packet modems on the same RF channel on the new interface. If I remember correctly, this method uses ALSA's .asoundrc mechanism. It would be good if this can be added to the Direwolf UserGuide or a new Direwolf support document.

[wb2osz]

I have not yet done this myself, but I think this is how it works. You set up two audio interfaces, connected to the same radio, and each one has a modem for a different speed. Something like:

ADEVICE0 plughw:2,0 CHANNEL 0 MODEM 1200 PTT GPIO 24

ADEVICE1 plughw:3,0 CHANNEL 2 MODEM 9600 PTT GPIO 24

So if something comes in on channel 0, you know it was at 1200 bps. An application could then respond on channel 0 and it would go out at 1200 bps. Or if it comes in on channel 2, you know it was at 9600 bps. An application could then respond on channel 2 and it would go out at 9600 bps.

Instead of two physical audio interfaces, you can perform some ALSA magic so that one physical device can be accessed as two virtual devices. Like a Y splitter cable.

I think this would be a very bad idea for APRS. The modem carrier detect only recognizes its own speed so stations would be stepping on each other.

However, I think it would be good for something like a BBS or Winlink server where you probably wouldn't have a bunch of people using the same frequency at the same time.

So, I think it basically comes down to a documentation effort. If we get serious about this, we could come up with a way to link data carrier detect (DCD) signals from multiple channels so transmit would not stomp on someone else transmitting with a different speed.

[guitarpicva]

In other waveforms (such as M110) this is called "auto-baud", and the waveform itself actually encodes in its preamble what data rate it is sending along with the interleave setting, and in some cases content type of the data (like digital voice). That waveform does so because its baud rate is fixed at 2400 baud for all data rates.

In any case, the knowledge of the data rate allows software to then reply at the same rate by commanding the modem to switch data rates before transmitting. This pre-supposes that the modem will send some sort of "indication" to anyone registered for it when the data rate is known of the latest reception. I call it "Track Data Rate" in my software implementations which make use of M110.

This is a good use for MQTT actually, at the local level (vs. OTA, but not limited). I am presently implementing an MQTT managed system that I intend to insert Direwolf into. So to give you an idea:

On a reception, the modem might publish

modem/recv_data/IL2P/2400 : This is the data I just received via IL2P -- OR -- modem/recv_data/AX25/1200 : This is the data I just received via AX.25

If using MQTT to direct the modem for transmit

modem/send_data/IL2P/2400 : This is the data I wish to send back the other way.

This could be a replacement for KISS and AGW as a more industry standard methodology for message passing. There are MQTT brokers for every major language now. The mosquitto broker supports websockets also, so the web browser as a UI is on the table. Mosquitto even serves static html/css/js as well.

Something like this would require that the modem be able to change baud rate on the fly as it processed each send_data request sequentially. It might also introduce a little latency in replies, but for APRS that's not a problem. For connected AX.25 it might be a little problematic due to timeouts in the ARQ session. For the fullest-featured experience, the modem would want to be able to simultaneously decode any of the 3 types of transmissions it can produce.