Loading ...
Sorry, an error occurred while loading the content.

Re: [rtrak] "Smart Beaconing" ? ?

Expand Messages
  • Jason Rausch
    Don, 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
    Message 1 of 3 , Jan 16, 2008
    • 0 Attachment
      Don,

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

      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.

      Thanks,
      Jason KE4NYV
      RPC Electronics
      www.rpc-electronics.com

      --- Don Pomplun <BlueFlash@...> wrote:

      > I haven't seen any mention of Smart Beaconing i.e.,
      > Beaconing
      > 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?
      >
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.