Notifications
Clear all

Decoding GPS

9 Posts
6 Users
0 Likes
1,241 Views
nsbuck
(@nsbuck)
Posts: 91
Trusted Member
Topic starter
 

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?

 
Posted : 05/07/2018 9:40 am
(@trewmte)
Posts: 1877
Noble Member
 

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?

From a quick search on Google did this not help

https://www.google.co.uk/search?source=hp&ei=lBE-W4voHsiTgAa_r4aICw&q=.sav+file+viewer&oq=.sav+file&gs_l=psy-ab.1.2.0l10.1793.1793.0.9793.1.1.0.0.0.0.113.113.0j1.1.0....0...1c.1.64.psy-ab..0.1.111....0.vJCOznq9cn4

What is the make/model of satnav?

 
Posted : 05/07/2018 12:44 pm
nsbuck
(@nsbuck)
Posts: 91
Trusted Member
Topic starter
 

It does not

NavMan S90i

 
Posted : 05/07/2018 1:29 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

From the little I can understand from here
https://www.gpsbabel.org/index.html
(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

 
Posted : 05/07/2018 7:36 pm
(@pypdnl)
Posts: 6
Active Member
 

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

 
Posted : 06/07/2018 8:55 am
nsbuck
(@nsbuck)
Posts: 91
Trusted Member
Topic starter
 

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.

 
Posted : 06/07/2018 2:09 pm
watcher
(@watcher)
Posts: 125
Estimable Member
 

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?

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

Note that the XRY numbers you posted have inconsistent precision, this may be a quirk in presentation or a minor error.

 
Posted : 06/07/2018 3:49 pm
nsbuck
(@nsbuck)
Posts: 91
Trusted Member
Topic starter
 

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.

 
Posted : 10/07/2018 1:25 pm
(@polar)
Posts: 48
Eminent Member
 

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.

 
Posted : 13/07/2018 10:19 am
Share: