Editing the Nav Stored Locations via SD Card

[EVNation]

I'm open and willing to test anything.

I can give you some data for AZ but I only have 2 currently in my database. Avondale Nissan and Bookman's Tuscon. If you have other locations, I can add those in also.

 

[EVNation]

1. I suspect the 3rd parameter is altitude.

2. the next 3 entries (0x3030) are probably text fields.

3. The, the "street" or "address" text field, followed by another text field.
(these 5 fields could be name, phone, and address lnformation)

Unfortunately I do not have a LEAF to try out variations.

In the first 256-byte header, have you discovered anything other than the record count @0x24 that is not a fixed value?

Is @0x25 the high byte of the count?

Sorry for the delay, I missed this email.

I haven't figured out anything in the header block. It seems the address book is limited to 200 entries so it is only a byte. Whenever I have poked around in the header block it just fails to load. Also no matter what I do with the address book editing, the header doesn't change.

It would be good to get someone else's file so I could compare. If you have a leaf and want to send me your storedlocation.slc file I might be able to figure out more.

I have a bunch of the actual line item parameters figured out. Most of them are to do with things like the phone number, group id, distance and direction. I need to just go through all the options to figure them all out.

-Jeff

 

[turbo2ltr]

I'm open and willing to test anything.

Did you save the charging locations you visited ? Then, you can export those locations to an SD and share the file.

Hmm, I haven't visited any. lol.

Sorry I thought tests were needed to confirm positions were correct.

 

[evnow]

You will then have 17 new locations added to any you have saved. Every time you import, it just adds to what is there. You can clear the address book by selecting "Settings/Navigation/AddressBook/Delete Stored Locations"

Let me know if you have problems trying this.

I'll check this out and report back. Interestingly, I don't have a apre SD card now - will have to wait for the one I recently ordered.

 

[garygid]

If you Export 10 and then Import the same ones, does it make duplicates?

If not, it must be doing some comparison to judge "duplicates", right?
Have you made minor location changes (50 feet) (or description changes) and ended up with "duplicates"?

Only 200 locations?
That is insufficient to cover the stations that are (will be) in a 50-mile radius! Really poor design.

If you have 125 locations, if you Export, change something "significant" on 100 of them, and Import, will it choke?

Does the LEAF show us how many locations are loaded?

 

[EVNation]

If you Export 10 and then Import the same ones, does it make duplicates?

If not, it must be doing some comparison to judge "duplicates", right?
Have you made minor location changes (50 feet) (or description changes) and ended up with "duplicates"?

Only 200 locations?
That is insufficient to cover the stations that are (will be) in a 50-mile radius! Really poor design.

If you have 125 locations, if you Export, change something "significant" on 100 of them, and Import, will it choke?

Does the LEAF show us how many locations are loaded?

Yes. If you just save to the SD, then re import it creates dupes. Does not remove them from what I have found. They are pretty hard to manually delete also. The interface has too many steps. So I usually just blast all of them and reload. This is yet another reason why having a editor would be a good thing.

I haven't verified the 200 stored locations. It says this in the docs. I will give it a try sometime and verify.

The Leaf does show how many are in the address book.

-Jeff

 

[EVNation]

Only 200 locations?
That is insufficient to cover the stations that are (will be) in a 50-mile radius! Really poor design.

I should say, the Nav system does support more locations than this in the overall database. If you search for Restaurants, it goes off and finds lots of them. I don't think those are stored, they are just on demand. I am sure when they finally add Charger locations, they will handle this better.

The 200 limit is for address book entries which are things you would add yourself and are saved locally.

 

[garygid]

The 200 limit makes it difficult to load our own extensive lists of POIs, or even many user-gathered charging locations.

It should be relatively easy to write a "merge" program for these LEAF Export files, showing the user the "close-duplicates", and allowing elimination of unwanted "extras".

But, with the 200 limit, a geographical filter (rectangular or circular area(s)) would also be required.

 

[evnow]

I made a test file for Pacific NW (Oregon and Washington). It has 17 locations in it.

I'm going to try it. Did anyone else try it ?

BTW, if a person exports the file from one Leaf - can it be uploaded to another without modifications ?

 

[garygid]

We believe it can, but best to make a backup of the target LEAF first, then Clear the user-POI, then try to load the other-LEAF file.

If you can send me two (or more) files from different LEAFs, I will try to merge them into one file and send it back to you to test. PM if you want to try.

 

[EVNation]

I made a test file for Pacific NW (Oregon and Washington). It has 17 locations in it.

I'm going to try it. Did anyone else try it ?

BTW, if a person exports the file from one Leaf - can it be uploaded to another without modifications ?

I have verified the file in at least one other Leaf. Not sure if that goes across to others. It has some unique id numbers that could relate to the specific car in there, but worked fine importing when I tried it on a second leaf.

 

[LEAFer]

I have backed up my file. A few technical questions ...

1. What is the "sts" file for ?
2. The ".slc" file: By eliminating the "header" (in a text editor) I can import data as CSV to Excel. The first two columns are obviously Long/Lat. Do we know what's in the 5th and 7th column ?
3. Purpose of the other columns ?

(The 5th column appears to contain only "0", except that in my case the last entry in the file happens to contain a very long HEX string in that column which is suspiciously similar (but much longer) than the data for that location in the 7th column. I happen to know that that location is L1, and is an entry whose name I edited after it was automatically stored after charging there ! Hope this helps I'll post more when I have time to decode it ... but the hint is ... 7th column is the automatically assigned street name of the location, 5th is the user edited name. Also: my 17th column for that location only contains a "1" instead of "0".)


Update: Figured it out ! The 5th & 7th column are encoded with the Ascii character set Hexadecimal equivalent of the "name" of the location, followed by the NULL ("00") character. So for example, "LAGUNA BLVD Henrys Market" becomes "4C4147554E4120424C56442048656E727973204D61726B657400"

 

[EVNation]

I have backed up my file. A few technical questions ...

1. What is the "sts" file for ?
2. The ".slc" file: By eliminating the "header" (in a text editor) I can import data as CSV to Excel. The first two columns are obviously Long/Lat. Do we know what's in the 5th and 7th column ?
3. Purpose of the other columns ?

(The 5th column appears to contain only "0", except that in my case the last entry in the file happens to contain a very long HEX string in that column which is suspiciously similar (but much longer) than the data for that location in the 7th column. I happen to know that that location is L1, and is an entry whose name I edited after it was automatically stored after charging there ! Hope this helps I'll post more when I have time to decode it ... but the hint is ... 7th column is the automatically assigned street name of the location, 5th is the user edited name. Also: my 17th column for that location only contains a "1" instead of "0".)


Update: Figured it out ! The 5th & 7th column are encoded with the Ascii character set Hexadecimal equivalent of the "name" of the location, followed by the NULL ("00") character. So for example, "LAGUNA BLVD Henrys Market" becomes "4C4147554E4120424C56442048656E727973204D61726B657400"

Yeah, if you read through this thread you will see I have most of those entries figured out.

As you found, the long hex strings are ascii coded text. Any of the entries with 00 are strings like that. For example the first (column 4) 00 is the phone number in ascii.

The real tricky part of the format is the system doesn't use the Lat/Long coordinates like you would hope. Instead that set of 3 numbers in the set (columns 9, 10, 11) are an encoded location format that is very convoluted. I can convert from lat/lon to close to it using a lot of math hoops and known positions. But I am sure it is not exact. I have an ongoing dialog with Nissan trying to find someone who knows this format. Without that cracked, we can only get close to the exact position.

However, if you send my your entries, I can add them to the known good database I am building of those 3 number sets.

 

[LEAFer]

Yeah, if you read through this thread you will see I have most of those entries figured out.

My apologies to EVNation ... I was directed to the bottom of page 4 in this thread from another one and did not take any time to review all the good work you had already accomplished ! I went straight to decoding your sample file ... Sorry

I did feel pretty good, though, having figured out all by myself :shock: the ASCII name stuff based on that one location I knew I had edited. And so (if you did not already know) maybe my contribution so far is that column 5 is the edited name the user entered on the Nav.

(PM sent to EVNation)

 

[EVNation]

Yeah, if you read through this thread you will see I have most of those entries figured out.

My apologies to EVNation ... I was directed to the bottom of page 4 in this thread from another one and did not take any time to review all the good work you had already accomplished ! I went straight to decoding your sample file ... Sorry

I did feel pretty good, though, having figured out all by myself :shock: the ASCII name stuff based on that one location I knew I had edited. And so (if you did not already know) maybe my contribution so far is that column 5 is the edited name the user entered on the Nav.

(PM sent to EVNation)

No worries at all. Just wanted to save you time also. Decoding that stuff is a pain of trial and error. Good job on the ascii coding. Really odd that they did that and not at all intuitive to encode ascii as hex "text strings".

I didn't know column 5.

Other columns I have figured:

3: group (friends =3, etc.)
4: Ascii coded phone number
7: Location name in hex coded ascii
9: Lat/Lon grid code
10: X offset from grid
11: Y offset from grid
21: Icon code (44 = charger, 24 = fast charger, 0 = slot marker, all other icons available)
24: Dist + 2000 meters (3000 is default = 1000 meters)
25: Direction of location (not sure the units but assume 0 - 2047 = 360 degrees or such)
26: 4294967295 (I assumed this was a car ID or such but it is the same on your car so may be a constant)

The other strings may be useful but for me, the name and lat/lon and marking a charger is enough.

I have a contact at Nissan now that I hope clears up the lat/lon encoding issue.

-Jeff

 

[garygid]

The grid codes/numbers might be the same ones (google Maidenhead grid squares) used in the Locator System used by Amateur (Ham) Radio folks?

I am in DM13do, about 6000 meters "square" (not really square).

What are your estimates of the size of the grid squares, and at what (Lat, Lon)?

 

[EVNation]

The grid codes/numbers might be the same ones (google Maidenhead grid squares) used in the Locator System used by Amateur (Ham) Radio folks?

I am in DM13do, about 6000 meters "square" (not really square).

What are your estimates of the size of the grid squares, and at what (Lat, Lon)?

That may be and would make sense. But it is a screwy format. The grid is encoded as two, two byte pairs of numbers. The least significant nibble is 0-4 on each pair and the rest seems to be straight hex. So and example would be 0x9953, 0x92C0 for the grid code. That is combined then turned into a integer (0x995392C0 =-1722576192). So yeah, screwy.

Best I can tell, each grid square is about 0.02083333 degrees latitude and 0.03127 degrees longitude. Though I suspect it is actually not in linear coordinates and it depends on where on the globe you are. So it is some other kind of projection. But those numbers are close for the main united states. A known good corner of the grid is (33.8125, -118.5) I also have other reg points. The offsets values from the grid I have seen range from 0-1950 or so. But I am not sure if the range is a full 2048 or something else. So getting more test points would help there.

So now you see why it is not nearly as easy as it should be to crack this. I am glad I got this far but if I can't find the exact projection/conversion or get a Nissan contact that knows, I may just need to rely on estimates.

[Edit] Looking at the known good points again, they are close to even Degree,Minutes,Seconds boundaries (within 0.001 secs). So that is how the grid is likely divided. But when I convert my known good positions, I see some flux. The grids are mostly 1' 15" (but one is 1' 14") x 1' 52" (with on 1' 53") Yuck. I hate sloppy data.

 

[LEAFer]

I provided EVNation with the Deg/Min/Sec from another car's GPS for the same location the LEAF had a stored point (using its wacky format). If anyone else could do the same ... that would help. Mine was in Elk Grove, CA. Additional points "far away" would be great ...

 

[garygid]

The LEAF stores both the GPS Lat, Lon AND the location's Wacky-Values (probably Grid based).

So, the car must calculate the Wacky-Value (from the Lat, Lon values?) when the new User-POI is "created".

However, if one Restores a location without the Wacky-Values, it apparently does not calculate new values from the given Lat, Lon values, and it apparently needs the Wacky-Values to function or display properly.

 

[EVNation]

The LEAF stores both the GPS Lat, Lon AND the location's Wacky-Values (probably Grid based).

So, the car must calculate the Wacky-Value (from the Lat, Lon values?) when the new User-POI is "created".

However, if one Restores a location without the Wacky-Values, it apparently does not calculate new values from the given Lat, Lon values, and it apparently needs the Wacky-Values to function or display properly.

Yep. I have tried loading in data with 0,0,0 in the values and just ,,, and it fails to load address book.

I suspect there may be a magic way to tell it to use the Lat/Lon via a flag or such but have not found any. That is what I hope to get from Nissan. It would be silly for the interface programmers not to support that but things are not always thought all the way through.