[OZAPRS] Desert trekking

Owen Duffy owen at owenduffy.net
Mon Oct 13 21:20:43 EST 2014


Hello Gordon,

On 13/10/2014 20:45, Gordon Taylor wrote:
> Thanks for the push Ian, I am well aware of theTT3 settings and thought I
> had it all set up correctly.  I changed a setting last weekend and now it
> beacons at the correct interval when stationary.  What setting was that you
> may well ask.
>
> I had the low speed value set at 0 in the smart beaconing settings.
> Changing this to 2 and the tracker beacons every 900 seconds when stationary
> which is correct.
>
> I wonder if there is an issue with the algorithm or some other reason not to
> use 0 for a slow speed setting.  I see from the manual the algorithm has the
> following line;
>
> IF (speed <slow_speed)
> 	beacon_rate = slow_rate
>
> With a slow speed value of 0 it is not possible to get below this.  Maybe
> this is why
It does depend on the implementation, but if it did literally what is
said above, then speed reported by the GPS will never be below zero.

Byon says in his manual:

"The SmartBeaconing algorithm basically says that if the speed is faster
than the Fast Speed setting, position reports will
be sent at the Fast Rate. If the speed is slower than then Slow Speed,
position reports will be sent at the Slow Rate. If
the speed is in between, position reports will be scaled from the Fast
Rate. So if the speed is ½ of the Fast Speed, the
transmissions will be sent at ½ the Fast Rate frequency (i.e., if the
Fast Rate was 90 seconds, it would send every 180
seconds.) "

If I was the programmer asked to literally implement this (even though
it has issues), a compliant approach would be
if current speed < slow speed setting:
    use slow beacon period;
else
    if current speed > high speed setting:
        use high speed beacon period;
    else
        period = high speed beacon period * high speed setting / current
speed.


The important thing here is the order or priority of these ifs. Though
you reported it never beaconed, it just might have been an extremely
long time.

Is the algorithm good? Well, the period vs speed function is
discontinuous but that is probably of little consequence.

Is it a good implementation? Probably not... but most things about APRS
have shortcomings. Just don't set the slow speed value to zero. Perhaps
the firmware and configuration program should enforce some limits so
users don't inadvertently disable the thing.

Save someone needing to comment, I know this will be far deeper than
most people might want to see, but Gordon, they shouldn't stop you from
understanding why it probably did what it did.


73
Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.aprs.net.au/pipermail/ozaprs/attachments/20141013/07ae26f2/attachment.html>


More information about the OZAPRS mailing list