Nanocom Bugs

Update:

A friend has kindly done a read of codes with a Hawkeye Total and Nanocom. The Hawkeye interprets the codes as per the BBS documentation, so it looks very much like Nanocom is in fact getting the Type-1 codes wrong. It is the only tool encoding with a CABC sequence - everything else uses ABCA.

I also realised that Faultmate MVS uses only numeric coding - the user is required to manually convert to the correct code using the BBS docs. This means in effect they use ABCA coding. So Faultmate and Rovacom can't suffer from this bug.

Sadly it does mean that every type-1 injector idle code programmed with a Nanocom since v2.05 was released in 2009 is wrong. Mine included.

The remaining is a bit disjointed - I'll try to get this sorted in the next day or two.

---

The current documentation for the Lucas Td5 module appears to contain the same information on coding as the Rovacom documentation quoted here.

Finally this post from 2017 illustrates precisely the effect you would expect if this bug actually existed:

Injectors  (Actual codes)
No1 NHBEA 
No2 NFBDA 
No3 NDNNA 
No4 NLNGA 
No5 NDBCA 



NANOCOM - TD5ENG.APP - TD5 ENGINE settings file 
param;value 
Injector 1;NHBEC 
Injector 2;NFBDC 
Injector 3;NDNNC 
Injector 4;NLNGC 
Injector 5;NDBCC 
Accelerator;3 WAY 

This all fits quite neatly with my "theoretical" bug.

The documentation says A = 0, B = 1, C = 2 while Nanocom reads and programs C = 0, A = 1, B = 2.

It's difficult to be certain the codes have never been reprogrammed. However if these are factory programmed codes and original injectors this would tend to support my "Nanocom wrong" theory.

I have a Launch X431 Diagnostic tool with LR coverage which is currently my only point of comparison. That reads and programs using the A=0 coding described in the BBS documentation.

I've also come across a French thread from 2017 which seems to suggest the CABC coding used by Nanocom is wrong:

Google translates the comment as "ABCA (or CABC, if the tool crashes on the conversion)"

It will be interesting to see what BBS say.

End Update.

It appears that the Nanocom EVO is incorrectly coding the idle trim for Type-1 "Blacktop" and Type-3 "numeric" injectors.

Revised and corrected.

Nanocom One firmare prior to v2.05 had a "bug" which resulted in incorrect coding of Type-1 idle codes.

This coding seems to have been:

A = 0, 3
B = 1
C = 2

After the bug was :fixed the codes translated as:

A = 1
B = 2
C = 0, 3

The current Nanocom documentation describes the A = 0,3 encoding for Type-1 injectors. As noted above this coding has been used in the documentation of Rovacom, Faultmate and Nanocom since at least 2008. The problem as noted is that Nanocom does not program A = 0,3 it programs and reads C = 0, 3.

The Nanocom firmware was apparently developed in part by reverse engineering a Rovacom.

So I wonder if the "bug fix" was a case of the Nanocom developer writing to match the documentation, then discovering the Rovacom used a different implementation. Curiouser and curiouser!

At this point I think about the best we can do to get closer to the truth is Tool X vs BBS comparisons. Omitec developed the original TestBook equipment for LR, They also produce the Hawkeye and Lynx tools for Bearmach and Britpart respectively. Comparing Type-1 idle codes read by Hawkeye, Lynx and Nanocom should give a fair idea if they align.

Type-2 codes

Type-2 programming seems to be 90% correct. The only questionable aspect is the interpretation of the M code. The Nanocom documentation indicates M is normally programmed as 8 but can be forced to 0.
If the values from E to M were programmed as numerical values from 1 to 8 everything would make sense. The EU3 idle trim has an X-axis with 10 values. The first (index 0) and last (index 9) are correspond with no adjustment. The design of the table suggests the valid values should fall in the range 1-8 and this is what the Nanocom docs describe. However the correlation of M as both 0 and 8 makes no sense at all.
For that to be true M would have to simultaneously be 0 uSec AND -47 uSec. Alt-facts anyone?

Unfortunately without access to the Delphi docs relating codes to timing that is going to remain a mystery, Fortunately the remaining codes for EU3 / Type-2 look reasonable.

Type-3 programming?

The Type-3 programming looks suspiciously like it is broken. Scratch that. It's completely broken.

Attempting to program Type-3 codes results in the Nanocom writing "illegal" values.

I tested Type-3 coding using idle codes 0, 1, 2, 3, 8.

Instead the Nanocom writes 0x1E, 0x1C, 0x1C, 0x1C, 0x1C as seen from the capture below...

The ECU masks these values with 0xF, meaning only the lower nibble is retained. 0x1E becomes 0x0E and 0x1C becomes 0x0C.

This masking can be seen in the values ECU sends back when the idle codes are read:

Even the Nanocom can't make any sense of what it wrote...

Programming codes.

At this point I'm tempted to suggest the only 100% safe way to program injector codes using a Nanocom is to find a friend with a Hawkeye.

The least risky path for Nanocom owners is to use the current documentation values to translate type-1 and type-3 codes to type-2 values and then program using type-2 mode.

We tend to assume that when you plug in a specialist fault code reader the codes that are reported are correct.

Unfortunately that faith seems to be misplaced.

Initially I thought this was a problem that only afflicted the Nanocom but a recent posting on a UK forum suggests that the Hawkeye suffers from the same problem.

The codes that had been posted will be familiar if anyone who as tried running an EU3 map on an EU2 vehicle.

Nanocom
- (4,3) Coolant temperature circuit. (Logged High).
- (6,3) Coolant temperature circuit. (Current).
- (24,7) Problems detected with auto gearbox. (Current).

Hawkeye
- Fault 3018 Coolant temperature High Fault logged
- Fault 3034 Coolant temperature Fault Active
- Fault 3174 Fault detected with automatic gearbox

The three "phantom" faults reported are caused by the lack of Ambient Air Temp sensor which is part of the 4 wire AAP/AAT sensor used on the EU3 engines. And the codes can be eliminated by adding an extra wire and the EU3 airbox lid and sensor.

But that doesn't explain why the fault codes do not reflect the actual fault.

We investigate anomalies...

It's not widely known that the EU2 NNN maps include code to process the output of the Ambient Air Temp sensor, although the data is not used by the engine maps. I currently have an EU3 4 wire AAP/AAT sensor fitted but have gone back to running EU2 maps. With this setup I discovered the AAT readings are returned as part of the live data. Unfortunately the AAT sensor is completely ignored by the Nanocom, despite multiple requests that this be added.

Given that both EU2 and EU3 NNN maps are AAT aware, it would be fairly surprising if the ECU code was setting incorrect fault bits.

Looking at the ECU code for EU2 and EU3 NNN maps shows that the bits which correspond to faults 4-3, 6-3 and 24-7 are set by code that handles the AAT sensor. So these faults should actually be shown as AAT faults - logged high, active fault, and voltage out of range.

Let's go back, way back...

So at this point I started looking back at the MSB code....

Fault 4-3 corresponds with ECT sensor over voltage, check.
Fault 6-3 corresponds with ECT sensor active fault, check.
Fault 24,7 corresponds with Auto fault, check.

In other words the fault codes are correct on MSB ECU's, but wildly incorrect on NNN ECU's.

Oops...

Unfortunately this issue doesn't effect just the AAT sensor.

There was some internal reordering of ADC inputs done in the upgrade from MSB to NNN which means that 1 in 4 of the fault codes in the 1,x - 6,x range are incorrect. An additional fault in that range cannot be correctly identified without a code that is "invalid" for the MSB and therefore not reported by diagnostic tools.

Beyond the basic input checking codes (1,x - 6,x) there are additional errors and major omissions.

Checking out some of the faulty codes on forums I've seen at least one instance where someone was told to replace the throttle position sensor when the fault code actually related to the MAP sensor... It wasn't surprising to see that after forking out a few hundred for a new pedal the person reported back that the new pedal had not solved his problems.

Other problems with incorrect codes are deemed as "quirks" when it becomes obvious the "faulty" part is fine and advice descends rapidly into random part swapping recommendations.

You just have to wonder how much money has been wasted based on the these incorrect codes...

So if you own a vehicle with an MSB ECU count yourself lucky - any fault codes will be correct.
NNN owners will just have to console themselves with the fact that the codes will be correct about 75% of the time...