[aprssig] APRS Message character sets ?
scott at opentrac.org
Wed Jul 9 18:07:18 CDT 2008
> This is quite understandable in view of TNC2 interfaced systems with
> 7E1 type communication channel -- which is unable to pass thru any extended
> However, I have reasons to believe that igate systems with such connections
> are in rarity. There are large parts of the world where the ASCII is
I would like to hear your reasoning on that. One would hope that by now
most people would be at least running KISS, but sadly that's not the
case, at least not in the US.
Look back in the archives at the flame war that erupted a few years ago
when someone flew a dual-mode APRS/OpenTRAC tracker on a balloon, and it
started getting into converse-mode IGates (which also didn't pay
attention to the PID).
That episode also proved that FindU doesn't like 8-bit data. It kept
parsing packets as being 4 million miles from the south pole or
something like that.
Can you guarantee that 0x0d and 0x0a will never appear in the bitstream,
aside from valid end-of-line markers? That's all the APRS IS uses to
delimit packets - you can spoof it by putting a CR/LF in your packet
data and starting a new 'packet' with a TNC2-style header. If anyone's
running a converse mode TNC, it'll spoof their client as well.
My guess is that you're going to find that there's no acceptable
encoding scheme that won't break either UI-View or the D700, and with
the way the APRS community holds those two sacred, it's never going to
fly. At least not in the US.
Now, OpenTRAC was designed from the start to use UTF-8, but it's still
got a long way to go... =]
More information about the aprssig