Thread: New ECU install

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.