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

[Lynn W. Deffenbaugh (Mr)]

If you're a programmer and are interested in the APRS protocol, 
especially compressed packets, you need to locate, download, and read 
aprs101.pdf.   That's the full protocol spec and is the key to 
understanding "evidently in reverse order" and "Clearly the translation 
must occur somewhere" and even "better checksumming".

On that latter note, APRS packets on RF are normally transmitted as 
AX.25 which includes a checksum, but once the packet is received by a 
TNC, that checksum is gone and the packets on the APRS-IS rely on the 
TCP/IP protocol for accurate transmission.

I haven't looked at any of the packets in question, but Mic-E compressed 
packets sometimes result in a non-printable character. If there's IGate 
software out there that is incapable of handling non-printables 
correctly, then it needs to get isolated and fixed, IMHO, because it's 
degrading the APRS network integrity.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


On 2/15/2014 12:12 PM, Paul Bramscher wrote:
> 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
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>