[aprssig] Error checking within APRS packets
iz6rdb at trentalancia.com
Sun Jun 26 14:48:04 EDT 2011
Hi Lynn !
On 26/06/2011 15:35, Lynn W. Deffenbaugh (Mr) wrote:
> On 6/25/2011 11:42 AM, Guido Trentalancia wrote:
>> I can only add in some way that it's still risky to do that. Have you
>> checked all possible TNCs being used nowadays ? Is there a standard
>> for TNCs ?
> Unfortunately those answers would have to be "not possible" and "not
> even". There is some level of apparent standardization across some
> TNCs, but when you get down to the details, there's no one standard.
> KISS comes close, but then there's SMACK (KISS with a CRC,
> http://www.symek.com/g/smack.html). SMACK is supposed to be
> backward-compatible with KISS implementations, but in my experience
> not all SMACK implementations quite make it.
> And as for find out what TNCs are still in use, it might have been
> possible if TNCs actually put some sort of identifier in their
> transmissions, but many don't.
I would not like a TNC that spontaneuously identifies itself by placing
a signature in its transmissions.
It would be similar to a phone call where the carrier spontaneuously
introduces a short message with its name (imagine "this is AT&T", "this
is Sprint" or "Verizon is handling this call").
Or this laptop placing a field in this email message with its brand and
As long as the TNC can be interrogated from the user side when needed,
that should be enough for most situations...
> My APRSISCE/32 client uses every trick and signature that I've been
> able to discover to figure out what the software or hardware is that
> is generating the packets for a station, but it still comes up with
> 8,352 (43%) "Generic" and 442 (2.2%) "Unrecognized" out of the 36,700
> stations that have been active in the past 2 hours (including CWOP and
Why do you care about that ? As long as it conforms to AX.25... The user
can configure the TNC separately or at least transparently.
> Just like Microsoft, we're constrained by backward compatibility
> until/unless we're ready to take the hit of a total disconnect and
> even then, I think substantial research needs to be done to determine
> and document the effects on the "obsolete" platforms.
It should still be possible to do it with little risk. As long as there
are no (multiple) interactive connections ongoing, there should be no
need (for anything or anyone) to switch the stream. Or at least, this is
my understanding (consider I do not have such a TNC, as the Kenwood
TM-D710 uses 0x01 by default, and I have never used that function
anyway). And usually for APRS, one TNC is exclusively devoted to APRS
The advantage it would bring is remarkable. And the risk is low because
it is a feature that is not commonly used in that context (see above)
and because most TNCs nowadays should be configurable. One could still
try sending out (with a modified radio or software) a bulletin
containing that character and see what happens... Most setups will
probably discard the bulletin but at the APRS level (after the sending
and receiveing TNCs have passed it out successfully).
If anyone is interested in looking up and verifying the details for
Kenwood (and other) TNCs, it's command STREAMSW. By the way, it needs
another character afterwards as a stream designator.
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
> PS. This message is not intended to state my position on change,
> neither for nor against, but simply to answer the questions within the
> realm of my personal experience.
More information about the aprssig