SmartBeaconing, was Re: [aprssig] Dupe Checking....

[Joel Maslak]

On Oct 4, 2007, at 7:40 AM, Robert Bruninga wrote:

> I don't think I ever had a problem with smart beaconing when set
> properly.  My concern was always for when it was set up badly.
> I was hoping that limits could be placed in the software
> implementations of it to kind of "watch over the users shoulder"
> and help him not make settings that would appear to be excessive
> on the network.


Okay, my misunderstanding.

A software developer could certainly set limits.  There are two ways  
of doing that - enforcing some sanity checking on the parameters or  
adding another parameter ("minimum position transmit time" or  
something like that).

If your user interface doesn't let you set any of the 3 SmartBeacon  
rates (slow_rate, fast_rate, and turn_time) in increments other than  
minutes, it is not possible to send a beacon more than once a minute.

I know you have the ear of the Kenwood people - it would be really,  
really great (and I'd probably end up buying one to replace my D700)  
if they implemented this in a firmware updated of the D710.  Have  
them set realistic limits to keep me from sending beacons every 10  
seconds (I told you how above - just make them set the rates I  
mentioned above in minutes).  I'd even be happy with it if some of  
the parameters were set to *reasonable* values for an automobile  
doing daily commuting and not user-editable (and you could probably  
create a formula to derive the rate settings from one "master" rate).

I'm sure a lot of people here could give you advice about what the  
defaults should be, since most hams wouldn't mess with the defaults  
for these parameters I think.  Figure out a nifty way of combining it  
with proportional pathing (easy: alternate paths for beacons).  And  
even disable it by default if you think uneducated users would be  
better off with higher beacon rates that are provided by fixed time  
beacons (the defaults for SmartBeaconing should be MUCH less often  
for slow speed than the D710 default, and about the same for high  
speed, with a turn time set to something realistic, but definitely  
NOT anything more often than the D710 default.  Combined with  
proportional pathing, I'd bet you could halve the number of D710  
packets an average amateur sends compared to *just* proportional  
pathing, which would seem to be a good thing.

It'd be great to have a D710 that didn't transmit just as many  
position packets when I'm parked in the parking lot as when I'm  
moving, I would think.  (right now, I have a delay power off for my  
D700 that leaves everything on for 30 minutes after I park -  
unfortunately that means I send *10* packets, one every 3 minutes,  
saying, "Nope, haven't moved at all!", when I probably should send  
about 3 packets for that same function, if even that many)

I'll also note that if you mentioned this to Kenwood, all the math  
can be done with integer math, so it's easy to implement in  
hardware.  There is some multiplication and two division operations  
though.