[aprssig] Maximum APRS Packet Lengths

SARTrack Admin info at sartrack.co.nz
Tue Nov 29 13:00:37 EST 2016

Some years ago, when I changed my old compiler for a new one which uses 
Unicode strings, and I had to rewrite a lot of code, I had a discussion 
with Heikki 'Hessu' Hannikainen the developer of the APRSC and aprs.fi 
software about the APRS packet length problem:

Below are some snippets from this email conversation at the time, which 
may be of interest.

Hessu said:
> The APRS-IS max line length is 512 bytes, both javAPRSSrvr and aprsc enforce that. aprsc's testing suite validates that such long lines do pass through the server. RTFS:
> https://github.com/hessu/aprsc/blob/master/src/worker.h#L46
> https://github.com/hessu/aprsc/blob/master/src/incoming.c#L882
> If you have Unicode *text* you can UTF-8 encode that and get an UTF-8 encoded Unicode string. An 'ä' character having Unicode code point of U+00C4 is represented by two bytes, 0xC3 0xA4.
> <snip>
> In APRS, UTF-8 is used within text messages, beacon comments, etc, but only for the message content itself. The endpoint software UTF-8 encodes the message, then generates an APRS packet containing the UTF-8 encoded message, and then transmits that packet. aprsc, for example, does not display APRS messages to end users, so it does not need to do any UTF-8 encoding or decoding.
> <snip>

Bart said:
>> I have now added UTF8 encoding/decoding to the TCP interface... And this works perfectly when I use my own program, while testing on a 'aprsc' based server. Russian and other languages with 'funny' characters now come out correctly on the other side.
>> However, when I tested it with the APRS client 'AGWTracker', garbage came out.

Hessu said:
> I think both APRSISCE/32 (http://aprsisce.wikidot.com/) and YAAC (http://www.ka2ddo.org/ka2ddo/YAAC.html) do UTF-8 encoded Unicode messaging on the desktop.
> APRSdroid for Android (http://aprsdroid.org/) supports it too.
> aprs.fi supports UTF-8 just as well.
> You can transmit a 'hello' message to a callsign 'UTF-8' on the APRS-IS, I've got an autoresponder set up that will reply with a few messages containing UTF-8 encoded text, to see if your setup can receive international text.
> I think AGWTracker is the oddball one, using a fixed 16-bit unicode encoding (UCS-16? some Microsoft default internal encoding?), which requires the user to tick a checkbox to enable and disable it, depending on if they're messaging to another AGWTracker or not. If you send regular english text using that encoding to an old ASCII client, it won't work (every second byte is a binary 0 / NULL byte for these regular english ones). With UTF-8 we don't need to have a setting to enable/disable it, as UTF-8 and ASCII are compatible as long as you don't actually transmit characters outside the ASCII range. Even then, the old non-UTF8 clients will just print 2-3 characters of garbage for the ÅÄÖ and 日本語, and print English around them just fine. UTF-8 doesn't use NUL bytes at all, either. This is pretty much why UTF-8 has become the standard for most of the Internet - it works for latin characters even if you accidentally send UTF-8 to an ASCII-only recipient application.
>> I would like to know how other APRS clients deal with this issue, and what Encoding (if any) is being used to transfer Unicode APRS packets over TCPIP.
>> And how this type of data is dealt with, when it must be transfered over the radio, as this is obviousely ASCII/ANSI based...
> UTF-8 encoding is commonly implemented on APRS. It works great over radio, and even with old digipeaters and igates, since it's ASCII compatible (doesn't use NUL bytes, and 'high' >127 values are only used for the characters outside ASCII text range).
>   - Hessu, OH7LZB

So while the APRS packet has a limit of 255 bytes, the APRS-IS network 
works with a packet (line) length of 512 bytes, and this should leave 
enough room for Unicode packets.
SARTrack uses UTF-8 encoding in APRS, and will display for example 
Russian text perfectly. I do limit the text input to 67 *characters* 
(regardless how many bits they contain).

Looking at my source code (for the first time in years) it looks like I 
transmit the data into KISS frames in UTF-8 format...
But I never got any complaints from end users using Kenwood or Yaesu 
radios that it did not work correctly.
I am not sure what happens when you send a Russian text to a Kenwood 
radio though.


Bart Kindt
SARTrack Developer and CEO

More information about the aprssig mailing list