![]() What is interesting is that the full data for each request is saved in the file, so that the Throttle % and AAT reading is present in the data.Īs can be see from the decoded structure the file also includes sensor voltages for all temperature sensors, and the MAF. This update fixed the duplication in fueling mode, but it remained in Instrument mode when I last looked. Note also that until the most recent update (v1.32) the Nanocom was making duplicate requests for the WGM Duty Ratio, and using one read for the EGR Output. I've corrected the script so it ignores the corrupt value. This means the corrected voltage is OK, but only the most significant byte for the uncorrected voltage is available making it useless. ![]() The problem I discovered when revising the script is that the Nanocom One logs only 3 of the 4 bytes of data for the Battery Voltage. These are common to MSB, and EU2 and EU3 NNN, so if you request 0x10 you'll always get back 4 bytes of data containing corrected and uncorrected Battery Voltage. The hex number appended to each DiagRequest_0x refers to a predefined diagnostic request used by the ECU to look up engine parameters. The final byte of the file looks to be a mod256 checksum. It consists of a CRLF ('0x0D0A') pair delimiting each "observation" and then the block of data which makes up the observation. This shows how a single fuelling record looks with the fu1 grammar applied: Fuel Record (0) Synalyze It! uses "grammar" files to apply structures a binary file which is a fairly nice way of reverse engineering file formats. Either way it's not especially flexible and a bit of a PITA.Īnyway last night I sat down with a copy of Synalyze It! (Hexinator on Windows/Linux) and worked out the structure of the. The usual procedure is to open up the old graphic viewer PC application and use that to check files or to export as a.csv file and then use a spreadsheet app to look at the data. And there are still a lot of them in circulation, and that means there a quite a few logs in the binary. map uploads than it's replacement - the Evo. While the Nanocom One is viewed as a bit of a dinosaur there is still a body of opinion that it is far more reliable for. The post is getting a rewrite to correct. When I made a couple of changes to tidy things up, I discovered that I'd managed to wallpaper over a small problem in the Nanocom One log format, and also missed the bleeding obvious in regard to the record delimiter. Updated: I decided to revisit the Nanocom One log converter code today with view to incorporating it into a larger project. Added link to Python 3 version of scripts on GitHub Obviously there needs to be some kind of feedback that the codes have been programmed. I think explicitly flagging this is more informative than leaving the code blank as the Hawkeye does. U=0 is a made-up "uncoded" code reflecting the fact that 0 is the default state for new ECU's and a substitute value for corrupted idle codes. codes read from ECU after update and used to refresh display.codes converted to numeric using A =0 for 10P, M=8 and U=0 for 15P. ![]() codes validated and highlighted in red if incorrect on enter/return.injector codes being read from an NNN ECU running an 15P/EU3 map.The main things happening in the video are: My code had been put on the back burner when I realised I needed access to Rovacom, Nanocom and a tool made by Omitec (Britpart Lynx or Hawkeye) to get enough points of reference to be confident of correct handling.įortunately Nicky Rovertech has access to all three and was kind enough to send me pics of how all three devices handled two specific test cases. This is basically a test GUI for Injector programming code I've been working on over the last month.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |