Android Question GPS location event trigger time

Scantech

Well-Known Member
Licensed User
I am usin GPS speed value from
B4X:
Sub GPS_LocationChanged (Location1 As Location)
OK, when i'm inside the house observing the trigger refresh it is around 1 second/per event trigger at 0 mph. I have not yet tested it above 0 mph. I am assuming you get more refresh rate per second?

My second question, when the device is in the background with device screen off i have been observing my distance and it seems to be off by half at least. I'm trying to figure out if the refresh rate is declined at this state? If yes, what can i do to increase the rate?

Thanks in advance

Tested with Android 8

B4X:
    pws.PartialLock
    Service.AutomaticForegroundMode = Service.AUTOMATIC_FOREGROUND_NEVER
    Service.StartForeground(1, CreateNotification("Trip is running..."))
 

Scantech

Well-Known Member
Licensed User
It might be an issue with my codeing. I will double check.

But im still interesting to know if refresh rate is affected?
 

Scantech

Well-Known Member
Licensed User
I found the problem. I have a comparison below you can observe. I was using Distance = Speed/Time with 125 ms timer. The problem was, the timer not triggering at every 125 ms. My Phone was in my pocket while i was logging data and i have noticed nearly half of the distance data was missing. My phone was turning on and off causing anywhere from 126 to 2500 ms delay with timer. This was confirmed in the logger. The timer needed some kind of Delay compensation.

I was using this compensation
B4X:
Sub tmrTrip_Tick

    Dim WhatMs As Long

    If gpsStarted = True Then
        WhatMs = DateTime.Now - startTime
        startTime = DateTime.Now
    Else
        startTime = DateTime.Now
    End If

'more codes now shown

'somewhere below
    Calculate_TotalDistance(WhatMs)
this gets called in the timer above
B4X:
Sub Calculate_TotalDistance(WhatTimeMs As Long)
 
    Dim WhatFactor As Double
    WhatFactor = (WhatTimeMs/125) * 0.0000347222222222
 
    If CurrentSpeedValue = "-" Or CurrentSpeedValue = "" Then
    Else
        Dim CurrentDistance As Double
        CurrentDistance = (CurrentSpeedValue * WhatFactor)
 
        dTotalDistance(Select_Trip) = dTotalDistance(Select_Trip) + CurrentDistance    'combine all current distance in km
 
        If StateManager.isMph = True Then
            Dim ConvertDistance As Double
            ConvertDistance = (dTotalDistance(Select_Trip) * 0.621371)
            CallSub2(Trip, "Display_TotalDistance",  NumberFormat2(ConvertDistance, 1, 2, 2, False))
        Else
            CallSub2(Trip, "Display_TotalDistance", NumberFormat2(dTotalDistance(Select_Trip), 1, 2, 2, False))
        End If
    End If
 
End Sub
Well it turns out.... Distance = Speed * Time vs Latitude and Longitude vs Car Tripometer

2002 Toyota Camry
Data Result (Stop and Go Traffic)

1st Run (No toggle on/off switch)
Car Tripometer = 7.7 miles
Distance = Speed * Time Method = 7.55 miles Sorry, it was longitude and latitude will test tomorrow
Latitude and Longitude Method = 7.49 miles
Google Map = not sure there 2 sets of data 7.2 and 2.5

2nd Run (Toggled many times maybe over 15 times)
Car Tripometer = 2.6 Miles
Distance = Speed * Time = 2.55 Miles it was longitude and latitude will test tomorrow
Latitude and Longitude = 2.55 Miles
Google Map = 2.3 Miles

3nd Run (Toggled)
Car Tripometer = 1.5 Miles
Distance = Speed * Time = 1.48 Miles it was longitude and latitude will test tomorrow
Latitude and Longitude = 1.48 Miles

4th Run (Toggled)
Car Tripometer = 5.8 Miles
Distance = Speed * Time = 5.74 Miles it was longitude and latitude will test tomorrow
Latitude and Longitude = 5.75 Miles

The question is which is the most accurate Total Distance?
I will test the OBD2 Speed Sensor Data and see if that matches up with the Tripometer. I think the Cluster gets its distance by the Speed Sensor using Distance = Speed * Time. It will be interesting to know if the miles match up precisely.

I am planning to add Calibration Factor Mode option. So it will match the Tripometer.

Thanks

Update: Will test Distance = Speed * Time and OBD2 data tomorrow

1st Run (Main Exit while service running and no toggling)
Car Tripometer = 2.5 Miles
Distance = Speed * Time = 2.22 Miles
Latitude and Longitude = 2.42 Miles

2nd Run
(Main not exit and no toggling)
Car Tripometer =
2.5 Miles
Distance = Speed * Time = 2.43 Miles
Latitude and Longitude = 2.43 Miles

3rd Run
(Main not exit and no toggling)
Car Tripometer = 3.5 Miles
OBD2 = 3.43 Miles uses timer as well
Latitude and Longitude = 3.43 Miles

4rd Run
(Main not exit and toggling)
Car Tripometer = 1.6 Miles
Distance = Speed * Time = 1.59 Miles
Latitude and Longitude = 1.61 Miles

All i know is the data with Distance = Speed * Time did not loose half like it did before. Now, i think its related to Main being exited while service is running. Toggling did not do any harm as much as exiting Main.
 
Last edited:

emexes

Well-Known Member
Licensed User
The question is which is the most accurate Total Distance?
If you are getting regular GPS readings and the distance and speed are of driving-scale rather than walking-scale, then the most accurate will be the Latitude and Longitude method, since most of the error will come from the GPS position error at the start and end of the trip, which for a run-of-the-mill consumer device nowadays is within 5 metres, regardless of the distance traveled.

Whilst you are moving, there will also be some error in the positions of the intermediate points, but they mostly cancel out because:
(i) in the direction of travel, what you lose/gain on this reading, you gain/lose on the next reading, eg 15 + 25 = 25 + 15
(ii) laterally to direction of travel, since you're presumably travelling at car-like speeds, and because the errors tend to change slowly, those sideways movements tend to be negligible*.

The tripmeter distance primarily depends on the radius of the wheel from the axle centre to the road-tyre interface, which varies with tyre size and wear and pressure, which also varies with vehicle load (more weight = more pressure) and temperature. Distance also depends on the slip/grip between the tyre and the road, eg road surface material, and to a lesser degree, rain and incline. Odometers usually read off an undriven wheel, but you still get slip due to mechanical friction on the vehicle side of the tyre, and braking.

And then you have the issue that the odometer reading usually comes off one wheel, and thus one side of the car, so that if you are measuring distance on a track, then the outside wheel will travel slightly further than the inside wheel - for a 2 metre wide car, there would be a 12 metre difference between the left wheel and right wheel distances travelled for each lap.

Lastly, the GPS Latitude Longitude method is quietly ignoring altitude. But, happily, most driving happens on flat or gentle inclines, and GPS is less accurate for altitude anyway, thus I have not yet worried about it for my uses.


* or perhaps this extra distance due to random lateral error noise is mostly counteracted by the "lost" distance due to the path of line segments on a curve being shorter than the path of the curve, eg, if you did a 90 degree turn on a unit-radius circle, then the curve circumference distance is pi / 2 = 1.55 but the straight line distance is sqr(2) = 1.41
 
Last edited:

emexes

Well-Known Member
Licensed User
I think the Cluster gets its distance by the Speed Sensor using Distance = Speed * Time.
The wheel sensors measure rotation angle*, not speed directly (that I've ever seen).

Mechanical odometers measure distance by counting rotations of a wheel.

Electronic odometers measure distance by counting pulses of a toothed wheel (like a gear wheel) or similar optical transducer, eg 120 pulses per rotation.

And then the cluster (and transmission, engine, OBD, ABS, ESC, etc) get their speed by Speed = Distance / Time.


* sometimes that angle might be in 360 degree steps, ie one pulse per revolution, but... unless you are changing direction (ie, forwards <-> backwards) then the readings are still correct, just smoothed/averaged out
 

emexes

Well-Known Member
Licensed User
I am planning to add Calibration Factor Mode option. So it will match the Tripometer.
That match the tripmeter remark made me laugh. Our dynamometers gave the operator a choice of several power measurements:
- plain old boring actual power ie "at the tyre because that's what's pushing the car down the road"
- temperature compensated power, so that you would get the same power readings on hot and cold days = POBAP at 20 deg C from memory
- "manufacturer power" or "brochure power" which used a calibration factor to (more closely) match the manufacturer's published power

I don't know about California, but here on main roads between cities we have roadside mile marker posts (now kilometre marker posts, but that doesn't roll off the tongue as nicely) that are supposed to be super accurate. So perhaps you could calibrate to those. Although I guess that's going to cheese off vehicle owners when you tell them their tripmeters aren't reading right.

Hmm. Another thought is that speedometers here now have to read high by law (to thwart defending against speed camera fines), so I wonder if that carries through to the odometer reading as well. I would expect not, but...
 

Scantech

Well-Known Member
Licensed User
I don't know about California, but here on main roads between cities we have roadside mile marker posts (now kilometre marker posts, but that doesn't roll off the tongue as nicely) that are supposed to be super accurate. So perhaps you could calibrate to those. Although I guess that's going to cheese off vehicle owners when you tell them their tripmeters aren't reading right.
We have them. I seen few of them around, even here in Las Vegas. Speed calibration is good way and on top of that this method here for example, Report the difference in miles you see at 3000 miles from tripmeter and the app. Formulate that value in the equation.
 
Top