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

[Paul Bramscher]

Hi Lynn--

Thanks again for APRSISCE.  I've recently downloaded the APRS spec. PDF,
but haven't had a chance to read it carefully.

(By means of disclosure: I work LAMP-stack programming, typically layers
5-7 in the standard OSI model.  We don't usually do field-specific
encoding -- i.e. where an encoding method is coupled to a particular
field.  In RDBMS' we build normalized tables of reserved
vocabulary/relationships, linked by keys.  Or compress data with a
uniform mathematical compression method.  TCP/IP does a good job of
separating transmission details out of that world.  I don't know the
history of AX.25. but understand it's considered a lower-level data link
layer.  Perhaps it would be simpler if its functions had originally been
split into 2-3 layers...)

Anyway...  I see on p. 53 the example decoding "j/" = Jeep does suggest,
albeit indirectly, a reverse order.  (Took me awhile to find an example).

Maybe this points toward flaky iGate software.  I once downloaded UISS
and played with a bit, but my copy seemed to have some malware in it, or
perhaps it was another package I was also using at the time, so I
abandoned it.

Perhaps it is the non-printables.  I can't be guaranteed I'm actually
seeing the "raw message" on these web sites.  In my LAMP work, we
usually store data back-end in unicode, and strip out problematic
characters when handling HTML for human-viewing through a browser -- or
encode for XML delivery.  For binary/BLOB data, we'd probably offer a
download option.

Might be handy if some of these APRS web sites offered a "really raw"
version of the messages, encoding non-printable characters for debugging
purposes.

Regards,
Paul / KD0KZE

On 2/15/2014 11:18 AM, Lynn W. Deffenbaugh (Mr) wrote:
> 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
>>
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>