## Editing the Nav Stored Locations via SD Card

TimeHorse
Gold Member
Posts: 999
Joined: Thu May 13, 2010 4:40 am
Delivery Date: 02 Nov 2011

### Re: Editing the Nav Stored Locations via SD Card

Currently measuring about 1540m between grid points or about 113 arc-seconds West at 38N48'45" latitude.

Can someone measure at about the same latitude on the West coast to see if it remains 1540m?

The calculation is simply cos(latitude)*92.5/3*s where s is the number of arc-seconds between the two grid points which are separated by one unit.
RIP CO2 Fre, 27 months, 42,282 mi & 11 bars.
unAmerican Job & Nissan's Rapid Depreciation cost \$20,000!
5 hours on the road daily w/o Charge at Work on 100%.

Long Live CO2 Fre, Maxed 2013 SL, 20,000 mi/yr lease.
http://aecn.timehorse.com/

TimeHorse
Gold Member
Posts: 999
Joined: Thu May 13, 2010 4:40 am
Delivery Date: 02 Nov 2011

### Re: Editing the Nav Stored Locations via SD Card

evnow wrote:As expected, the import worked fine and is showing all the 17 locations.

BTW, I had also stored Rairdon's earlier - so here is the comparison.

Code: Select all

`47.338402,-122.220001,0,00,00,00,526169646F6E204E697373616E00,00,-1551855391,69,490,,,,,0,0,-1,0,1,44,0,-1,3000,-1,4294967295,65535,6553547.338889,-122.221111,0,00,00,00,33355448205354204E4500,00,-1551855392,1882,556,,,,,0,0,-1,0,1,0,0,-1,3000,-1,4294967295,65535,65535`

I threw these into my Python script and drew the following conclusions with locations nearer to 38N48'45" and here's what I got:

# Grid Data Notes
# -1659656333(0, 0) = 38N48'45" 77W01'52"
# -1659656334(0, 0) = 38N48'45" 77W03'45"
# 1540m
# math.cos(latitude)*92.5/3*113 to get approximate arcsecond length
# From EVNow
# -1551855391(69,490) = 47N20'18" 122W13'12"
# -1551855392(1882, 556) = 47N20'20" 122W13'16"
# North/South here are noise represented by AFAICT 66/2048ths of a
# unit and 2 arc-seconds and thus about 61.666666666666666666666666666666666666666667m
# East/West represents 4 arcseconds and thus about 120.6m and maybe
# 234/2048 ticks of grid data; this makes about 1,056m per grid point

If these conclusions are right, about 10 degrees North represents a shortening of Grid Data Points by about 500m. Curiouser and Curiouser.
RIP CO2 Fre, 27 months, 42,282 mi & 11 bars.
unAmerican Job & Nissan's Rapid Depreciation cost \$20,000!
5 hours on the road daily w/o Charge at Work on 100%.

Long Live CO2 Fre, Maxed 2013 SL, 20,000 mi/yr lease.
http://aecn.timehorse.com/

TimeHorse
Gold Member
Posts: 999
Joined: Thu May 13, 2010 4:40 am
Delivery Date: 02 Nov 2011

### Re: Editing the Nav Stored Locations via SD Card

Update: I think I have the equation for converting between the Map Data Grid, X and Y and longitude and latitude and rather than making anyone else suffer, let me spell it out here for all to see. This information wasn't meant to be proprietary, it was meant to be free as in speech, but in this case also free as in beer!

The Grid Data collectively stores a 25-bit number for the longitude (x) and a 25-bit number for the latitude (y). The North American Nissan LEAF maps only distend over a range from 172W to 52W Longitude and from 0N to 80N in Latitude. The North Pole is not part of the map, and neither is Iceland or Europe or the Prime Meridian. Thus one third of the Earth by Longitude (120 degrees or 432,000 arc-seconds) and almost half by Latitude (80 degrees or 288,000 arc-seconds). The mapping between x, y and Longitude, Latitude is a linear function mapping the 25-bit values to their degree, minute, second mapping, respectively, as follows:

Code: Select all

`x = (longitude + 172)*65,536 + 15,728,640y = latitude*98,304 + 16,777,216longitude = (x - 15,728,640)/65,536 - 172latitude = (y - 16,777,216)/98,304`
This is clearer if hexadecimal is used:

Code: Select all

`x = (longitude + 172)*0x10000 + 0x0f00000y = latitude*0x18000 + 0x1000000longitude = (x - 0x0f00000)/0x10000 - 172latitude = (y - 0x1000000)/0x18000`
Of course, that assumes you have x and y as the properly formatted, unsigned, 25-bit values. To get those you have to do quite a bit of jiggery-pokery. Specifically, the Data Grid is a negative, 32-bit value. I find it easier treat the grid data as an unsigned 32-bit value in my calculations so for instance -2,147,452,928 (-0x7fff8800) becomes 2,147,514,368 (0x80007800), specifically:

Code: Select all

`u = (grid_data & 0x7FFFFFFF) + 0x80000000grid_data = -(-u & 0x7FFFFFFF)`
It has to be done this way to preserve the sign, otherwise the grid_data will lose the upper bits.

That resolved, I've observed that, starting from 0x80000000 as bit zero and 0x00000001 as bit 31, bits 1, 12, 13, 28 and 29 are never used. In other words, 0x400C000C is a mask for all the bits never used in the grid data. Likewise, 0 and 18 are always set (bit 0 means the number is always negative), in other words 0x80002000 is a mask for the always-on bits. Ignoring bits 0, 1 and 18 for the moment, what's clear with bits 12, 13, 28 and 29 is that they don't enter into the calculation of position. What you effectively have when you ignore those bits is:

Code: Select all

`yyyyyyyyyyyy00yyxxxxxxxxxxxx00xx`
for the format of the upper register of the x and y components, xh and yh, where each letter represents a bit in u starting with bit 0. The conversion is thus:

Code: Select all

`xh = ((u & 0xFFF0) >> 2) | (u & 0x0003)yh = (((u >> 16) & 0xFFF0) >> 2) | ((u >> 16) & 0x3u = ((yh & 0x3FFC) << 18) | ((yh & 0x0003) << 16) | ((xh & 0x3FFC) << 2) | (xh & 0x0003)`
where << means bitwise shift left, >> means bitwise shift right, & means bitwise and and | means bitwise or.

Finally we have the Map Data X and Y components, which are each 11-bit, unsigned values, meaning they go from 0 to 2047; at 2048 the increment the high portion and go back to 0. We'll call these map X and Y points xl and yl respectively.Therefore:

Code: Select all

`x = (xh << 11) | xly = (yh << 11) | ylxh = x >> 11xl = x & 0x7FFyh = y >> 11yl = y & 0x7FF`
And from x and y you can now compute longitude and latitude as a floating-point number similar to the way its stored in the NavTech app. I've found this calculation to be accurate within 1 arc-second, the resolution of the longitude and latitude floating-point values, which represents about 30m (100 ft) of accuracy in latitude and less in longitude (by a factor of the cosine of the latitude). Ideally, this should be within a half a degree which would be within rounding error. Currently, the error represents as much as one arc-second difference between the Grid Data Longitude and Latitude and the stored Longitude and Latitude.

Anyway, that's the total skinny you've been waiting for. Hope this helps any would-be developer.

Edit: Fixed equation for u in terms of xh and yh thanks to kcarmich.
Last edited by TimeHorse on Tue May 13, 2014 2:31 pm, edited 1 time in total.
RIP CO2 Fre, 27 months, 42,282 mi & 11 bars.
unAmerican Job & Nissan's Rapid Depreciation cost \$20,000!
5 hours on the road daily w/o Charge at Work on 100%.

Long Live CO2 Fre, Maxed 2013 SL, 20,000 mi/yr lease.
http://aecn.timehorse.com/

kcarmich
Posts: 27
Joined: Fri May 18, 2012 10:20 am
Delivery Date: 11 Oct 2011

### Re: Editing the Nav Stored Locations via SD Card

these calculations seem close but not quite right for my location.

geo location
49.246389
-123.003611

griddata= -1528590221
xoffset=1798
yoffset=1719

If I follow the calculations to use lat/long to calculate the griddata and xoffset/yoffset, the offsets are within about +/- 16 but the griddata doesnt match significant bits of data.

can someone else confirm to see if my interpretation of the conversion is correct?

TimeHorse
Gold Member
Posts: 999
Joined: Thu May 13, 2010 4:40 am
Delivery Date: 02 Nov 2011

### Re: Editing the Nav Stored Locations via SD Card

kcarmich wrote:geo location
49.246389
-123.003611

griddata= -1528590221
xoffset=1798
yoffset=1719

Taking your grid data using my Python code (which implements the algorithm above among other things, https://svn.timehorse.com/public-repos/ ... dresses.py ) I find the coordinates 123W00'14", 49N14'48" which as a fraction is -123.003889 by 49.246667 which are rounded to the nearest arcsecond IIRC. Internally, though, the algorithm calculates -123.00381469726562 and 49.24665323893229 before rounding.

For reference, your geolocation in Degrees/Minutes/Seconds is 49N14'47" and 123W00'13" meaning the calculation is off by a second. So to be honest, that's about the level of error I was seeing in my original calculations. I could never get it more accurate than about 100m in either direction since an arcsecond represents about 30m to 60m.

Reversing the calculation from your original coordinates I get:

Grid Data: -1528590221
xoffset: 1811
yoffset: 1693

So off by 13 in X and by 26 in Y which I take it is what you're observing. I'm not sure exactly what's off here as again we're talking about distance less than 100m but I would welcome more data to see if we can narrow down the final arcsecond.
RIP CO2 Fre, 27 months, 42,282 mi & 11 bars.
unAmerican Job & Nissan's Rapid Depreciation cost \$20,000!
5 hours on the road daily w/o Charge at Work on 100%.

Long Live CO2 Fre, Maxed 2013 SL, 20,000 mi/yr lease.
http://aecn.timehorse.com/

kcarmich
Posts: 27
Joined: Fri May 18, 2012 10:20 am
Delivery Date: 11 Oct 2011

### Re: Editing the Nav Stored Locations via SD Card

thanks I am getting -1530716221 as a result trying to follow your description. so I am missing something on the conversion ... I will dig through your code to see what I am missing.

TimeHorse
Gold Member
Posts: 999
Joined: Thu May 13, 2010 4:40 am
Delivery Date: 02 Nov 2011

### Re: Editing the Nav Stored Locations via SD Card

kcarmich wrote:thanks I am getting -1530716221 as a result trying to follow your description. so I am missing something on the conversion ... I will dig through your code to see what I am missing.

Sorry for the bug in the instructions. For reference, I'm getting 0xa4e39073 in hex for the GridData and you're getting 0xa4c31fc3 which means it's off by 0x00208fb0 (Exclusive Or). In other words, the X portion of the Grid Data has only one errant bit but the Y portion is very off. I'd focus there. Interestingly enough, I seem to recall 0x8fb0 is one of the magic numbers in the calculation, like the number of points along the given axis.
RIP CO2 Fre, 27 months, 42,282 mi & 11 bars.
unAmerican Job & Nissan's Rapid Depreciation cost \$20,000!
5 hours on the road daily w/o Charge at Work on 100%.

Long Live CO2 Fre, Maxed 2013 SL, 20,000 mi/yr lease.
http://aecn.timehorse.com/

aminorjourney
Posts: 92
Joined: Fri Jul 30, 2010 10:46 pm
Location: Porland, OR

### Re: Editing the Nav Stored Locations via SD Card

HI Folks,

Is someone willing to help me prepare for this trip by helping load all of the various POI, KML, and other location files of public charging stations onto my LEAF's sat Nav? And by that, I mean help me convert the locations to LEAF-friendly data I can put onto an SD card? Maybe an image I can dd?

Right now, we're pretty full-up with trip planning, so if someone is willing to help me I'd be eternally grateful.

Cheers,

Nikki.
Nikki Gordon-Bloomfield

Editor, co-founder, transportevolved.com
Mom, Troublemaker.

TimeHorse
Gold Member
Posts: 999
Joined: Thu May 13, 2010 4:40 am
Delivery Date: 02 Nov 2011

### Re: Editing the Nav Stored Locations via SD Card

It wouldn't be too hard to accomplish with my python script based on a longitude, latitude and name, with any other settings like markers or sounds as you like. My Address Creator uses Python Keywords so you can do a limited set creation and generate grid points from the Longitude and Latitude and add them to an Address Book, then write it out to a file. Your SD card is (IIRC) FAT formatted and once you have the file, export your current addresses using the SD card then overwrite (backup your old file though!) the large address file whose name I can't recall at the moment but like I said you export and replace the file. If you want to put them into a google spreadsheet I could probably send you a file with the address book you need. Or send my your current address book too and I can append the entries, say via DropBox. Keep in mind the address book is limited to 200 entries in the LEAF.

Edit: Your trip is in Europe which uses a different SatNav than the US. These are US calculations but I'd be quite keen to make one for European settings, though I'm thinking the saved files are probably a totally different algorithm that would require starting again from scratch.
RIP CO2 Fre, 27 months, 42,282 mi & 11 bars.
unAmerican Job & Nissan's Rapid Depreciation cost \$20,000!
5 hours on the road daily w/o Charge at Work on 100%.

Long Live CO2 Fre, Maxed 2013 SL, 20,000 mi/yr lease.
http://aecn.timehorse.com/

aminorjourney
Posts: 92
Joined: Fri Jul 30, 2010 10:46 pm
Location: Porland, OR

### Re: Editing the Nav Stored Locations via SD Card

Great!

Thanks for offering help. Let's see what I can do in the next few days. (I'll need to ask my other half to take her Volt instead of my LEAF so I can tinker!)

I can tell you that the unit itself is based on the same tech, but obviously the location data may be different if the algorithm you describe remains true. Let me see if I can get some nav data exported over the next few days. Watch this space

Essentially, I'd like to get this: https://docs.google.com/spreadsheet/ccc ... sp=sharing -- Set in my sat nave using an additional SD card
Nikki Gordon-Bloomfield

Editor, co-founder, transportevolved.com
Mom, Troublemaker.