Order Tray | Contact Us | Home | SIG Lists

[aprssig] Is the APRS Spec for APRS Data Type Identifier just randomly ignored? Should it be?

Steve Dimse steve at dimse.com
Thu Aug 18 13:11:05 UTC 2005


On Aug 18, 2005, at 12:48 AM, James Washer wrote:

> I guess I'm just arguing for a STRICT interpretation of the spec. I  
> believe that if findu would display "ILLEGAL PACKET", possibly with  
> some text explaining what rule was broken, for any searches where  
> the packets were not in strict adherence, folks might start fixing  
> their configs. Most folks are probably mis-configuring out of  
> ignorance, and when they look on findu and find their station they  
> figure everything is good.

The error.cgi page is meant for a specific reason, as a page for  
people to go to look when their data isn't appearing on findU. For  
data parsed and displayed, findU's type checking is rather strict, a  
result of the use of regex in the parser. Going from there to an  
explanation of why a packet is bad is much more work, and not worth  
my effort. As to the specific telemetry issue, these packets are not  
that commonly used, and I've never seen someone sending telemetry  
that was mis-formatted, so again the return does not justify the effort.

If someone's position packet is wrong, they will not appear on findU.  
If someone sends some other sort of non-APRS packet, like a BEACON  
packet, that is simply ignored by findU. This is as I think it should  
be, I'm not going to make their position disappear because there is a  
non-APRS packet in the system. As I said, there are legitimate  
reasons why a beacon packet could appear on the APRS-IS.

> btw, I guess I should add that I believe that a packet "claiming"  
> to be a Telemetry packet that does not meet the requirements of a  
> telemetry packet is a BAD Telemetry packet, much as a packet that  
> claims to be a posit without the N/S fields is a bad posit.
>

Except it isn't a telemetry packet, it is a beacon packet that  
happens to start with the letter T. There is a very specific reason  
that letters and numbers are not used as type-id's, because they can  
be confused with beacon packets common in elsewhere in packet. T is  
an exception, because it was created outside of APRS by a TNC  
manufacturer. It would be nice if the spec said telemetry was T#,  
there is precedent for multi character TIDs, for example ! vs !!.

Steve K4HG





More information about the aprssig mailing list