[aprssig] "no sym yet" icon + compressed packets?
pfbram at comcast.net
Sat Feb 15 17:14:17 EST 2014
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
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
Might be handy if some of these APRS web sites offered a "really raw"
version of the messages, encoding non-printable characters for debugging
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:
>>> 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
>> 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
>>> 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
>> Paul / KD0KZE
>> aprssig mailing list
>> aprssig at tapr.org
> aprssig mailing list
> aprssig at tapr.org
More information about the aprssig