[Loadstone] Tripmeter

Ari Moisio arimo at iki.fi
Tue Jun 17 09:28:46 BST 2008


Hi Shawn

On Mon, 16 Jun 2008, Shawn Kirkpatrick wrote:

> The accuracy is computed by using hdop * ure and that value is in metres. If
> your receiver has a minimum accuracy of 40 metres then it should be tossed
> in to the nearest bin. The receiver has either gone bad or you're
> doing a lot of walking around in underground areas. The globalsat is
> known for being rather bad for heading spin but its accuracy is fine.

   I had to set the URE value to 40 meters (with Holux M-1000 to 50 meters) 
to stop the tripmeter to advance because of gps drift in poor receiving 
conditions, usually indoors or large covered areas.

  The problem is that neither of the receivers do not follow the standard 
rule to use maximum error divided by some constant as a base of HDOP but 
will just throw some value, usually below 1.0 outdoor and below 1.5 indoor 
as a indication of receiving condition. Usually the HDOP starts with 
higher value after receivers has booted but the value drops within few 
minutes.

My old sirf-2-based Globalsat gave more sensible HDOP values but it was 
othervise  not accurate as more modern receivers.

   Instead of HDOP one can for example take a snapshot  with the phone's 
front camera and measure it's brighness and color.  Outdoor will give 
brighter image than indoors and  if the image is both brigh and blueish 
the receiving conditions are probably excellent. Even easier to use the 
number of  actively used  satellites. The more satellites, the better 
reception and better accuracy.

  > Minimum gps accuracy should be around 15 metres and maximum of
> 50. The trip metre distance is calculated by just adding up the distances
> traveled. Rounding up would only increase error.

  Rounding does not increase the eror much. Even better would be to show 
the actual value rounded. This will   increase the actual error maximum 5 
meters  but prevent the value to look like too accurate. There is no  need 
to display more significant digits than is the maximum possible accuracy. 
I haven't looked the source code but if the  distance between the route 
points is rounded to meters even this will cause some error.

btw: i  dropped the URE value to 5 meters and got  trip distance of 520 
meters as a trip value as compared to 500 meters as a locked point 
distance.  Not bad at all. Measured with Holux. I'll continue to look for 
optimal URE value for both sirf-3 and MTK-based receivers for outdoor use.

  >
> On Mon, 16 Jun 2008, Ari Moisio wrote:
>
>> Hi
>>
>>  After trial-and-error a found ure avlue of 40 meters high enough for
>> Globalsat sirf-3-based receiver, not tested with others yet.
>>
>>  Of course with values like this the estimated gps error makes no sense
>> and also the tripmeter lacks behind somewhat for shorter trips,  for
>> longer trips the errors does not matter.
>>
>>  Only relation between DOP and actual error is that with hign DOP values
>> the variation in reported location migth be greater. Another way to
>> determine the accuracy would just be to divide some user-defined value,
>> for example 200, with the number of actively used satellites. Even better
>> would be satellites minus three and tripmeter is not update if the number
>> of satellites is below four.
>>
>>  I'll continue the search to find also the minimum usable value for some
>> receivers before the error increases too much.
>>
>>  Btw: counting distance in one meter resolution will give wrong sense of
>> accuracy. It would be better to use  rounded-up values to next full ten
>> meters or 50 ft.
>>
>> You can still escape from the Gates of hell: Use Linux!
>> --
>> mr. M01510 & guide Loadstone-GPS
>>
>>
>> On Sun, 1 Jun 2008, Shawn Kirkpatrick wrote:
>>
>>> Once you find the propper ure for your receiver things should be fine since
>>> the accuracy value goes up with a bad signal.
>>> A manual update for a trip meter makes no sence since it wouldn't take in to
>>> account things like turns that may double back on the route. It would be
>>> like riding in a car and having to hit a button to make the odometer count
>>> up, that just doesn't happen. The trip meter may be slightly inaccurate but
>>> it'll really depend on your receiver, if you have bad drift you'll have more
>>> trouble than the trip meter.
>>>
>>> On Mon, 2 Jun 2008, Ari Moisio wrote:
>>>
>>>> Hi
>>>>
>>>>  Current value works best with static navigation -spoiled devices.  It
>>>> is however usually not the failure of receiver but the temporary failure
>>>> in the receiving  condition that makes the excessive drift.
>>>>
>>>>  Could you please elaborate,  what makes  the manual alternative in the
>>>> ripmeter 'ridiculous'? If we have for example a city with street corners
>>>> with better reception condition as the streets between them. Would it make
>>>> sense to update the tripmeter fewer  times with a good signal condition
>>>> than many more times with more erroneus signal?
>>>>
>>>>
>>>>
>>>>
>>>> You can still escape from the Gates of hell: Use Linux!
>>>> --
>>>> mr. M01510
>>>>
>>>>
>>>> On Sun, 1 Jun 2008, Shawn Kirkpatrick wrote:
>>>>
>>>>> The default ure value should work for most good receivers. Getting a propper
>>>>> value for your particular receiver may be trial and error. If you have that
>>>>> much drift then you'll probably have speed trouble as well.
>>>>> The trip meter in exploration mode is on the todo list.
>>>>> Manually updating the trip meter is a bit ridiculous, you don't do that
>>>>> anywhere else.
>>>>>
>>>>> On Sat, 31 May 2008, arimo at iki.fi wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>>  Tripmeter is a nice feature but...
>>>>>>
>>>>>> - Using user range error to calculate minimum movement to count is too
>>>>>> low. I have set URE to 10 meters, quite high value for decent receivers
>>>>>> but still walked  almost 400 meters just sitting on my garden. Finding a
>>>>>> good value for minimum movement is  trial and error but current value is
>>>>>> too low. I'll look for higher values for URE if they would help.
>>>>>>
>>>>>> - Also not  updatin the tripmeter if speed is below  static threshold d
>>>>>> might help.
>>>>>>
>>>>>> - There could a manual mode  where distance is advanced only by user
>>>>>> request or by giving any LS command.
>>>>>>
>>>>>> - There could be a parallel  tripmeter counting from zero everytime LS
>>>>>> is started.
>>>>>>
>>>>>> - There could be a tripmeter-like functionality in the exploration mode
>>>>>> too.
>>>>>>
>>>>>> - LS converts stored distance kilometers to meters when closed and
>>>>>> launched again.
>>>>>>
>>>>>>
>>>>>>
>>>>>> You can still escape from the Gates of hell: Use Linux!
>>>>>> --
>>>>>> mr. M01510
>>>>>>
>>>>>> _______________________________________________
>>>>>> Loadstone mailing list
>>>>>> Loadstone at loadstone-gps.com
>>>>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>>>>>
>>>>> _______________________________________________
>>>>> Loadstone mailing list
>>>>> Loadstone at loadstone-gps.com
>>>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Loadstone mailing list
>>>> Loadstone at loadstone-gps.com
>>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>>>
>>> _______________________________________________
>>> Loadstone mailing list
>>> Loadstone at loadstone-gps.com
>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>>
>>>
>> _______________________________________________
>> Loadstone mailing list
>> Loadstone at loadstone-gps.com
>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>
> _______________________________________________
> Loadstone mailing list
> Loadstone at loadstone-gps.com
> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>
>

You can still escape from the Gates of hell: Use Linux!
-- 
mr. M01510 & guide Loadstone-GPS




More information about the Loadstone mailing list