[aprssig] APRS Message character sets ?

[Scott Miller]

> This is quite understandable in view of TNC2 interfaced systems with
> 7E1 type communication channel -- which is unable to pass thru any extended
> characters.
> 
> 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... =]

Scott
N1VG