[aprssig] Error checking within APRS packets

[Guido Trentalancia]

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 
model.

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 
> firenet.us).

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 
itself.

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.

Guido IZ6RDB