Close

Arduino KISS interface

A project log for digital-walkie-talkie

long range, low power, modular

Christoph TackChristoph Tack 11/07/2021 at 19:290 Comments

Trying to avoid to reinvent the wheel, so I found some KISS sources:

A lot of time and effort has been put in these firmwares, but...  For implementing a KISS interface, shouldn't the code be KISS as well?  These source codes are not simple (relying on AFSK and/or AX.25) makes the class complicated and hard to port to other platforms or tool chains.  The firmwares are not for the stupid either.  The Mobilinkd C++ code may be beautifully written, but it's hard to read for novice C++ programmers.

So I'll need to write my own code based on the PacketSerial and HamShield_KISS libraries while adhering as much as possible to the KISS-"standard".

Android

As mentioned elsewhere, instead of implementing all functionality in a single device, I'll offload functionality to an Android device.  These apps are already there, so why not use them?  Why would I decode Codec2 samples in the ESP32 when there's already an Android app that can do that for me?

The only thing needed is a KISS-TNC interface and a Bluetooth serial port to talk to these Android apps.  This is not so hard to do.

Codec2 Talkie

I have tested my KISS-TNC code with the sh123 android app to send and receive Codec2 speech samples.  Codec2 samples sent by the ESP32 were correctly decoded and output on the Android app.  I've also off-line decoded Codec2 samples that the ESP32 received from the Android app.

Aprsdroid

Sending voice with Codec2 Talkie is one thing, but it would be nice to have a messenger application with the added bonus of sharing location info.  That is what Aprsdroid can do for us.

I'll mention Ripple Messenger (and LoRa Qwerty Messenger) here as an alternative, but that application looks like a single person project.

APRS uses only a subset of the AX.25-framework.  And Aprsdroid in its turn only uses a subset of the APRS-protocol.  So we can suffice by only implementing a very limited set of the AX.25-framework.
Moreover, the data we receive over the KISS-interface doesn't carry flags, has no checksum and isn't bit-stuffed either.  This also saves us a considerable amount of work.

Unfortunately, the APRS-protocol is a real mess.  It seems like the standard has been written after the fact, trying to match the standard to different applications already seeing field use.

Settings for Aprsdroid to communicate with our TNC. (cdn.hackaday.io/images/5671441640889476886.jpg)

Location reports

AX.25-frame, received as Data Frame by our KISS-TNC :

0x82 0xa0 0x88 0xa4 0x62 0x6c 0xe0 0x9c 0x60 0x86 0x82 0x98 0x98 0x61 0x03 0xf0 0x3d 0x30 0x31 0x30 0x30 0x2e 0x30 0x30 0x4e 0x5c 0x30 0x30 0x32 0x30 0x30 0x2e 0x30 0x30 0x45 0x29 0x20 0x68 0x74 0x74 0x70 0x73 0x3a 0x2f 0x2f 0x61 0x70 0x72 0x73 0x64 0x72 0x6f 0x69 0x64 0x2e 0x6f 0x72 0x67 0x2f 

Decoded by AX.25 Frame Generator :

Source & SSID: N0CALL-0
Destination & SSID: APDR16-0
PID : 0xF0 (no layer3 protocol)
CONTROL : 0x03 (UI Frame)
Payload: =0100.00N\00200.00E) https://aprsdroid.org/

We can also send our own location reports to Aprsdroid:

cdn.hackaday.io/images/4244511641152187114.jpg
cdn.hackaday.io/images/5451181641152204611.jpg
Fooling Aprsdroid by letting it know that we're in Ushuaia.(cdn.hackaday.io/images/5451181641152204611.jpg)

Text message

More info can be found in the APRS-specification, chapter 14.  Aprsdroid expects messages to be acknowledged, hence the '{' followed by a number at the end of the message.

AX.25-frame, received as Data Frame by our KISS-TNC :

0x82 0xa0 0x88 0xa4 0x62 0x6c 0xe0 0x9c 0x60 0x86 0x82 0x98 0x98 0x61 0x03 0xf0 0x3a 0x4e 0x31 0x43 0x41 0x4c 0x4c 0x20 0x20 0x20 0x3a 0x48 0x65 0x6c 0x6c 0x6f 0x20 0x77 0x6f 0x72 0x6c 0x64 0x7b 0x35 

Decoded by AX.25 Frame Generator :

Source & SSID: N0CALL-0
Destination & SSID: APDR16-0
PID : 0xF0 (no layer3 protocol)
CONTROL : 0x03 (UI Frame)
Payload: :N1CALL   :Hello world{5

AX.25 References

Discussions