You say this hit your APRS IS parser? The third party format is not
supposed to appear on the APRS IS. I doubt this is the case because I
do not see any APRS IS info in the path.
Assuming this was on RF, which is the only place the third party
packet ought to appear, it is a correct implementation. WX4MLB did not
send this object, it merely relayed it like a digi or an APRS IS hub
would. Your interpretation is correct.
It is important to rocognize that WX4MLB did not originate the packet,
so it should not modify it. Data is IGated from Internet to RF intact
(other than removal of the old TCPIP path information). WX4MLB should
NOT reformat this into another type of object.
Steve K4HG
On Jun 9, 2009, at 12:45 PM, Lynn W. Deffenbaugh (Mr) wrote:
> Greeting group,
>> I just discovered that my APRS-IS parser is considering the
> following packet as having been relayed by WX4MLB-3.
>> WX4MLB-3>BEACON:}146.52>APOBJ:!2806. N/08039. WrPHG7260 NWS
> MELBOURNE
>> I do believe that is a correct interpretation of the } third-party
> traffic designator. This packet tells me that 146.52 originated a
> position without timestamp (!) packet with a destination of APOBJ.
> WX4MLB-3 picked up this packet and relayed it to RF as a third-party
> (}) packet with a generic destination of BEACON.
>> Is this an accepted (and possibly common) method of defining objects
> on RF? Or would it be better defined as an Item (')') or Object (;)
> defined directly by WX4MLB-3? I suspect it was done as third-party
> traffic to avoid the unique naming issue for objects, but I'm not
> really sure.
>> I'm just trying to learn what I can so I can make recommendations
> when/if asked about such things.
>> Lynn (D) - KJ4ERJ
>>> _______________________________________________
> aprssig mailing list
>aprssig at tapr.org>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig>