Support M17 Packet Mode #529
Comments
|
As I understand it, M17 is a digital voice codec project which very different from Direwolf which is a digital data project. I see on https://m17project.org/get-started/hardware where it states some TNC projects have added M17 but of those solutions are either just USB attached sound devices (irrelevant) or are Bluetooth TNCs attached to the computer (probably then using the bluetooth "headset" profile instead of the normal "serial data" stream profile, etc. If you would, please add some detail why you think adding digital voice to a data centric project like Direwolf that focuses on AX.25, APRS, APRS-TT, AIS, and IL2P makes significant sense. Giving some specific use cases would be helpful. |
|
M17 specification allows encapsulation of several data protocols like
AX.25, APRS, 6LoWPAN, IPv4, SMS, Winlink.
This allows using existing RF-based MMDVM repeaters to establish data
links.
IPv4 RF links enable support of applications only available to run over IP
and explore their possibilities in an amateur radio network. Linking AREDN
sites using non-microwave devices is a possibility.
Also, it could be used simultaneously with voice data, at a lower data
rate.
El mié, 22 may 2024 a la(s) 11:55 a.m., David Ranch (
***@***.***) escribió:
… As I understand it, M17 is a digital *voice* codec project which very
different from Direwolf which is a digital *data* project. I see on
https://m17project.org/get-started/hardware where it states some TNC
projects have added M17 but of those solutions are either just USB attached
sound devices (irrelevant) or are Bluetooth TNCs attached to the computer
(probably then using the bluetooth "headset" profile instead of the normal
"serial data" stream profile, etc. If you would, please add some detail why
you think adding digital voice to a data centric project like Direwolf that
focuses on AX.25, APRS, APRS-TT, AIS, and IL2P makes significant sense.
Giving some specific use cases would be helpful.
—
Reply to this email directly, view it on GitHub
<#529 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALECID7GOJCY3KAA3RXJZDZDSWX5AVCNFSM6AAAAABICQAJRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGAYTCNZTGM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I would like to second this request. M17 specification has a distinct Packet Mode, and Mobilinkd has implemented it in both TNC4 and the NucleoTNC. |
|
Honestly, i was about to make the same post, but here it is, so I'll second/third the M17 request. This has nothing to do with voice. M17 supports APRS. M17 uses modern FSK vs the increasingly old 1200baud two-tone mark/space. M17 could work in parallel with the 1200baud modes on the same frequency. By my own observations, the M17 packets are smaller/tighter. Everything would remain the same, we would be adding a second (de)modulator to the existing direwolf. I'd like to come up with a proposal for the APRS Charity, adding M17 to the APRS specification. I can standup a dual 1.2K/M17 hybrid digipeater in Northern California for testing. -craig |
|
KISS M17 info: https://m17-protocol-specification.readthedocs.io/en/latest/kiss_protocol.html Also the Mobilinkd TNC4 natively supports an M17 KISS interface. |
|
I just wanted to chime in on one of Craig's points: "M17 could work in parallel with the 1200baud modes on the same frequency" Running incompatible data modes on the same frequency is a mess and it's been tried before. Legacy TNCs won't recognize that an M17 transmission is present and transmit on top of it which will destroy both packets. I imagine the reverse situation is similar and since APRS packets use UI / un-connected packets, all packets won't be re-sent. Many areas in the US have alternative or secondary APRS frequencies in their band plans to use "APRS" or experimental modes. --David |
|
If you search the APRS and AX.25 protocol specifications ( see latest in https://github.com/wb2osz/aprsspec ) you will find no mention of a specific type of modem. 1200 bps was used initially because a group in Canada got a pile of surplus Bell 202 modems dirt cheap. The tradition continued because it was easy to implement with 1970s technology. 9600 bps (G3RUH?) was developed in the 1980s and was included in some legacy TNCs. Kenwood radios, Yaesu radios, and software TNCs support it. Three TNC manufacturers in the previous century had 2400 bps QPSK which is now supported in the leading software TNCs. It works great even with pre-emphasis and de-emphasis distorting the audio. Direwolf 1.8 (currently the "dev" branch) now allows a channel to be mapped to an external TCP KISS network TNC. This was developed initially for use with LoRa APRS but should work with M17 or anything else that supports KISS over TCP. This allows direwolf to perform digipeating to same channel, digipeating from one channel to another, and IGate functions for a simple KISS TNC. Modem experts can concentrate on making better modems and not have to reinvent all the other stuff. You can find details at https://github.com/wb2osz/direwolf-doc/blob/main/APRS-LoRa-VHF-APRS-Bridge.pdf I agree with David's comment that running different modes/speeds on the same busy channel for APRS would create a mess with everyone transmitting on top of other modes/speeds. However, it would be a nice feature for a packet BBS on channel with little activity. The BBS would listen for multiple modes/speeds and respond with the same one. Does this help? |
|
Are there any M17-KISS-TCP TNC's out there? Mobilinkd TNC4 does M17-KISS but it's over bluetooth, I suppose I could make a bluetooth/TCP/netcat bridge for testing purposes. Direwolf has two modulation modes now, 1200 and 300, are those hard-coded, or could M17 be added as a third? I still think we can do mixed-mode APRS on the same frequency provided we have collision detection If we don't, APRS will not evolve and eventually die on the existing frequencies. I don't think we can get critical mass on a new frequency. All HT and mobile units use COS (open squelch) to avoid collisions, so the Yaesu's and Kenwoods are already good to go. That leaves software TNC's which have no choice but to use DCD (data carrier detect) to avoid collisions. Once the vast majority of software TNC support combined M17 and 1200 DCD, we're ready for hybrid APRS networks imho. thanks guys! |
|
I'm only aware of the Moblilinkd unit so far when it comes to a hardware device supporting M17. When it comes to supported mode, it's actually more like DIrewolf does 300 & 1200 which are AFSK, 2400 and 4800 which are PSK, >=9600 are FSK for packet. Then Direwolf also supports AIS using GMSK. It's worth noting that Direwolf 1.8's new external bridging concept work with other TNCs like LORA ( https://github.com/wb2osz/direwolf-doc/blob/main/APRS-LoRa-VHF-APRS-Bridge.pdf ). That all said, I imagine M17 data mode could be added/linked to Direwolf and it would work but is that the best thing to do? Compare that to say the ARDOP modem used with tools like ARIM/gARIM and other tools as it has a very different communication protocol. IMHO, it's less powerful than AX.25 but AX.25 also has a lot of limitations. AX.25 v2.2 + FX.25 goes a long way to modernize it but I think something better can be done. Doing it right will be very disruptive, will take a very long time to adopt but it's the best thing to. I think one good example of this is VARA though it still uses FM-radios which actually hurts it's performance. To your point about COS, that won't work for multiple reasons. 1)modern data modems don't use FM modulation.. they use variety of other options (look at DMR, LORA, etc). Next, AFSK packet doesn't use/care about COS, it uses the HDLC preamble to "detect the presence" of a valid packet (aka DCD) and nothing else. This is the #1 IMHO reason why you cannot mix different modes on a packet frequency without creating harm as all the currently deployed TNC on the planet will have no clue about the RF frequency being in used by this new M17 thing. Next, the KISS protocol does NOT have any way to convey details about the RF world such as the frequency is busy so that badly hurts legacy TNCs + external computers running the AX.25 stack and all it's various protocol timers running. To me, the best way to potentially solve this scenario is to use an SDR listening on different frequencies for AFSK packet, M17, etc. and when it's time to transmit, give Direwolf the ability to QSY the TX radio to the correct frequency, pick the correct mode(s), and transmit. It's only the lack of QSY support that Direwolf doesn't natively support today but I don't think it would be hard since it already supports HamLib. |
There is the NucleoTNC, which is open source and available on github. Basically, it is from Mobilinked creator Rob Riggs aka WX9O, a version of TNC3, without BT and without the battery. Both hw and sw are open sourced. |
|
It would be cool if serial port would be also supported for incoming KISS TNC connection, not only TCP. It would make it easier to use Direwolf together with external KISS modems like Mobilinkd TNC and use Direwolf as a KISS serial->AGWPE TCP bridge. Baofeng -> Mobilinkd TNC -> bluetooth -> /dev/cu.usbmodemXXX -> direwolf -> AGWPE TCP 8001 -> Pat |
It would be great if direwold supports the M17 project.
The text was updated successfully, but these errors were encountered: