dashcam GPS latitude/longitude wrong

[Martin314]

Thanks for taking a look.  I noticed the same thing (points not close enough together) when I looked more closely at longitude and realized that I wasn't seeing any patterns pop out in the bit patterns.  I have some more data points that are sequences of 6 or 8 numbers in a row at that point around 0 and 180 degrees longitude.  I'll keep adding data points from latitude and upload a new file when I have a nice collection.

[Martin314]

Attached is a more detailed mapping for Latitude values only.  (390 rows)
I have tried to include at least 16 adjacent values in a row for new test cases, as well as staggering out samples across the entire latitude range.

If there are any specific ranges where additional data points would be helpful, please let me know! 

[obetz]

Actual Longitude = (Raw_Longitude - 1474560) * 0.000122070312

This is obviously a scaling with powers of two:

0.000122070312 = 1/8192

8192 = 2**13

1474560 / 8192 = 180

So your formula can simplified to:

Actual Longitude = Raw_Longitude  / 8192 - 180

Oliver

[Martin314]

Thanks Oliver, good catch on seeing the 8192.    It seems I made a transcription error though between my notes and the post which I didn't find until I actually tried to use the formula.

1474560 is the raw value range between 0 and 180, so +1 in raw value represents 1/8192th of a degree.  I divided 180 / 1474560, if I had done it the other way around I would have noticed 8192.

0x4509732E = 0 Longitude

So the formula actually should be:
Actual Longitude = (Raw Longitude - 1158247214) / 8192

The zero point unfortunately isn't evenly divisble by 8192.

This relationship holds for values as least as low as 0x45000000 and as at least as high as 0x45800000, although it falls apart somewhere outside that range.  Fortunately we don't care about this as valid longitudes are between +0 and +180 (since E/W is a separate field).

[obetz]

0x4509732E = 0 Longitude

A huge number containing two large primes: 1158247214 = 2*9679*59833, not looking good in any common number base.

Your wrong number looked better <g>.

Oliver

[Martin314]

The longitude seems pretty easy to translate, but any ideas on the latitude?  If not, I'll try to find some time this weekend to crack it.

[Martin314]

It seems the GPS player for PC interprets out of range values differently than the Mac version.  On the Mac version I was getting ridiculously huge numbers (e.g. 0xFF000000 = 56713729510357210881534969900898975744.00000000 degrees) whereas on the PC if either latitude or longitude are out of range an incorrect value is shown for both, usually fairly small (< 2 degrees for latitude and < 20 degrees for longitude from what I've seen) but it does vary a bit.

Anyway, I discovered another interesting data point - a single increment of the raw value does NOT equate to the same difference in latitude values; it's dependent on the latitude value!  Additionally, I can't get any value to hit 0 degrees or 180 degrees exactly.

Code Select Expand

Hex      Dec            Longitude    difference from next
44E5E65C 1,155,917,404  -2.333330    N/A
44E5E65D 1,155,917,405  -179.999954  -0.00006100000002
44E5E65E 1,155,917,406  -179.999893  -0.00006099999999
44E5E65F 1,155,917,407  -179.999832  -0.00006099999999
44E5E660 1,155,917,408  -179.999771  N/A
...
4509732D 1,158,247,213  -0.00014     -0.00013
4509732E 1,158,247,214  -0.00001     0.0001
4509732F 1,158,247,215  -0.00011     0.00012
...
451FF32B 1,159,721,771  -179.999619  0.000122
451FF32C 1,159,721,772  -179.999741  0.000122
451FF32D 1,159,721,773  -179.999863  0.0001355
451FF32E 1,159,721,774  -179.9999985 N/A
451FF32F 1,159,721,775  -2.333330    N/A

Strange that there are almost two orders of magnitude in how much each increment changes the longitude going from -180 to 0, but then going back to -180 again it's negligible.  Because of this the difference between -180 to 0 is 2,329,809 while from 0 back to -180 it's only 1,474,560. However, it doesn't seem the dashcam actually uses this second range to encode any values; there is just some kind of weird quasi-symmetry going on in the decoder. 

I'm not sure where the sign of the longitude is stored, either, but I haven't been able to get a positive value manipulating just the 4 bytes holding the longitude.  I'm using a hex editor to patch values in, as I can't seem to find a way for `exiftool -ee` to write data back.

[Phil Harvey]

This is very interesting.  I'm glad to see someone else taking a crack at this because I just don't have the time myself to work on it.

- Phil

[Martin314]

I think I have found an algorithm for finding the longitude when it is between 0 and -180 (180 degrees west).

First, the latitude and longitude are both stored as 32-bit values in big endian format.  So looking at the byte order in the file with a hex editor if I see 78 56 34 12 then this yields a raw value of 0x12345678.

Now, if the raw value is of the form 0x44XXXXXX, then our divisor is 16384, our subtrahend is 0x44E5E65D and our base is -180.
But, if the raw value is of the form 0x45XXXXXX, then our divisor is 8192, our subtrahend is 0x45000000 and our base is -75.59938.

We then subtract our subtrahend from our raw value, then divide by our divisor to get the offset number of degrees, which we add to our base to get the longitude value.

It may be possible to simplify this algorithm further.

At this time I don't know how to represent positive longitude values (or negative latitudes).  I can't get any samples to test it out with.  There may be a bit somewhere else; I have experimented with a few locations but haven't been able to get a positive longitude or negative latitude to come out yet.  exiftool with the -ee option shows a speed and track reference, but no E/W/N/S for the latitude longitude.  For all I know the manufacturer designed this to only work on the north/west hemisphere!

I'll come up with some test cases the verify the above algorithm and then work on the latitude next... it appears to have a similar phenomena where part of the range has half the resolution, but in this case it seems that adjacent values simply translate to the same latitude.

[Phil Harvey]

I think you should be looking at the values as IEEE 4-byte floats.  The 0x44 and 0x45 at the start are the exponent part

- Phil