[aprssig] "no sym yet" icon + compressed packets?

[Paul Bramscher]

Greetings--

> 1)   The symbol set in use by another station has NO effect on the
> symbols YOU see.   All that is transmitted is a two-character control
> code that tells the other station(s) what symbol position in his symbol
> set to select and display.

Yes, I'm aware of this.  In the raw data reported to ariss.net, I see this:

KD0KZE>TUPX9R,RS0ISS*,qAR,K0GDI-6:'yaIl -/]Greetings via ISS from Circle
Pines MN=

The "-/" 2-character portion before the right bracket indicates the
'Home' icon, though evidently in reverse order.  I switched to satellite
dish once, and saw that 2-character code appear instead (reverse order
again, if I recall correctly).  If you browse other peoples raw messages
in compressed format, who have different icons selected, I believe
you'll find their codes also -- and in reverse 2-character order.

> What you see in response to that control code is entirely dependent on
> the graphic images stored on YOUR computer or device.

No, the ariss.net and other websites dynamically load a graphic icon/jpg
on their servers in relation to what it thinks is the correct match.
Certainly, desktop apps like ARPSISCE/32, etc. would load graphics
internally from within the desktop app itself, but that's not where I'm
seeing the problem.  This between an igate and t2 server, just before
the server-side scripts on common APRS/mapping websites try to make
sense of it.

> If your station symbol is coming up wrong, then somewhere along the
> transmission path (ISS digipeater, igate station, etc), the symbol
> control characters in your packets are getting mangled.

Yeah, it seems to be (a) this particular station, and (b) when he's
reporting compressed-format packets.  At least, that's the pattern I'm
seeing.

> Igate software translating Mic-E is a vestige of another era, decades
> ago, when not all APRS client software knew how to decode Mic-E. Today,
> there is NO reason for igates to be translating packets, since all
> current APRS software now knows how to deal with Mic-E packets.

Clearly the translation must occur somewhere, on the server-side scripts
running ariss.net, etc. so it can map those to GPS coordinates for
map/Google display.  (I'm a programmer by trade myself.)  There's a
failure pattern.  Probably stripping out a control-character, or
otherwise mangling something inadvertently.

Perhaps what's missing here is better checksumming.  If an igate can't
understand packets, whether due to poor RX/conditions or due to a
logical error it shouldn't forward the receipt of the packet to an
aggregating server.

What's curious is that it apparently can deal with the GPS coordinates
correctly.  Seems to be limited to handling the icon 2-char representation.

Regards,
Paul / KD0KZE