Posts relating Electronic diagnostics on the Discovery 2

Hawkeye and Nanocom: The Case of the Wrong Fault Codes

Friday, November 23, 2018 - 12:30

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.

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

- 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.


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...

Key fob not unlocking the D2 - RF Interference?

In the last week the Disco has decided it won't unlock in the morning using the remote. I can unlock with the key and then lock and unlock on the remote without any dramas.

The issue looks to be identical to that described in Tech Bulletin L8605bu REMOTE HANDSET FAILS TO UNLOCK VEHICLE - ALARM RECEIVER.

After the vehicle has stood for an extended period (e.g. overnight), the remote handset will not unlock the vehicle. Unlocking using the key restores normal operation.

The problem seems to be a bit intermittent, and there have been several occasions where the remote will work fine. It's almost tempting to buy a RF sniffer to check if there is a local source of interference on the fob frequency, but the cost for a cheap scanner is twice the cost of the replacement receiver.

The Silicon Chip scanner sounds cheap but would cost around $50-60 once you buy the board and parts. The RF Explorer looks like a better option for not that much more outlay.