SmartBeaconing, was Re: [aprssig] Dupe Checking....
jmaslak-aprs at antelope.net
Thu Oct 4 09:00:58 CDT 2007
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
More information about the aprssig