Hello,
I have a raw file which cannot be decoded showing addresses in ASCII and GPS in base 16 (hex).
The results below are taken from a similar file that XRY decoded -
Hex 788E3700 equates to 0.434040
Hex 74E8A819 equates to 51.319599
The file I am working on is a .sav file from a European sat nav.
Can anyone tell me how they got from the hex to the longitude and latitude please?
Hello,
I have a raw file which cannot be decoded showing addresses in ASCII and GPS in base 16 (hex).
The results below are taken from a similar file that XRY decoded -
Hex 788E3700 equates to 0.434040
Hex 74E8A819 equates to 51.319599The file I am working on is a .sav file from a European sat nav.
Can anyone tell me how they got from the hex to the longitude and latitude please?
From a quick search on Google did this not help
https://
What is the make/model of satnav?
It does not
NavMan S90i
From the little I can understand from here
https://
(not necessarily useful for you)
each and every manufacturer has its own "encoding format" for these data ( , besides a few (of course different) "standards".
jaclaz
Firstly, do you know XRY is doing the conversion correctly?
Secondly, an observation. If you treat the hex values as little endian, then the ratio
0x19A8E874 / 0x00378E78 is ~= 118.24 ~= 51.319599/0.434040
which suggests a simple relationship. However, there are some obvious questions such as how would it deal with -ve longitude and why isn't it making better use of the 32bits available i.e. even 360 degrees would only be ~ 0xD4FEFFB3.
Basically, I'd want some more example known values before assuming it is to do with the little endian value. As an experiment, could you manipulate the 'similar file' you decoded with XRY and put in some different Hex values and observe the output?
Good luck!
David
Had a look at little Endian but I too could not get a match.
Heres what I've got on a known file (the file I do need to work on is displayed differently) -
E007030B88291A02C71981FE05CFB61A68006900730074005F00610064006400720065007
3007300000073007900730000000000440075006E00650073002000570061007900000000
00025F4742520000005F4742520000004C003500200039005A00530000004C0069007600
500720070006F006F006C002C0020004B00690072006B00640061006C0065000000440075
006E006500730020005700610079E007030B88291A02 – date & time
C71981FE – Longitude
05CFB61A – latitude
68006900730074005F0061006400640072006500730073 – this appears to be a marker for an historic address
440075006E00650073002000570061007900 – Location name
4C003500200039005A005300 - postcode
440075006E006500730020005700610079 - address
4C00690076006500720070006F006F006C002C0020004B00690072006B00640061006C006
500 – City
I know the long & lat are correct as putting in the postcode into Google Maps verifies this.
Hello,
I have a raw file which cannot be decoded showing addresses in ASCII and GPS in base 16 (hex).
The results below are taken from a similar file that XRY decoded -
Hex 788E3700 equates to 0.434040
Hex 74E8A819 equates to 51.319599The file I am working on is a .sav file from a European sat nav.
Can anyone tell me how they got from the hex to the longitude and latitude please?
The above numbers work out (with rounding error) if you assume that they are "Little Endian", 32-bit Integer (signed or unsigned), scaled 23 bits.
2^23 = 8388608
Hex (LE) 788E3700 = 3640952 (dec); divide by 8388608 = 0.434035301
Hex (LE) 74E8A819 = 430499956 (dec); divide by 8388608 = 51.319593906
That works - Thankyou
Does anyone know if GPS & date informaiton is stored in the cityhistory_v4.sav file - Ive seen differect layouts from difference sat nav manufacturers which I would not have expected.
I can confirm that the 2^23 thing features in many files from iGo/NNG navigation software.
As for cityhistory, I've seen multiple versions of that file too, but it has been a few years. From what I recall there are no co-ordinates, but there is a timestamp (32 bit LE, Unix) near each city record. I couldn't tell you the significance of the timestamp off the top of my head though.