--- In [email protected], James Ewen <ve6...@...> wrote: > > On Thu, Jul 29, 2010 at 6:00 PM, Chris <wellre...@...> wrote: > > > I have done some additional test and believe that what you are > > describing (and what I intially suspected) is correct. However, > > I think this is a really a software glitch because 0 MPH is a boundary > > condition and the software should be smart enough to disregard > > normal position variation in sequential GPS fixes at very low speeds. > > Okay, so we tell the GPS to ignore any position fixes it sees until it > can calculate that it is moving at 5 mph or better... So how do we > determine if we are moving at better than the threshold speed if we > are ignoring new positions until we are moving? Kind of a catch 22 > situation. > > What if we are moving at a rate below the threshold value? How far do > we let the position deviate from what we think is the actual position > before we announce that we are at a new location? > > Obviously the 5 mph rate above is probably a little high. There are > GPS units out there that attempt to figure out if the "wandering" is > due to calculations, or actual user movement, but those units will by > design have to ignore some user induced movements in order to try and > cover up the calculated errors. > > SmartBeaconing and CornerPegging were designed and implemented on > resource poor devices many years ago. There wasn't a lot of processor > power, nor memory available for sophisticated routines to attempt to > eliminate GPS "wandering", nor was there any desire to do so, as > SmartBeaconing and CornerPegging were conceived as a way to have > vehicular based trackers automatically back off their reporting rates > when they slowed down, yet still report the important events as they > happened. This was at a time when people set their trackers to beacon > every minute or two, and would leave them on 24 hours a day. The > airwaves were flooded with vehicles parked in driveways or parking > lots screaming out all day long "I'm still here!". > > You are trying to design a system to drive a finishing nail with a 20 > lb sledgehammer... your fingers are going to get sore. What you need > to do, is to come up with a routine that not only allows you to > continuously vary your beacon rate similar to SmartBeaconing, but also > does the fuzzy decision making for when the rate of real position > change is less than the variability due to RF vagaries. Get that > routine fleshed out, and polished up, and it will be the next best > thing since SmartBeaconing... (Uh-oh, I'm going to upset Lynn with his > Genius routine!) > > James > VE6SRV >
James, I pretty sure the software in the T2 and/or the intrinsic algorithm has already solved the problem of phantom turning arising from positional uncertainty at low speeds. I also completely agree that smartbeaconing is a simple solution that can help reduce the bandwidth problem that arises from constant rate beaconing. However, the problem I am describing arises when the end user innocently selects 0 as the low speed as compared to a small non-zero value. In BOTH cases the behavior of the T2 should be exactly the same whenever it receives 0 MPH data that varies positionally. (After all 0 is 0 no matter how you get there.) It should: Set "Actual Beacon Rate" to the "Low Speed Beacon Rate" that the user set, AND it should ignore phantom turning. The T2 ignores phantom turning if the Low Speed Threshold was set at 2 MPH (and the GPS speed data is 0) but does not NOT do correctly ignore phantom turning if the user set the Low Speed Threshold to 0 (and the GPS speed is 0). The problem is probably related to whether there is a "<" or a "<=" at a critical branch point in the program OR a multiply and/or divide by 0 issue. I have opened another thread that poses the question more directly. Chris KF7FIR
