[QUESTION] TNC incompatibility with other projects

[M0IGA]

I have used RNode as a TNC for APRS, I use also T-beam v1 with SQ9MDD sot. TNC. I found the packets from both TNCs are incompatible to each other. Moreover, RNode's packets are incompatible with other aprs over LoRa projects too.

The aprs frame sent by Xastir via RNode TNC [2022-12-18 20:25:08] [-23 dBm] [SNR 10.75 dB] [45 bytes]
b'\xa0\x82\xa0\xb0dbp\x9a\x92\x8e\x82@`\xae\x92\x88\x8ad@e\x03\xf0=5452.39N\00121.80Wz\r'

The aprs frame sent by Xastir via SQ9MDD TNC [2022-12-18 20:25:37] [-24 dBm] [SNR 13.5 dB] [45 bytes]
b'<\xff\x01M0IGA>APX218,WIDE2-2:=5452.39N\00121.80Wz\r'

Why these are different and which one is correct?

[markqvist]

I don't think one of the other is "correct", as such, it is just two different ways of doing things. One thing I would say though, is that the other implementation is a bit wasteful, since it (for some reason) encodes the AX.25 PATH components (APX218,WIDE2-2) as plain ASCII characters, instead of the more efficient 7-bit ASCII encoding dictated by part 3.12 of the AX.25 link-layer specification. So if you really want to go out on a limb, you could say that the RNode implementation is more "correct", since it actually follows the AX.25 link-layer spec encoding guidelines.

I haven't looked at the code for these other projects directly, but I'd venture a guess that these other projects simply transmit the TNC frames directly, within single LoRa frames.

Doing it like this gives you a maximum payload of 255 bytes, which is pretty low. You can fit simple applications like APRS into that ok (several early or simple TNC designs actually only support MTUs of around 240-256 bytes).

RNode uses a simple and efficient PHY layer implementation, that allows it to use multiple LoRa frames to acheive a packet MTU of 508 bytes. This makes it possible to do a lot of other things, like using RNodes with Reticulum, for TCP/IP communication, and for more advanced Amateur Radio TNC applications, that require a larger packet size than the very limited 255 bytes.

This approach spends 2-bytes per (508-byte) packet for headers allowing this, but on the other hand, in comparison with the other example you posted above, it also saves those 2 bytes again (which would be more for longer paths), since it correctly encodes the path components.

If there is any interest from other projects, I will be happy to formally document and describe the RNode LoRa PHY, and provide an example implementation in C. It's already in the RNode Firmware source code, but if it can make it easier for anyone to implement it in their own projects, I'd be happy to describe it in more plain language, to make it easier to make other compatible TNCs.

[markqvist]

By the way, those "extra" header bytes you see when using LoRaMon is part of the PHY layer protocol, and are of course stripped from the frame when delivered to the host application, so Xastir (or whatever else), will see the pure AX.25 frame, as they should. You are only seeing them because you are doing raw monitoring of the actual physical frames :)

[M0IGA]

Thanks for the explanation. You can close the topic.