This is different to the Nanocom CSV order.
SYNALYZE IT FIND STRUCTURE FULL
csv contains the full data from the log saved in the same order the requests appear in the. The converted file is saved as filename.csv in the current working directory. The script is run from command line, with the path to the file to be converted as an argument. It's is a bit less basic than previous version, and has only been tested on macOS 10.13 with Python 2 and 3. I've put together a small python script which is attached. The corrected value is used by the ECU for fuelling and boost limiting purposes, however the Nanocom (One) reports the raw value. Reading corrected for variation in sensor supply voltage. I found that there is also a small error in the Nanocom One's AAP value - there are two values returned - one is the raw reading, and the other is the 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.
SYNALYZE IT FIND STRUCTURE UPDATE
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 a lot of them in circulation, and that means logs in the binary.
map uploads than it's replacement - the Evo.
While the Nanocom One is viewed as a dinosaur there is 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.
SYNALYZE IT FIND STRUCTURE CODE
* 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.
0 kommentar(er)
