Order Tray | Contact Us | Home | SIG Lists

[aprssig] IRLP Node Object

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Mon Mar 26 09:17:11 UTC 2012


Hessu,

I know how much we love "special" values, but 111111z is another one of 
those that you probably need to make an exception for.

 From http://www.aprs.org/info/object-perm.txt

> OBJECTS: use the unique 111111z timestamp to indicate permanence
>
> The 111111z time stamp has always been recommended for all timeless
> objects as a default to indicate to the viewer that this object time
> stamp carries no temporal value.  Therefore, it was a reasonable
> extension of this concept to declare that a 111111z object is permanent
> and should not be overwritten by any other identically named object
> UNLESS it is originated by the same transmitting station.


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 3/26/2012 1:53 AM, Heikki Hannikainen wrote:
> On Sun, 25 Mar 2012, Paul Yeager wrote:
>
>> ;IRLP-4040*111111zDDMM.hhNIDDDMM.hhW0FFF.FFFMHz Tnnn CALLSIGN
>>
>> ... and what I entered is:
>>
>> ;IRLP-4397*111111z3522. NI08313. W0444.875MHz T131 K4RCC
>>
>> My problem is that aprs.fi appears not to like the format. Viewing 
>> the raw
>> packets reveals:
>>
>> 2012-03-25 22:05:09 UTC: 
>> EGLNST>APN383,qAR,N4NE-1:;IRLP-4397*111111z3522.
>> NI08313. W0444.875MHz T131 K4RCC [Delayed or out-of-order packet 
>> (timestamp)]
>
> aprs.fi uses the timestamp for duplicate/delayed and out-of-order 
> packet filtering. If the timestamp suddenly jumps back, the packet is 
> probably older than the previous packet from that station, and can be 
> thrown away. (It's actually just a little bit more complicated than 
> that, but that's the principle.)
>
> http://aprs.fi/info/a/IRLP-4397 - The same station is already 
> transmitted by K4RCC-13, which uses real UTC timestamps instead of a 
> constant 111111z, so aprs.fi takes the 111111z packet as a delayed one.
>
> It's probably not a problem for you if aprs.fi doesn't accept your 
> packets - your target are the local RF-based stations, which probably 
> do not see K4RCC-13's packets.
>
>   - Hessu
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20120326/6577df91/attachment.htm>


More information about the aprssig mailing list