[aprssig] Extending javAPRSSrvr's dupeTime

Keith VE7GDH ve7gdh at rac.ca
Mon Sep 22 19:26:41 CDT 2008

Pierre VE2PRT wrote...

> The target I was following was a balloon and it appeared to be
> bouncing up and down. (See the altitude value.)

My question would be why on earth was the balloon using a path of
WIDE1-1,WIDE2-2? That's a three hop path that would have triggered every
WIDEn-N digi including the "WIDE1-1 only" digis out to the horizon.
Their path is part of the problem. If digis are causing the delays, much
of the problem can be eliminated by not going through so many digis. The
more digis it goes through, the more chance of it going through one that
can cause a delay. However, from an altitude of less than 3000 feet at
least in the samples you provided, maybe the impact wouldn't be huge.

# 1221916877  sam sep 20 09:21:17 EDT 2008
10.1V 19C HDOP01.1 SATS07

# 1221916921  sam sep 20 09:22:01 EDT 2008
10.1V 19C HDOP01.0 SATS08

Both of the above went through VE2RAW-3. Therefore, VE2PCQ-3 and VE2HOM
should have heard the beacon at exactly the same time. It appears there
was a delay of abut 44 seconds.

# 1221916927  sam sep 20 09:22:07 EDT 2008
:/201321z4519.15N/07322.31WO006/020/A=000949 10.1V 19C HDOP01.1 SATS07

Above, it was gated again another 6 seconds after VE2HOM gated it.
VE2FET-1 should have heard it via VE2RAW-3 at exactly the same time as
VE2CPA-3 and VE2HOM.

# 1221916943  sam sep 20 09:22:23 EDT 2008
10.1V 21C HDOP01.2 SATS07

The above is a bit strange. The original beacon was sent just one second
after the 201321z beacon. The altitude had changed from 949 feet to 1643
feet. That's gotta be inaccuracy of the data outputted from the GPS
receiver. Vertical resolution is never as good as horizontal resolution.

# 1221916966  sam sep 20 09:22:46 EDT 2008
10.1V 21C HDOP01.0 SATS08

# 1221916976  sam sep 20 09:22:56 EDT 2008
:/201321z4519.33N/07322.16WO060/017/A=001382 10.1V 19C HDOP01.0 SATS08

The above is a strange ne. VE2FET-1 had already gated this identical
packet, but this time it had been digid by VE2RTS-3. It should have
theoretically been digi'd at the same time as it was gated by VEPCQ-3,
VE2HOM AND VE2RAW-3 but ot necessarily so... e.g. it could have held off
because the frequency wasn't clear.

# 1221916989  sam sep 20 09:23:09 EDT 2008
:/201323z4519.49N/07321.61WO073/030/A=002215 10.1V 21C HDOP01.0 SATS08

# 1221916997  sam sep 20 09:23:17 EDT 2008
:/201322z4519.38N/07322.03WO062/020/A=001643 10.1V 21C HDOP01.2 SATS07

# 1221917017  sam sep 20 09:23:37 EDT 2008
:/201322z4519.44N/07321.84WO064/027/A=001951 10.1V 21C HDOP01.0 SATS08

# 1221917033  sam sep 20 09:23:53 EDT 2008
:/201323z4519.57N/07321.13WO072/025/A=002762 10.1V 21C HDOP01.2 SATS07

# 1221917055  sam sep 20 09:24:15 EDT 2008
:/201323z4519.49N/07321.61WO073/030/A=002215 10.1V 21C HDOP01.0 SATS08

Digi'd thru VE2LY-3, gated by VE2FET-1, but only 22 seconds after the
previous one gated by VE2HOM.

# 1221917055  sam sep 20 09:24:15 EDT 2008
:/201324z4519.62N/07320.91WO068/027/A=002896 10.1V 21C HDOP01.0 SATS08

This is not a duplicate of the previous packet. It was sent one second
later and again, the elevation had changed from 2215 feet to 2896 feet.

# 1221917084  sam sep 20 09:24:44 EDT 2008
:/201323z4519.57N/07321.13WO072/025/A=002762 10.1V 21C HDOP01.2 SATS07

# 1221917088  sam sep 20 09:24:48 EDT 2008
:/201324z4519.62N/07320.91WO068/027/A=002896 10.1V 21C HDOP01.0 SATS08

And again... not a duplicate of the previous packet, but with some
elevation change and only one second later! It was heard direct by
VE2FET-1 without help from any digis. As no digis were involved, the 33
second delay had to be caused by VE2FET-1... unless the delays ever
happen at the server level.

No big conclusions... no overly obvious smoking guns. Several digis were
apparently causing delays in excess of 30 seconds. In one case, the
delay could have been at the IGate level.

> Would it be advisable to increase dupeTime, say to 90 seconds, on tier
> 1  and tier 2 servers? Would there be any drawback doing so?

I have wondered this too. However, if the APRS servers are going to do
90 second dupe checking, that's 3 times as much data they would have to
juggle at the same time. If the servers have enough horsepower to do it,
perhaps dupe checking should be changed to something more than 30
seconds. 30 seconds? 90 seconds?  Guess it's up to the server operators
to say if it's feasible or not. In all of your examples, the balloon was
transmitting the time. Without that, it can be a lot more difficult to
determine if the packet is a duplicate or not.

73 es cul - Keith VE7GDH
"I may be lost, but I know exactly where I am!"

More information about the aprssig mailing list