Updates
* Added link to Python 3 version of scripts on GitHub.
* I decided to revisit the Nanocom One log converter code today with view to incorporating it into a larger project. 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. The post is getting a rewrite to correct.
While the Nanocom One is viewed as a dinosaur there is a body of opinion that it is far more reliable for .map uploads than it's replacement - the Evo. And there are a lot of them in circulation, and that means logs in the binary .fu1 format.
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. Either way it's not especially flexible and a bit of a PITA.
Anyway last night I sat down with a copy of Synalyze It! (Hexinator on Windows/Linux) and worked out the structure of the .fu1 log files.
Synalyze It! uses "grammar" files to apply structures a binary file which is a fairly nice way of reverse engineering file formats.
This shows how a single fuelling record looks with the fu1 grammar applied:
Fuel Record [0] (0)
{
RecordDelimiter: CR LF: 0D 0A [0]
FuelData [0] (2)
{
DiagRequest_0x09 [0] (2)
{
RPM: 754 [0]
}
DiagRequest_0x0D [0] (4)
{
RoadSpeed: 1 [0]
}
DiagRequest_0x1A [0] (5)
{
ECT: 3523 [0]
ECT mV: 772 [0]
IAT: 3311 [0]
IAT mV: 1309 [0]
AAT: 3200 [0]
AAT mV: 1681 [0]
FT: 3325 [0]
FT mV: 1260 [0]
}
DiagRequest_0x1B [0] (21)
{
TPS1 mV: 571 [0]
TPS2 mV: 4460 [0]
TPS3 mV: 4677 [0]
Throttle %: 0 [0]
TPS Supply mV: 5021 [0]
}
DiagRequest_0x1C [0] (31)
{
MAP: 10143 [0]
MAP raw: 10158 [0]
MAF: 575 [0]
MAF mV: 1977 [0]
}
DiagRequest_0x21 [0] (39)
{
idleErrorRpm: -3 [0]
}
DiagRequest_0x40 [0] (41)
{
Cyl 1: 3 [0]
Cyl 2: -2 [0]
Cyl 3: -1 [0]
Cyl 4: -2 [0]
Cyl 5: 2 [0]
}
DiagRequest_0x23 [0] (51)
{
AAP: 9971 [0]
AAP raw: 10013 [0]
}
DiagRequest_0x37 [0] (55)
{
EGR Inlet: 0 [0]
}
0x38 [0] (57)
{
WGM Duty: 0 [0]
}
0x38 [0] (59)
{
WGM Duty: 0 [0]
}
0x10 [0] (61)
{
BAT mV: 13807 [0]
BAT_MSB_only: 35 [0]
}
}
}
The format is actually pretty simple. It consists of a CRLF ('0x0D0A') pair delimiting each "observation" and then the block of data which makes up the observation. The final byte of the file looks to be a mod256 checksum.
The hex number appended to each DiagRequest_0x refers to a predefined diagnostic request used by the ECU to look up engine parameters. 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 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. This means the corrected voltage is OK, but only the most significant byte for the uncorrected voltage is available making it useless. I've corrected the script so it ignores the corrupt value.
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. This update fixed the duplication in fueling mode, but it remained in Instrument mode when I last looked.
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. As can be see from the decoded structure the file also includes sensor voltages for all temperature sensors, and the MAF.
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 reading corrected for variation in sensor supply voltage. The corrected value is used by the ECU for fuelling and boost limiting purposes, however the Nanocom (One) reports the raw value.
Converter
I've put together a small python script which is attached.
It's is a bit less basic than previous version, and has only been tested on macOS 10.13 with Python 2 and 3. You'll need to remove the txt extension.
The script is run from command line, with the path to the file to be converted as an argument.
python fuconvert.py file.fu1
The converted file is saved as filename.csv in the current working directory. The .csv contains the full data from the log saved in the same order the requests appear in the .fu1 file. This is different to the Nanocom CSV order. The converter alters temperatures from Kelvin to Celsius, and adjusts decimal points to match the the Nanocom, with the exception of voltages which are left as millivolts.
Note that the AAT and TPS3 voltages will read 5000mV if the input is not connected.