1
$\begingroup$

The APRS specification document says the following:

Although there is no restriction on the nature of user-defined data, it is highly recommended that it is represented in printable 7-bit ASCII character form.

What is the reason for this suggestion? Is it a matter of hardware/software compatibility and if so how relevant is this today?

$\endgroup$
  • $\begingroup$ Hello and welcome to ham.stackexchange.com! $\endgroup$ – rclocher3 Jun 9 at 23:12
3
$\begingroup$

So far as I know, nobody here is on the APRS Working Group, so it's difficult to say exactly what their motivations were, but I'll make a few guesses. First, Unicode was still fairly young in 2000, and personally I still have a horror of Windows code pages and other ugly mechanisms used to represent other character sets in hardware and software before Unicode came along. In those pre-Unicode days the printable ASCII characters, the ones represented by decimal numbers 32 through 126, were a sort of "lingua franca" understood by most hardware devices and operating systems, at least in the US. Many OSes and hardware devices couldn't tolerate character encodings that used more than one byte per character. Many OSes and devices used codes outside of the ASCII 32-126 range as control codes, so for instance if a file containing such codes was attempted to be printed, then one such code that happened to occupy a byte of the file might signal the printer to eject the page being printed and start a new page. Another such code might tell the printer to switch to its largest font. Such behaviors were device-, OS-, or software-specific, because for a long time there was no universal way to handle codes outside of the ASCII 32-126 range. Unicode existed in the year 2000, but its use was far from universal, and many OSes, devices, and software packages were completely ignorant of it.

I feel fairly certain that the motivation of the group was to minimize the confusion and incompatibility issues that were still common in the year 2000 with characters outside the ASCII 32-126 range. Also, all the members of the APRS Working Group had US call signs, and it's possible that some group members were somewhat ignorant of the need for other character sets by different languages and cultures.

Regarding how relevant the recommendation to use the ancient ASCII subset is today, I would say that how software and hardware should handle the user-defined data section is undefined. Many software packages still act strangely when asked to edit files with data of an unknown format in them, or print such files. So my advice would be to feel free to experiment, but be very careful to test as much hardware and software as you can before commonly sending packets with other character encodings in the user-defined data field out "into the wild".

| improve this answer | |
$\endgroup$
  • $\begingroup$ Just in passing, that "ancient ASCII subset" is also a subset of the Unicode code points. Every 7-bit ASCII code is a valid Unicode code and those codes represent the same character. $\endgroup$ – Pete NU9W Jun 10 at 12:16
  • $\begingroup$ I'm not concerned about compatibility with unicode or existing software, I only care that packets containing binary data do not get dropped or mangled by repeaters, can such a thing happen? $\endgroup$ – Noah McIlraith Jun 13 at 21:44
  • $\begingroup$ As I read the standard, anything trying to decode an APRS stream, from the internet or RF, will first try to separate packets by looking for the 0x7E ("~") delimiter characters, and then look to the first byte of the AX.25 information field. When the decoder sees the "{" character indicating user-defined data, then it will ignore everything until the two bytes before the "~" indicating the end of the frame. What this means to you is that your user-defined data had better not contain any "~" characters, or 0x7E bytes. If you follow that rule, then your packets should be handled correctly. $\endgroup$ – rclocher3 Jun 15 at 18:21
  • $\begingroup$ I was able to send a message containing solely ~ characters using direwolf. I wasn't able to test if it could be received because I was unable to figure out how to do an audio loopback on Linux. $\endgroup$ – Noah McIlraith Jul 19 at 15:42
  • $\begingroup$ I also found the following information which seems to imply that ~ gets escaped: "A packet starts and ends with a 0x7E Flag which in binary translates to 01111110. The six '1' bits in a row is a pattern reserved to inform the receiver/decoder about the packet boundaries. In any other case a series of five or more '1' bits is stuffed with an extra '0' bit before the remaining bits follow." $\endgroup$ – Noah McIlraith Jul 19 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.