[aprssig] Beacon rate feedback

[Scott Miller]

> 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 
the packets.

> 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.

Scott
N1VG