It appears that the Nanocom EVO is incorrectly coding the idle trim for Type-1 "Blacktop" and Type-3 "numeric" injectors.
I've done some research and found a post on lr4x4 forum from July 2009 that mentions a bug with Type-1 idle coding which had been fixed in the Nanocom One v2.04 firmware. The documentation was not updated so there was a difference in how codes were displayed.
Prior to the fix in v2.04 the injector idle codes were:
A = 1 B = 2, C = 0, 3
After the bug was fixed the codes translated as:
A = 0, 3 B = 1 C = 2
The current Nanocom documentation describes the correct A = 0,3 encoding for Type-1 injectors.
However the Nanocom EVO is still using the buggy encoding when writing to and reading from the ECU . To verify check the type-3 numeric encoding by pushing the Inj. Type button until the idle code shows as a number. If the numbers match the correct idle codes for the injector (A = 0 or 3, B= 1, C= 2) then the programmed codes are correct.
The main SOI and EOI trim codes appear to be correct.
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 look reasonable.
The Type-3 programming looks suspiciously like it is broken.
Writing idle codes using Type-3 mode generates the same five hex codes in slots 1-5 regardless of the value in the range 1-8 entered for each injector. Given that at least one of the values is not a valid code I think its safe to say writing this type of injector is not currently supported by the Nanocom.
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.