[aprssig] Beacon rate feedback
scott at opentrac.org
Mon Nov 24 10:06:31 CST 2008
> You are correct though, in many cases when mobile just because you don't
> decode your own packet doesn't mean it didn't get to the digi. Without some
> limit on retries (ham hud would only try twice I think), such a
> retry-when-not-heard system would lead very quickly to network collapse. I
Well, the feature's always intended to be used as a 'transmit less if I
was heard' thing than 'transmit more if I wasn't heard'. But what I'm
trying to show with the N1VG-6 track is that even up in San Fransisco it
doesn't show any signs that it was transmitting excessively.
I think this is a viable option as long as you're using less power and
less antenna gain than the digipeater. It looks like most of the
'misses' were bad coverage areas, and any collisions were likely on the
tracker-to-digi side and not the digi-to-tracker leg.
I'm not saying this is the best option for every situation, but it does
seem to work pretty well in this case.
> Before we get into a Ford vs Chevy war... each method has it's own
> advantages... time based beacons, proportional pathing and smart beaconing.
In this case (driving up the California coast) I really don't see any
advantage to proportional pathing. Yes, I could add some direct
packets, but I don't really care about faster local updates and it's
still increasing the chances of the digi hearing collisions. And since
a single WIDE hop is enough for the coverage I need along most of the
route, there's no point in going wider.
> Proportional pathing probably gives the best "snap shot" type info... more
> info as you get closer to the tracker, less info if you are further away.
I could see doing this for my IGate station. I did notice that I got
all the way through town without hearing my own IGate on the way home.
I think it's set to beacon once every 15 minutes or less, and only
locally. If it had a wider path every 30 minutes, I might have had it
on my map by the time I got there.
> But two trackers who try to transmit at the same second each minute will
> tend to stay in lockstep.
On the OpenTracker, that's true only for timeslotting. Otherwise, I've
deliberately set it up so that when it holds off because the channel is
busy, it starts counting the next interval from the time it actually
gets the packet out. As long as one tracker can hear the other once in
a while, it'll 'slide' to the end of the first tracker's transmission.
And since it resets the timer AFTER sending the packet, the interval
will vary a little as long as there's any difference in length between
> beaconing. I guess it would really be nice if you could program a ratio of
> PATH1 and PATH2 in either of these devices... so you could for example,
> transmit 4 times with a direct path and 1 time with a regional path.
I'm trying to come up with a scheme for the Tracker2 in particular
that'll allow flexible but reasonably simple configuration of multiple
paths, multiple rates, and multiple transmit frequencies for each packet
type (position, weather, telemetry, status, etc). Right now there's
only limited control over what gets sent when.
More information about the aprssig