Delayed or Out-of-Order Packets (timestamp)

[David Andrzejewski]

My igate is sending out an object periodically, and when it makes it to APRS.fi, here's what happens.  What is wrong her?

2016-07-17 01:26:43 EDT: NEWBRY>APRX28,qAR,KA8OAD-1:;442.0875 *111111z4127.04N/08131.93Wr442.087MHz DMR N8NOD [Delayed or out-of-order packet (timestamp)]

[Heikki Hannikainen]

The object name is not unique, it's a frequency object and that frequency
is also in use elsewhere:

http://aprs.fi/?c=raw&call=W9AMT

yours:

http://aprs.fi/?c=raw&call=NEWBRY

Frequency objects, due to their format, cannot be unique throughout the
world, since they're named by the frequency and the frequency is reused.
This is not considered to be a real problem, as these frequency objects
are transmitted on the local APRS radio frequency, for the benefit of
local APRS radio users, so that they can use the built-in "tune" option of
their APRS radios to tune to that repeater. That's the primary intended
use case. It's possible, though, to add a letter after the frequency to
differentiate the names: http://www.aprs.org/info/freqspec.txt

Your packets also have a constant 111111z timestamp, which is quite
invalid - it decodes to 11th day of the current month (July 11th now),
11:11 UTC. The other station is sending valid timestamps, and yours are
quite consistently discarded.

If you send a packet with timestamps, they should be actual, correct
timestamps. Check the aprx documentation on how to get that set up
correctly. In case of problems, get in touch with the aprx discussion
group:

https://groups.google.com/forum/#!forum/aprx-software

- Hessu

[David Andrzejewski]

On Monday, July 18, 2016 at 10:54:44 AM UTC-4, Heikki Hannikainen wrote:

On Sat, 16 Jul 2016, David Andrzejewski wrote:

> My igate is sending out an object periodically, and when it makes it to APRS.fi, here's what happens.  What is wrong her?
> 2016-07-17 01:26:43 EDT: NEWBRY>APRX28,qAR,KA8OAD-1:;442.0875 *111111z4127.04N/08131.93Wr442.087MHz DMR N8NOD [Delayed or out-of-order packet
> (timestamp)]

The object name is not unique, it's a frequency object and that frequency
is also in use elsewhere:

http://aprs.fi/?c=raw&call=W9AMT

yours:

http://aprs.fi/?c=raw&call=NEWBRY

Frequency objects, due to their format, cannot be unique throughout the
world, since they're named by the frequency and the frequency is reused.
This is not considered to be a real problem, as these frequency objects
are transmitted on the local APRS radio frequency, for the benefit of
local APRS radio users, so that they can use the built-in "tune" option of
their APRS radios to tune to that repeater. That's the primary intended
use case. It's possible, though, to add a letter after the frequency to
differentiate the names: http://www.aprs.org/info/freqspec.txt

Well that would explain it. And yes, that's why I produce those objects that way.  It's just nice to see them on the map.

And actually, since this is a DMR repeater, there aren't any DMR units right now that I'm aware of that have APRS at all. So maybe I can just present the object a little differently so people know it exists.

 

Your packets also have a constant 111111z timestamp, which is quite
invalid - it decodes to 11th day of the current month (July 11th now),
11:11 UTC. The other station is sending valid timestamps, and yours are
quite consistently discarded.

If you send a packet with timestamps, they should be actual, correct
timestamps. Check the aprx documentation on how to get that set up
correctly. In case of problems, get in touch with the aprx discussion
group:

https://groups.google.com/forum/#!forum/aprx-software

That appears to be a bug in aprx, as I have not specified a timestamp in the config file.  I went ahead and posted on their group as well.

 

   - Hessu

Thanks!

73,

- Dave 

[Lynn W Deffenbaugh (Mr)]

On 7/18/2016 10:54 AM, Heikki Hannikainen wrote:
> Your packets also have a constant 111111z timestamp, which is quite
> invalid - it decodes to 11th day of the current month (July 11th now),
> 11:11 UTC. The other station is sending valid timestamps, and yours
> are quite consistently discarded.

Actually, 111111z is a "permanent" object timestamp per
http://www.aprs.org/info/object-perm.txt

> The APRS1.2 solution was to define a class of objects that are permanent
> yet, are backwards compatible to all existing clients.
>
> 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.

Also from http://www.aprs.org/info/freqspec.txt

> These objects are transmitted with the pseudo permanent date/time
> stamp of 111111z. This unique time stamp declares this object to be
> permanent. This means that it should not be replaced by any other
> similarly named object unless that object is transmitted by the same
> originating station. This lets the originator of a permanent object
> update or move his object, but it then prevents his object from being
> replaced by anyone else's similar object.

And numerous other pages show many of their repeater/frequency objects
using the 111111z timestamp.

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

[David Ranch]

I'm seeing this as well and could be my reason why my APRS Objects aren't showing up on the map anymore (reported in another thread here on the list).  Was this behavior changed recently on aprs.fi?

2016-07-29 12:10:04 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2INDIANA:;WW6BAY-Y *111111z3718.73NY12208.50Wa444.425MHz T127 R21k WW6BAY Yaesu System Fusion Rptr NetSu1900
2016-07-29 12:12:42 PDT: KI6ZHD>APRS,TCPIP*,qAC,T2USANW:;EL-KI6ZHD*111111z3720.61NE12200.00W0441.000MHz T136 R21k KI6ZHD Echolink running svxlink.sourceforge.net [Delayed or out-of-order packet (timestamp)]
2016-07-29 12:24:54 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2INDIANA:;KI6ZHD-1 *111111z3720.61N/12159.99Wn145.050 full service packet digi/pbbs/node [Delayed or out-of-order packet (timestamp)]
2016-07-29 12:39:09 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2INDIANA:;WW6BAY-Y *111111z3718.73NY12208.50Wa444.425MHz T127 R21k WW6BAY Yaesu System Fusion Rptr NetSu1900
2016-07-29 12:42:42 PDT: KI6ZHD>APRS,TCPIP*,qAC,T2USANW:;EL-KI6ZHD*111111z3720.61NE12200.00W0441.000MHz T136 R21k KI6ZHD Echolink running svxlink.sourceforge.net [Delayed or out-of-order packet (timestamp)]
2016-07-29 12:51:54 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2INDIANA:;KI6ZHD-1 *111111z3720.61N/12159.99Wn145.050 full service packet digi/pbbs/node [Delayed or out-of-order packet (timestamp)]
2016-07-29 13:06:29 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2INDIANA:;WW6BAY-Y *111111z3718.73NY12208.50Wa444.425MHz T127 R21k WW6BAY Yaesu System Fusion Rptr NetSu1900

--David
KI6ZHD

[David Ranch]

 
Does anyone have any updates to this issue?  My KI6ZHD objects continue to not show on APRS.fi though ironically, the WW6BAY-Y object I do export into APRS-IS via APRX does show up.  Very strange!

--David
KI6ZHD

[David Ranch]

I see that my various APRS objects are showing up again on APRS.FI so it sounds like a fix went in.  Thanks APRS.FI team!

--David
KI6ZHD

[Heikki Hannikainen]

On Tue, 16 Aug 2016, David Ranch wrote:

> I see that my various APRS objects are showing up again on APRS.FI so it sounds like a fix went in.  Thanks APRS.FI team!

Actually, aprs.fi has not been changed in any way that would affect that,
to either direction, during the past few years.


- Hessu

[David Ranch]

Hmmm.. that's very strange.  Ok, the only other thing I can think of is that various posit data coming from Xastir going into APRS-IS was confusing something within aprs.fi.  Things are displaying on aprs.fi as expected right now so let be start Xastir up and see if anything breaks.

--David
KI6ZHD

[Nosey Nick VA3NNW]

On Wednesday, August 17, 2016 at 2:53:15 PM UTC-4, David Ranch wrote:

Hmmm.. that's very strange.  Ok, the only other thing I can think of is that various posit data coming from Xastir going into APRS-IS was confusing something within aprs.fi.  Things are displaying on aprs.fi as expected right now so let be start Xastir up and see if anything breaks.

My guess would be that since we passed the 11th of the month, the 11th 11:11am timestamp looked "believable" for a while, not "delayed".

111111z is a perfectly valid "normal" timestamp, so was a completely surreal choice for "permanent". How am I supposed to tell the difference between a genuinely permanent one, vs one that I genuinely transmitted at 11:11 on the 11th of any month? Something deliberately different to a real timestamp would have made more sense - I'd have proposed 000000z (0th of the month) or 999999z (99:99 hrs on 99th of the month), or heck, there are already the ")" lines, "Items" described in Ch11 of APRS101 (p59), almost identical to objects except lacking a timestamp, or in the words of APRS101:

"Item Reports specify an Item's position, but cannot have a timestamp. While Item reports may also include course/speed or other Extended Data, they are really intended for inanimate things that are occasionally posted on a map (e.g. marathon checkpoints or first-aid posts). Otherwise they are handled in the same way as Object Reports"

Now I recognise that APRS typically has about a dozen ways to send the same info, but... c'mon! It says "Such a Permanent Object format was proposed for APRS1.2" - did anyone actually DISCUSS object-perm.txt? Whilst sober? Did it pass into "standard", if such a thing even exists for APRS?   :-D


Nick VA3NNW

[David Ranch]

Ok.. I've reproduced the problem again and it seems to deal with duplicate callsigns with no SSID given.  This is what I did to reproduce:


Step #1
--------
On 8/17/16 @ 7:02pm PST looking at KI6ZHD-1 on aprs.fi :: I'm seeing the APRX injected APRS-IS objects for "KI6ZHD-1" and "EL-KI6ZHD" coming from Svxlink.  For example, lets' look at KI6ZHD-1:
--
APRS station KI6ZHD-1 - show graphs

Source callsign:        KI6ZHD  <-------------------------------------
Comment:        145.050 full service packet digi/pbbs/node
Location:       37°20.61' N 121°59.99' W - locator CM97AI02AK - show map - static map
2.3 miles Northeast bearing 51° from Cupertino, Santa Clara County, California, United States [?]
2.7 miles Southeast bearing 131° from Sunnyvale, Santa Clara County, California, United States
5.8 miles West bearing 273° from San Jose, Santa Clara County, California, United States
37.6 miles Southeast bearing 142° from San Francisco, San Francisco County, California, United States
Last position:  2016-08-17 19:00:16 PDT (2m ago)
2016-08-17 19:00:16 PDT local time at Cupertino, United States [?]
Last path:      KI6ZHD>APRX28 via TCPIP*,qAC,T2EDM
Positions stored:       3
Others sourced by KI6ZHD:       EL-KI6ZHD WW6BAY-Y
--


Step #2  Looking at KI6ZHD :: APRS.FI hasn't seen a position for this callsign in 22 days
--
APRS station KI6ZHD - show graphs
Map loading...
Comment:        Send APRS TXT 4 QSO via Xastir/Cento
Last beacon:    KI6ZHD/k KI6ZHD/d KI6ZHD-1/p SCLARA/n 44.4.10.39/ip -73 from Santa Clara
Location:       37°20.62' N 121°59.99' W - locator CM97AI02AL - show map - static map
2.3 miles Northeast bearing 51° from Cupertino, Santa Clara County, California, United States [?]
2.7 miles Southeast bearing 131° from Sunnyvale, Santa Clara County, California, United States
5.8 miles West bearing 273° from San Jose, Santa Clara County, California, United States
37.6 miles Southeast bearing 142° from San Francisco, San Francisco County, California, United States
Last position:  2016-07-25 21:43:12 PDT (22d 21h20m ago)   <----------------------------------------------------------------
2016-07-25 21:43:12 PDT local time at Cupertino, United States [?]
Last telemetry:         2014-02-07 14:07:24 PST (922d 3h55m ago) – show telemetry
Avg 10m: 0.020 Rx Erlang, Avg 10m: 0 Tx Erlang, RxPkts: 11 count/10m, IGateDropRx: 0 count/10m, TxPkts: 0 count/10m
Device:         Open Source: Xastir (software, Linux/Unix)
Last path:      KI6ZHD>APX209 via TCPIP*,qAC,FIFTH
Positions stored:       38
Packet rate:    520 seconds between packets on average during 25995 seconds.
Items and objects originated:   EL-KI6ZHD KI6ZHD-1 WW6BAY-Y
--


Step #3
-------
Reconfigure Xastir from using the callsign+ssid combo of KI6ZHD-4 to using KI6ZHD  (no SSID)


Step #4
-------
Almost instantly I started to see both APRX and Svx beacons every 15 seconds over and over and over via Xastir's RF AX25 interface (tied into Linux's native AX.25 stack)

d710: fm KI6ZHD-4 to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 64 19:06:56
=3720.62N/12159.99WxPHG7190Send APRS TXT 4 QSO via Xastir/Cento
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 64 19:09:32
=3720.62N/12159.99WxPHG7190Send APRS TXT 4 QSO via Xastir/Cento
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:10:47
;EL-KI6ZHD*180210zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:11:04
;EL-KI6ZHD*180211zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:11:21
;EL-KI6ZHD*180211zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:11:38
;EL-KI6ZHD*180211zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:11:55
;EL-KI6ZHD*180211zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:12:12
;EL-KI6ZHD*180212zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:12:29
;EL-KI6ZHD*180212zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:12:46
;EL-KI6ZHD*180212zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:13:03
;EL-KI6ZHD*180213zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:13:03
;WW6BAY-Y *180213zY;Z[9/YdMa   444.425MHz T127 R21k WW6BAY Yaesu System Fu
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:13:20
;EL-KI6ZHD*180213zE;Y31/]!!0   441.000MHz T136 R21k KI6ZHD Echolink runnin
d710: fm KI6ZHD to APX209 via WIDE2-1 ctl UI^ pid=F0(Text) len 75 19:13:20
;WW6BAY-Y *180213zY;Z[9/YdMa   444.425MHz T127 R21k WW6BAY Yaesu System Fu
--

At this point, I went into Xastir's Interface control and disabled Transmit on the AX0 interface.  At that point, the transmissions on RF stopped.  I'm not sure why this would impact what seems to be a digitpeating issue when I have the Xastir AX.25's AX0 interface not to digipeat. 


Step #5
-------
Looking at KI6ZHD on aprs.fi  :: newest position is just a minute or so old and they are still displaying
--
 APRS station KI6ZHD - show graphs
Map loading...
Comment:        Send APRS TXT 4 QSO via Xastir/Cento
Last beacon:    KI6ZHD/k KI6ZHD/d KI6ZHD-1/p SCLARA/n 44.4.10.39/ip -73 from Santa Clara
Location:       37°20.62' N 121°59.99' W - locator CM97AI02AL - show map - static map
2.3 miles Northeast bearing 51° from Cupertino, Santa Clara County, California, United States [?]
2.7 miles Southeast bearing 131° from Sunnyvale, Santa Clara County, California, United States
5.8 miles West bearing 273° from San Jose, Santa Clara County, California, United States
37.6 miles Southeast bearing 142° from San Francisco, San Francisco County, California, United States
Last position:  2016-08-17 19:09:32 PDT (5m11s ago)
2016-08-17 19:09:32 PDT local time at Cupertino, United States [?]
Last telemetry:         2014-02-07 14:07:24 PST (922d 4h7m ago) – show telemetry
Avg 10m: 0.020 Rx Erlang, Avg 10m: 0 Tx Erlang, RxPkts: 11 count/10m, IGateDropRx: 0 count/10m, TxPkts: 0 count/10m
Device:         Open Source: Xastir (software, Linux/Unix)
Last path:      KI6ZHD>APX209 via TCPIP*,qAS,KI6ZHD-4
Positions stored:       38
Packet rate:    393 seconds between packets on average during 19631 seconds.
--


Step #6
-------
Next day, things look ok on APRS.FI and things still looked ok.  So I think restarted local packet system @ 8:32am PST 08/18/16


Step #7
----------
Now looking at 11:24am on 8/19/16, I'm back to the broken state.   I do not see EL-KI6ZHD nor KI6ZHD-1 on the map
but I *do* see the WW6BAY-Y object on the map which is coming from KI6ZHD.   I *do* see all my APRS objects on
openaprs.com and Findu - http://www.findu.com/cgi-bin/near.cgi?zip=95051&distance=50


So there is obviously something funny going on here but I don't understand why my APRS objects aren't showing up on aprs.fi

--David
KI6ZHD

[Heikki Hannikainen]

On Fri, 19 Aug 2016, David Ranch wrote:

> At this point, I went into Xastir's Interface control and disabled
> Transmit on the AX0 interface.  At that point, the transmissions on RF
> stopped.  I'm not sure why this would impact what seems to be a
> digitpeating issue when I have the Xastir AX.25's AX0 interface not to
> digipeat. 

So, basically, it seems like the issue is that the packets are not being
transmitted in the first place. For further help, please get in touch with
the xastir folks / mailing list.

> Step #7
> ----------
> Now looking at 11:24am on 8/19/16, I'm back to the broken state.   I do not see EL-KI6ZHD nor KI6ZHD-1 on the map
> but I *do* see the WW6BAY-Y object on the map which is coming from KI6ZHD.   I *do* see all my APRS objects on
> openaprs.com and Findu - http://www.findu.com/cgi-bin/near.cgi?zip=95051&distance=50

At least findu.com and aprs.fi agree completely. Right now,

http://www.findu.com/cgi-bin/near.cgi?zip=95051&distance=50 says EL-KI6ZHD
Last Position was 00:05:18:02 ago (5 hours 18 minutes 2 seconds).

http://aprs.fi/info/?call=EL-KI6ZHD says Last Position: 2016-08-19
17:32:01 EEST (5h17m ago) - close enough, my page reloads were certainly
not on the same second.

So, the positions are not transmitted continuously. If you look at the
aprs.fi map view, the default setting for time range ("Show last:") on the
right is 1 hour, if you extend that to something > 5 hours now (6, 12, 24
hours), you'll see EL-KI6ZHD since it was transmitted 5 hours ago.

If you want to see it with the default 1 hour time range, you'll need to
transmit at least once per hour.

The aprs.fi equivalent to findu.com's near.cgi is looking at the "Stations
near current position of..." table on http://aprs.fi/info/a/KI6ZHD-4 for
example, it shows EL-KI6ZHD just as well as findu.com near.cgi, and shows
the "last heard" column too.

- Hessu

[David Ranch]

Hello Hessu,

So, basically, it seems like the issue is that the packets are not being
transmitted in the first place. For further help, please get in touch with
the xastir folks / mailing list.

I wasn't clear enough but my AX.25 RF setup is not on 144.390 (APRS frequency).  It's on 145.050 so no APRS Igate would pick up those beacons.  I only mentioned it to be complete but maybe that was misleading.  The key point here is that I have APRX and Svxlink configured to only send their objects in via APRS-IS only.
 

At least findu.com and aprs.fi agree completely. Right now,

http://www.findu.com/cgi-bin/near.cgi?zip=95051&distance=50 says EL-KI6ZHD
Last Position was 00:05:18:02 ago (5 hours 18 minutes 2 seconds).

http://aprs.fi/info/?call=EL-KI6ZHD says Last Position: 2016-08-19
17:32:01 EEST (5h17m ago) - close enough, my page reloads were certainly
not on the same second.

As of 1:39PM PST, I don't see EL-KI6ZHD (sent via Svxlink) nor KI6ZHD-1 (sent by APRX) on aprs.fi's map but I *do* see WW6BAY-Y (sent by APRX).   Both APRX and Svxlink are configured to send it's objects every 30 minutes into APRS-IS.

Looking at the details of KI6ZHD - http://aprs.fi/?c=raw&call=KI6ZHD - I can see that aprs.fi is flagging the missing objects as "[Delayed or out-of-order packet (timestamp)]"

2016-08-19 13:03:17 PDT: KI6ZHD>APRS,TCPIP*,qAC,T2CAWEST:;EL-KI6ZHD*111111z3720.61NE12200.00W0441.000MHz T136 R21k KI6ZHD Echolink running svxlink.sourceforge.net [Delayed or out-of-order packet (timestamp)]
2016-08-19 13:10:04 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2OREGON:;KI6ZHD-1 *111111z3720.61N/12159.99Wn145.050 full service packet digi/pbbs/node [Delayed or out-of-order packet (timestamp)]
2016-08-19 13:22:59 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2OREGON:;WW6BAY-Y *111111z3718.73NY12208.50Wa444.425MHz T127 R21k WW6BAY Yaesu System Fusion Rptr NetSu1900
2016-08-19 13:32:41 PDT: KI6ZHD>APX209,TCPIP*,qAC,SIXTH:=3720.62N/12159.99WxPHG7190Send APRS TXT 4 QSO via Xastir/Cento
2016-08-19 13:33:17 PDT: KI6ZHD>APRS,TCPIP*,qAC,T2CAWEST:;EL-KI6ZHD*111111z3720.61NE12200.00W0441.000MHz T136 R21k KI6ZHD Echolink running svxlink.sourceforge.net [Delayed or out-of-order packet (timestamp)]
2016-08-19 13:35:34 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2OREGON:;KI6ZHD-1 *111111z3720.61N/12159.99Wn145.050 full service packet digi/pbbs/node [Delayed or out-of-order packet (timestamp)]
--


Per the other recent thread here on Google Groups, it seems that the 111111z timestamp is tripping something up through I think only happens with a specific interaction of things.

 --David
KI6ZHD

[Heikki Hannikainen]

On Fri, 19 Aug 2016, David Ranch wrote:

> At least findu.com and aprs.fi agree completely. Right now,
>
> http://www.findu.com/cgi-bin/near.cgi?zip=95051&distance=50 says EL-KI6ZHD
> Last Position was 00:05:18:02 ago (5 hours 18 minutes 2 seconds).
>
> http://aprs.fi/info/?call=EL-KI6ZHD says Last Position: 2016-08-19
> 17:32:01 EEST (5h17m ago) - close enough, my page reloads were certainly
> not on the same second.
>
>
> As of 1:39PM PST, I don't see EL-KI6ZHD (sent via Svxlink) nor KI6ZHD-1
> (sent by APRX) on aprs.fi's map but I *do* see WW6BAY-Y (sent by
> APRX).   Both APRX and Svxlink are configured to send it's objects every
> 30 minutes into APRS-IS.
>
> Looking at the details of KI6ZHD - http://aprs.fi/?c=raw&call=KI6ZHD - I
> can see that aprs.fi is flagging the missing objects as "[Delayed or
> out-of-order packet (timestamp)]"
>
> 2016-08-19 13:03:17 PDT: KI6ZHD>APRS,TCPIP*,qAC,T2CAWEST:;EL-KI6ZHD*111111z3720.61NE12200.00W0441.000MHz T136 R21k KI6ZHD Echolink running svxlink.sourceforge.net [Delayed
> or out-of-order packet (timestamp)]

There are both packets with a correct timestamp in there, and ones with
111111z. The ones with the correct timestamp go through, and the ones with
111111z get ignored since there are recent packets with a correct
timestamp available, too.

If timestamps are present, aprs.fi uses them to pick the latest packet and
ignore older ones. If you do not wish to use the timestamps, please do not
transmit them, and aprs.fi then will not use them to filter out older
packets. If you transmit timestamps, aprs.fi will use them, so that
out-of-order packets will not make tracks of moving stations jump around
erratically.

http://aprs.fi/?c=raw&call=KI6ZHD&limit=300&view=normal - see packets from
last night and earlier today - at the same time there were *both* packets
with good timestamps and ones with 111111z.

If aprx can't send good timestamps, please get in touch with the aprx
discussion group:

https://groups.google.com/forum/#!forum/aprx-software

2016-08-18 22:20:28 UTC:
KI6ZHD>APX209,TCPIP*,qAS,KI6ZHD-4:;EL-KI6ZHD*182220zE;Y31/]!!0

441.000MHz T136 R21k KI6ZHD Echolink runnin

2016-08-18 22:33:17 UTC:

KI6ZHD>APRS,TCPIP*,qAC,T2CAWEST:;EL-KI6ZHD*111111z3720.61NE12200.00W0441.000MHz
T136 R21k KI6ZHD Echolink running svxlink.sourceforge.net [Delayed or
out-of-order packet (timestamp)]

2016-08-18 22:40:01 UTC:
KI6ZHD>APX209,TCPIP*,qAS,KI6ZHD-4:;EL-KI6ZHD*182240zE;Y31/]!!0

441.000MHz T136 R21k KI6ZHD Echolink runnin

2016-08-18 23:03:17 UTC:

KI6ZHD>APRS,TCPIP*,qAC,T2CAWEST:;EL-KI6ZHD*111111z3720.61NE12200.00W0441.000MHz
T136 R21k KI6ZHD Echolink running svxlink.sourceforge.net [Delayed or
out-of-order packet (timestamp)]

2016-08-18 23:07:13 UTC:
KI6ZHD>APX209,TCPIP*,qAS,KI6ZHD-4:;EL-KI6ZHD*182307zE;Y31/]!!0

441.000MHz T136 R21k KI6ZHD Echolink runnin

...

> 2016-08-19 13:10:04 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2OREGON:;KI6ZHD-1 *111111z3720.61N/12159.99Wn145.050 full service packet digi/pbbs/node [Delayed or out-of-order packet
> (timestamp)]
> 2016-08-19 13:22:59 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2OREGON:;WW6BAY-Y *111111z3718.73NY12208.50Wa444.425MHz T127 R21k WW6BAY Yaesu System Fusion Rptr NetSu1900
> 2016-08-19 13:32:41 PDT: KI6ZHD>APX209,TCPIP*,qAC,SIXTH:=3720.62N/12159.99WxPHG7190Send APRS TXT 4 QSO via Xastir/Cento
> 2016-08-19 13:33:17 PDT: KI6ZHD>APRS,TCPIP*,qAC,T2CAWEST:;EL-KI6ZHD*111111z3720.61NE12200.00W0441.000MHz T136 R21k KI6ZHD Echolink running svxlink.sourceforge.net [Delayed
> or out-of-order packet (timestamp)]
> 2016-08-19 13:35:34 PDT: KI6ZHD>APRX28,TCPIP*,qAC,T2OREGON:;KI6ZHD-1 *111111z3720.61N/12159.99Wn145.050 full service packet digi/pbbs/node [Delayed or out-of-order packet
> (timestamp)]
> --
>
>
> Per the other recent thread here on Google Groups, it seems that the 111111z timestamp is tripping something up through I think only happens with a specific interaction of
> things.
>
>  --David
> KI6ZHD
>

> --
> You received this message because you are subscribed to the Google Groups "aprs.fi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to aprsfi+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

- Hessu

[Tom Hayward]

On Fri, Aug 19, 2016 at 2:11 PM, Heikki Hannikainen <he...@hes.iki.fi> wrote:
> There are both packets with a correct timestamp in there, and ones with
> 111111z. The ones with the correct timestamp go through, and the ones with
> 111111z get ignored since there are recent packets with a correct timestamp
> available, too.
>
> If timestamps are present, aprs.fi uses them to pick the latest packet and
> ignore older ones. If you do not wish to use the timestamps, please do not
> transmit them, and aprs.fi then will not use them to filter out older
> packets. If you transmit timestamps, aprs.fi will use them, so that
> out-of-order packets will not make tracks of moving stations jump around
> erratically.
>
> http://aprs.fi/?c=raw&call=KI6ZHD&limit=300&view=normal - see packets from
> last night and earlier today - at the same time there were *both* packets
> with good timestamps and ones with 111111z.
>
> If aprx can't send good timestamps, please get in touch with the aprx
> discussion group:

Hes,

111111z is not a timestamp. It's the permanent object identifier.

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

If you disagree with this, the one to contact is WB4APR, not the aprx
group. It's not their fault he picked a silly spec.

Tom KD7LXL

[Lynn W Deffenbaugh (Mr)]

On 8/19/2016 5:16 PM, Tom Hayward wrote:
> Hes,
> 111111z is not a timestamp. It's the permanent object identifier.
>
> http://www.aprs.org/info/object-perm.txt
>
> If you disagree with this, the one to contact is WB4APR, not the aprx
> group. It's not their fault he picked a silly spec.
>
> Tom KD7LXL
>

I think the real issue is that you should pick one or the other for any
given object. What's likely confusing the delayed packet detector is
that the timestamp is real sometimes and then jumps to 111111z. If you
only did one or the other, consistently, I suspect the problem will go away.

[Heikki Hannikainen]

On Fri, 19 Aug 2016, Tom Hayward wrote:

> On Fri, Aug 19, 2016 at 2:11 PM, Heikki Hannikainen <he...@hes.iki.fi> wrote:
>> There are both packets with a correct timestamp in there, and ones with
>> 111111z. The ones with the correct timestamp go through, and the ones with
>> 111111z get ignored since there are recent packets with a correct timestamp
>> available, too.
>>
>> If timestamps are present, aprs.fi uses them to pick the latest packet and
>> ignore older ones. If you do not wish to use the timestamps, please do not
>> transmit them, and aprs.fi then will not use them to filter out older
>> packets.
>

> 111111z is not a timestamp. It's the permanent object identifier.
>
> http://www.aprs.org/info/object-perm.txt
>
> If you disagree with this, the one to contact is WB4APR, not the aprx
> group. It's not their fault he picked a silly spec.

I agree that the spec for 111111z is silly, but like Lynn said, and I said
above, the 111111z packets get ignored because there are packets with
recent correct timestamps present, too, and those are preferred since it
seems like the station is able to generate them.

For example, OH3RBE-1 is consistently sending 111111z all the time, and
the packets are not ignored:

http://aprs.fi/?c=raw&call=OH3RBE-1

I'd recommend sending the timestamps always, with correct time values, so
that they can be used for something. Or then sending packet formats which
do not have timestamp (APRS item format, for example), if you cannot
generate timestamps.

- Hessu

[Nosey Nick VA3NNW]

On Friday, August 19, 2016 at 5:16:58 PM UTC-4, Tom KD7LXL wrote:

111111z is not a timestamp. It's the permanent object identifier.
http://www.aprs.org/info/object-perm.txt

111111z *IS* a perfectly valid timestamp for an object created on 11th of the month at 11:11Z (UTC).
 http://www.aprs.org/doc/APRS101.PDF Ch6 P22

If you disagree with this, the one to contact is WB4APR, not the aprx
group. It's not their fault he picked a silly spec.

 
No, but I see object-perm.txt as a proposal, which should have been discussed, and *IF* it was agreed upon, rolled into APRS101 (or 102 or 103 or whatever, I guess). In the meantime it's entirely up to APRX and APRS.fi and any other software authors whether they choose to implement this proposal. I won't, myself   :-p

NN

[David Ranch]

Hello Hessu,

There are both packets with a correct timestamp in there, and ones with
111111z. The ones with the correct timestamp go through, and the ones with
111111z get ignored since there are recent packets with a correct
timestamp available, too.

Sounds like this is indeed the issue though as Tom KD7LXL points out, 111111z isn't a timestamp.  It seems it should be recognized as a signature meaning "permanent object" and be ignored in your "out-of-order packet (timestamp)" logic.

 

If timestamps are present, aprs.fi uses them to pick the latest packet and
ignore older ones. If you do not wish to use the timestamps, please do not
transmit them, and aprs.fi then will not use them to filter out older
packets. If you transmit timestamps, aprs.fi will use them, so that
out-of-order packets will not make tracks of moving stations jump around
erratically.

Another point to call out here is that KI6ZHD-0 callsing+ssid which is announcing the KI6ZHD-1 and WW6BAY-Y objects is not sending a position for itself and is thus, not on the map.  Looking at
at say http://www.tapr.org/pipermail/aprssig/2014-December/043953.html which discusses the difference between an APRS OBJECT vs ITEM, it sure seems like sending an OBJECT is the right choice as none of these items are moving.. they permanent, non-moving objects.

If aprx can't send good timestamps, please get in touch with the aprx
discussion group:

It can but it would be sending APRS "items" which seem to be more intended for things that move (which these wouldn't be doing).  Also seems like there could be bugs with with a good portion of APRS rigs out there.  For me, it's clear that the best solution is to not use duplicate callsign+ssid setups that will be creating different timestamps.  That's clearly a user error on my my part but I do encourage you to reconsider how your much appreciated website treats the "111111z" string not as a timestamp but as a "permanent" keyword.

--David
KI6ZHD

[Heikki Hannikainen]

On Sat, 20 Aug 2016, David Ranch wrote:

> Sounds like this is indeed the issue though as Tom KD7LXL points out,
> 111111z isn't a timestamp.  It seems it should be recognized as a
> signature meaning "permanent object" and be ignored in your
> "out-of-order packet (timestamp)" logic.

111111z is a completely valid timestamp, too, as Nick pointed out. It's
hard to tell which one it is when you receive one. Also, it's silly if a
transmitter which is transmitting timestamps must avoid transmitting on
the otherwise fairly valid time of 11:11z on the 11th day, in the fear
that the timestamp would be misunderstood.

Especially if both 111111z and a good timestamp are sent around the same
time, I maintain it's better to pick the ones with good timestamps.

> Another point to call out here is that KI6ZHD-0 callsing+ssid which is
> announcing the KI6ZHD-1 and WW6BAY-Y objects is not sending a position
> for itself and is thus, not on the map. 

I'm sorry, but I don't see how that is relevant to the discussion. Could
you elaborate?

> Looking at at say
> http://www.tapr.org/pipermail/aprssig/2014-December/043953.html which
> discusses the difference between an APRS OBJECT vs ITEM, it sure seems
> like sending an OBJECT is the right choice as none of these items are
> moving.. they permanent, non-moving objects.
>
> If aprx can't send good timestamps, please get in touch with the aprx
> discussion group:
>
> It can but it would be sending APRS "items" which seem to be more
> intended for things that move (which these wouldn't be doing).

Please see APRS101.PDF, the specification, section "11 OBJECT AND ITEM
REPORTS", which says:

"Object Reports specify an Object’s position, can have an optional
timestamp, and can include course/speed information or other Extended
Data. Object Reports are intended primarily for plotting the positions of
moving objects (e.g. spacecraft, storms, marathon runners without
trackers).

Item Reports specify an Item’s position, but cannot have a timestamp.
While Item reports may also include course/speed or other Extended Data,
they are really intended for inanimate things that are occasionally posted
on a map (e.g. marathon checkpoints or first-aid posts). Otherwise they

are handled in the same way as Object Reports."

Objects are perfectly good for moving things, and are commonly used as
such, when a tactical object name is needed instead of a callsign. For
example, this SAR rescue vessel:
http://aprs.fi/#!call=a%2FJENNYWIHU&timerange=3600&tail=3600

And, items cannot have timestamps.

>  For me, it's clear that the best solution is to not use
>duplicate callsign+ssid setups that will be creating different
> timestamps.  That's clearly a user error on my my part but I do encourage you to reconsider how your much appreciated website treats the "111111z" string not as a timestamp
> but as a "permanent" keyword.

Using timestamps for duplicate / delayed packet filtering provides great
benefit on the APRS network, since it makes the track lines work nicely
and old / delayed packets, which are very common on the APRS network,
especially with flying objects like high-altitude balloons and aircraft,
will not make the station jump back and forth on the map. If I disabled
that, there would be people complaining again about zig-zag track lines,
and that would not be great.

The 111111z idea is so ambiguous, especially if both are around, that I'd
rather ignore it for now. aprs.fi will receive packets with 111111z, as
demonstrated, so you can use it, but just don't try to mix it with good
timestamps.

- Hessu