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.