Editing the Nav Stored Locations via SD Card

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
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.
 
evnow said:
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:
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,65535

47.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"
# Thus, one grid point here represents about 113 arcseconds about
# 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.
 
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:
x = (longitude + 172)*65,536 + 15,728,640
y = latitude*98,304 + 16,777,216

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

longitude = (x - 0x0f00000)/0x10000 - 172
latitude = (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:
u = (grid_data & 0x7FFFFFFF) + 0x80000000
grid_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:
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:
xh = ((u & 0xFFF0) >> 2) | (u & 0x0003)
yh = (((u >> 16) & 0xFFF0) >> 2) | ((u >> 16) & 0x3

u = ((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:
x = (xh << 11) | xl
y = (yh << 11) | yl

xh = x >> 11
xl = x & 0x7FF
yh = y >> 11
yl = 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.
 
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?
 
kcarmich said:
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/trunk/Code/NissanLEAF/parse_addresses.py" onclick="window.open(this.href);return false; ) 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.
 
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.
 
kcarmich said:
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.
 
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.
 
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.
 
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?key=0Ask8xyuIo1sMdEtVdTlYa3JIR2lYX2h0R2ZNWTlkZlE&usp=sharing" onclick="window.open(this.href);return false; -- Set in my sat nave using an additional SD card :)
 
Timehorse I found the problem...

you have a typo in your calculations above

u = ((yh & 0xFFF0) << 18) | ((yh & 0x0003) << 16) | ((xh & 0xFFF0) << 2) | (xh & 0x0003)

these should be 0xFFFC not 0xFFF0 I was missing two bits from both the X and Y in my result.
 
Timehorse,

Just sent you my data as a ZIP file. Can you look and confirm the system is the same for Europe, please?

FYI, the EU LEAFs contain navigation data for the whole of the EU.

Nikki.
 
kcarmich said:
Timehorse I found the problem...

you have a typo in your calculations above

u = ((yh & 0xFFF0) << 18) | ((yh & 0x0003) << 16) | ((xh & 0xFFF0) << 2) | (xh & 0x0003)

these should be 0xFFFC not 0xFFF0 I was missing two bits from both the X and Y in my result.

Wow! Great catch! Yeah, actually it should have been 0x3FFC not 0xFFF0 since the upper 2 bits aren't used in the calculation anyway. Sorry for the typo but I fixed the original post and left a note of thanks on the bottom.
 
Glad I could help half of the inimitable Transportation Evolved (aminorjourney) team from the AECN team, meaning me. :) I would like to welcome anyone who's interested in joining me in developing my python script further to send me a PM and I'll add you to my access list. The code itself is public but the Trac ticker and editing access require authentication.

https://svn.timehorse.com/public-repos/trunk/Code/NissanLEAF/parse_addresses.py" onclick="window.open(this.href);return false;

I'm looking for LEAFs in Australia, South America, Africa and East Asia if possible to compare Address Books. It looks like the European address book is just a single bit different from North America which bodes well for supporting other regions. Also would like to get the extent of the European maps. All this is to help us all rack up those EV miles/km and to do more eTrekking!
 
So... after a week where my feet didn't touch the ground, I've finally grabbed a few moments to get the coordinates of the UK map.

It appears (though I couldn't get it to go right to the edge) to run from 22 degrees North, 20 degrees west to 80 degrees north, 68 degrees east.

Does that fit in with what people are expecting?

Nikki.
 
aminorjourney said:
So... after a week where my feet didn't touch the ground, I've finally grabbed a few moments to get the coordinates of the UK map.

It appears (though I couldn't get it to go right to the edge) to run from 22 degrees North, 20 degrees west to 80 degrees north, 68 degrees east.

Does that fit in with what people are expecting?

Nikki.

Oh, that is interesting! Thanks Nikki! So it don't quite go to the equator after all, unlike North America where it does. 20W to 68E is interesting though clearly Iceland isn't completely covered, nor is the entire Middle East. Since this is interesting to everyone on Earth, here's a Fusion Chart of the regions we currently have covered between Nikki and myself:

https://www.google.com/fusiontables/DataSource?docid=1e9nF7jYXcC1U2jeiL1-9PFgXvrsFPlrcKX7RsOYc" onclick="window.open(this.href);return false;

Still a lot of Earth uncovered and one wonders what map is loaded onto an Icelandic LEAF or a Saudi LEAF (believe me, the LEAF and electric cars, generally cars that don't run on Petrol, are very popular in the Middle East; they know all about the Resource Curse they suffer from). As well as of course all of South America, Africa, Australia, China and of course Japan.

PS: Thanks a lot Google! It took me hours to figure out how to do that incredible simple map! :roll:
 
This thread is mainly about coding an application, but it was closest to my question.

Does the Leaf store any personal navigation info on the right SD card? I know it has capability to transfer addresses to a left SD card. Is it our responsibility to back up own data (I have a full address book) or does the system automatically do back ups to its own SD card?

Based on descriptions (I do not want to mess with the card on the right), it just a regular SD card, not a mini?
 
With the base of TimeHorse's script, I created a gpx2slc conversion script. Obviously It takes a gpx file and converts it to slc ;)

With TimeHorse's permission, I'd like to publish my script here. At the moment there's some limitation though:
  • A maximum of 200 POIs is supported. This limitation is coming from the Leaf's navigation system.
  • The geographic region for encoding the coordinates is currently hard-coded to Europe. This can be changed to North America in poi_collection.py line 91 by changing it Europe to North_America.

Unfortunately I cannot attach my script here, but if anyone is interested in getting it, just send me a PN with your E-Mail-Address.

In the future I plan to write a GUI, that supports filtering the contents of a gpx and then exporting to slc. Unfortunately my time is a bit limited currently and this might not happen too soon :roll:

If someone is interested in helping me on that, he's very welcome. Only some knowledge on Python and Qt is required (already started to write the GUI in Qt).
 
Hello!

I have read all posts. But I am slightly perplexed.
If I undestand the "storedlocation.slc" file format correctly, it contains a header (256 bytes) ans items. Each item contains 30 fields.
Discussion in this thread is related to the fields 1, 2, 9, 10 and 11 (how to calculate the 9, 10, 11 field values by the values of the 1 and 2 fields.

Looks like the following post http://www.mynissanleaf.com/viewtopic.php?f=37&t=2483&start=80#p356265 contains formulas for calculation. But I have not understood how these formulas can be applied.
Does anybody understand that algorithm? If so, please write here an exact formula for calculation fields 9, 10 and 11 by fields 1 and 2 ?
Something like this:
F9 = function(F1, F2)
F10 = function(F1, F2)
F11 = function(F1, F2)
 
Back
Top