Re: [rtrak] "Smart Beaconing" ? ?
The RTrak is built around the SMT OpenTracker V2.0 and
since this is the case, the RTrak will have all
functions of the OpenTracker, including
I was actually introduced to SmartBeaconing by the
original device to have it, the HamHUD.
SmartBeaconing was developed by Steve Bragg KA9MVA and
Tony Arnerich KD7TA and they did a great job in trying
to include every possible parameter that would
determine the best beaconing rate and cycle. As we
all know, nothing is perfect.
The situation that you described has been a topic of
discussion in several forums, regarding
SmartBeaconing. There has been some talk of adding in
a function that will basically look for a drastic drop
in speed and then determine if it's a permanant stop
or just a stop at a red-light (for example). The best
way I see to do this is when there is a drastic drop
in speed, set a timer. If the timer expires, assume
the tracker is destinated and send a final packet to
show that, if not, resume tracking and normal.
Scott and Steve might be able to chime in here and
make a better suggestion.
--- Don Pomplun <BlueFlash@...> wrote:
> I haven't seen any mention of Smart Beaconing i.e.,
> interval linked to velocity parameter from the GPS.
> I've been told
> (but not expended the effort to rigorously confirm)
> that a problem
> with SB, as implemented in TinyTrak is that as soon
> as you drop into
> the realm of less-frequent beaconing, it immediately
> sets he interval
> to the "infrequent rate". In my (real world)
> example, if the train is
> going faster than 1 mph, I beacon every minute;
> below that speed I
> consider it stopped, and switch to a 30 minute
> interval. The problem
> is that I don't get "one last beacon message" as I
> go from running to
> stopped. So in one message I'm going 25 mph, and
> suddenly I get
> nothing for 30 minutes. I reason that I should get
> an additional
> message as soon as I fall into the slower realm so I
> know it has
> happened. How is Rtrak handling this?