I have look at this previously, what do you mean by ROW?Quote:
Originally Posted by mturri
Printable View
I have look at this previously, what do you mean by ROW?Quote:
Originally Posted by mturri
ROW = Rest Of the World
Believe your choices are:
1- Defender 90 A/C Europe
2- Defender 90 non-A/C Europe
The 90 vs 110 aspect I wouldn't worry about, some people even say the 110 runs better on a 90 tune. Personally couldn't tell the difference.
Re what the actual difference in fuelling is between a Europe and a ROW map I'm yet to find out.
Rgds
Matt
From the Nanocom Map Wizard there are the following Maps available for 110 and ECU NNN000120, I cant find any mention of AC vs Non AC.
- svloe002-svtnp003 - DEF110 Manual Europe NNN000120 25-06-2001
- svloe002-svtnp003 - DEF110 Manual Europe NNN000120 07-02-2002
- svloe005-svtnp005 - DEF110 Manual Europe NNN000120 17-06-2002
- svloj002-svtnp003 - DEF110 Manual Japan NNN000120 22-12-2002
- svlor002-svtnp003 - DEF110 Manual ROW NNN000120 25-06-2001
- svlor004-svtnp003 - DEF110 Manual ROW NNN000120 07-02-2002
- svlor005-svtnp005 - DEF110 Manual ROW NNN000120 17-06-2002
I have gone for svlor005-svtnp005 is this the correct one?
Your MY99 Defender has a EU2 engine therefore needs an engine management system running a EU2 map.
NNN type ECUs were originally designed for EU3 engines but a few specific maps were created in order for them to be used in EU2 engines.
See the attachment for a list of EU2 maps that suit each NNN type ECU.
HTH
Thanks for that the aforementioned maps is in the Nanocom Map Wizard as
STHLE022-STTLP009 UNKNOWN Manual Europe NNN000120 20-09-2001
Thanks everyone for all your help especially mturri and djam1
when trying to load the map to the ecu with the nanocom it says "checksum error" then other times it says "Map Program Error"
I think the map wizard generates may be corrupted.
Anyone else have this issue? or can shed some light on how to fix it?
Based on the method detailed in this translated post, the checksum of the file is correct.
In a hex editor you delete the last two bytes of the map file, 2D A0 in this case. You then create a 16 bit checksum for the remaining file contents. The regenerated check sum is 2D A0, which indicates the checksum in the map "generated" by the nanocom tool matches the contents for the map file.
The file length also matches the figure given in the post: 118798 bytes.
The only thing I can see which differs from the post is that position 00019010 is not hex 3F but instead hex 29.
After examining a number of map files it seems these characters are an indicator of motor type:
29 80 is used for Def 90 EU2
2A 18 is used for Disco EU2
3F D8 is used for EU3 maps for Discos and Defenders
(this is based on a sampling of 14 map files for NNN000120, NNN000130 and NNN500020 ECU's)
This would suggest the hex bytes at 00019010 are correct for the fuel map in question, and it would appear that the files being generated by the nanocom map utility at very least have correct checksum, file size, and most likely correct engine designator.
If they are being corrupted it seems likely this is occurring after the file is generated.
cheers
Paul
Ok thanks for that I will validate the checksum of the files being generated.
The other issue I have now is that the Nanocom is now refusing to talk to the ECU. I have put the old one in because I need to drive it tomorrow. I hope the weekend works a little better for me.
Next question will the Nanocom with all SD cards or is it restricted by size and type?
My guess is if you find the root cause of your communication issues your checksum issue will disappear.
It only takes one mistransmitted bit to throw the checksum out.
I ended up choosing the Discovery menu on the Nanocom, then to TD5 instead of Defender and that seemed to work better i.e. completed the write and read of the map.
Thanks again to all for assisting getting this all fixed.
Now I just have to figure out which remap to go for.