RomRaider

ecubyteindex="CF48D" is not valid. This causes the Logger to scan the supported PID index (received from DEBUG [Thread-6] - ECU Init Response <--- ) to look for a True value at this byte/bit location.

You will need to use the format:


PS: RR will be switching to the 6 character CAL ID / ECU ID in the next release. The "1" dropped from the beginning of all will be required in future definitions, i.e.: 1CF48D

Ahhh. No work around there then haha I really appreciate you taking the time to answer all my questions! Thank you once again for all the help!

Thanks for the heads up on the ECU ID portion! I definitely want to get a head start on changing the format for my current defs haha Is the only thing that needs to be changed the ecuid and internalidstring portion of the definition file? Or do you also need us to change the xmlid and .xml file name as well?

I would suggest replacing all instances of the CAL ID/ECU ID with the new version in XML files. File names do not matter though.

Hi dschultz, can you elaborate on this ?
SID 1A does add that leading '1' for some unfathomable reason, but Nissan seems to use the 5-char version pretty much everywhere : part numbers, repro file / TSB lookups (i.e. from https://www.nissan-techinfo.com/ ), even those factory-supplied .dat repro files internally refer to the 5-char version only...

OBD Mode 09 04 reports the full 6 characters of CAL ID. Because this Logging mode is not manufacturer specific I have to use the full 6 characters to be compatible across all. This forces the use of all 6 characters, as some definitions are common once the ECU ID is known. You can leave the XML ID as a 5 character code if you wish.

Fair enough. Thanks for the explanation !

In any case, I'm not maintaining RR nor the definitions anymore, so it actually doesn't matter to me, hehe.
I imagine "our" (Nissan) def naming will keep the 5-char convention but change the xml tag needed for logger integration.