View Full Version : 3.4.2 log format?

6th-July-2013, 02:34 AM
Hi! I saw a post for the log file format in a previous version, but it seems v3.4.2 has more fields. Could you please let us know what the fields correspond to? It looks like my log files are grouped in 7 14-field lines (since every 7th line seems to be all zeros during a run at least in my setup).

I am wanting to script some logfile analysis tools to assist in my tuning. It may also be helpful to know the format of the .tbl files, It is obvious which lines are the cell data, but knowing what the data fields in the other lines are since some of them are not quite as obvious.


My setup: 2007 2TR-FE Tacoma, URD Stage II Rotrex kit, MAP-ECU3 + AFR Recalibrtator. Operating mode: MAF intercept, MAP Y-axis, -24 to +15.

10th-July-2013, 09:34 AM
I realized the multiple columns were the separate logs. I was confused because I hadn't really looked at more than one log at a time in your software.

I was able to decipher which fields were what in the log once I figured out there was one line for each log per log interval.

Is there a way to log the frequency of my speed input and/or output? I am using mode MAF intercept, MAP Y-axis, and using the KVF input as my SPD in, and Switched #3 as SPD-LOW out. I know the frequency I need to cap is somewhere between 100Hz and 135Hz, but would like to narrow it down closer without splitting the difference, reconfiguring, making a 4th gear pull, then continue interpolating and reconfiguring over and over again...would be nice to set it above the point the factory has set, make 1 run, then look at the log and know exactly what frequency trips the factory ECU to go into the speed cut.

Also, I had to create my own .o2 table for my NTK Lab-grade WB that came with my AFM1000. You may wish to add one for it in your next release. It's simple enough, the AFM1000 (and AFM1500) have linear analog-output (via BNC cable, center condutor signal, shield is ground) sending exactly 0v for 8:1 AFR through exactly 5v for 18:1.

Another interesting note is that when the AFM1000 and AFM1500 are powered on, the (analog) output passes through a series of three voltages. Each voltage is held for 5 seconds. For the AFM1000, these 3 voltages are 0.0v, 3.28v, and 5.0v, and correspond to 8.0, 14.56, and 18.0 AFR respectively. For the AFM1500, the 3 voltages are 0.5v, 3.28v, and 4.5v, which correspond to 9.0, 14.56, and 17.0AFR respectively. This is a pretty neat feature to verify correct electrical connection and signal conversion with the AFM and the receiving device :).

Back to the .log file format, what are the fields in the lines prior to the actual data logging?


11th-July-2013, 12:59 AM
Wow! You have been busy! Thanks for the info on the NTK WB, do you want to upload the file to the forum?

I don't think you will get the speed input at the same time as running MAF Intercept but I will have do some research.

The numbers at the beginning of the log are the ECU Configuration parameters for the ECU that you used for logging. They give you the parameters to understand the log data, especially boost/vacuum pressure. I thought they were explained in the log document. Is there something missing?

11th-July-2013, 05:16 AM
Doh! I missed the "log document". I assume it is on the CD and I'll certainly check it later today. The CD that URD is still shipping at least as of late last month when I received mine is v3.3 with the older firmware. Soon after installing and verifying all was working I updated to 3.4.2 and the accompanying firmware. I downloaded the 3.4.x pdf, but did not even think to look for other documentation on the CD since I was no longer using the software or firmware versions from it.

Thanks for diplomatically pointing out I already had the information...I just needed to read it haha.

As for the .o2 file, all I have done was to create it and verify that my MAP-ECU software picked it up. I have not yet installed my AFM1000 due to weather and time constraints, so as of right now, the file is not verified to work. Hopefully I will get the ECM unit installed today.

I'll post later today from my laptop and attach it...if I have not had the chance to verify it, then I'll include "untested" in the filename. If I do manage to complete the ECM unit install (along with a supplemental bypass oil filtration system and some cosmetic changes also partially completed), then I'll omit "untested" from the filename.

11th-July-2013, 11:21 AM
We don't include the log file document on the CDROM because most people are not interested, it has been posted on the forum by request. I just did a search for "log file format". We have to update it for the MAP-ECU3 but this will give you a good start: http://www.performancemotorresearch.co.nz/forum/showthread.php?t=783

11th-July-2013, 12:40 PM
OK, thanks. I didn't get to verify the AFM1000/AFM1500 .o2 file yet but here it is.

13th-July-2013, 07:24 PM
Thanks for the O2 lookup table.

Please find attached an updated log file document. Let me know if you have any questions.

BTW, the reason you cannot get the Speed input Hz at the same time as MAF mode is that the same MAF-In field is used depending on the mode. Out of luck in MAF mode. I will talk to the developers as we need to move to log file format 8 anyway for the new version of MAP-CAL3.

14th-July-2013, 02:39 AM
Excellent info!

I work weekends and surrounding days, so I won't get to do much until later in the week...but this should certainly come in quite handy!

I am confused a little as to why the speed in Hz input can't be displayed/logged. When capped 100Hz I've had it successfully bypass the OEM speed limiter, therefore the input is being read, and the associated output is being conditioned properly...so the MAP-ECU3 is reading and acting on the input. It seems to me the software should therefore be capable of logging it. Worst case scenario I could see that perhaps this would require a firmware update depending on exactly how the hard code is written and configured...or is this due to a hardware limitation (insufficient registers, speed (data acquisition or data processing), cache, I/O bandwidth, instaled/addressable ram, etc)?

If the underlying hardware can support it, I believe it would be nice to have at least some kind of data to work with...even if is just a single field containing the number of times the input (or output if that would be easier) was switched between low & high during the log interval (default 0.1 second interval per log line).

I will most certainly make use of the logfile data as it is though...and understanding the configuration lines should make it possible for me to create some useful analysis scripts. Also, I am considering seeing if the Open Source "VirtualDyno" project developers would wish to add MAP-ECU3 logs to their growing list of supported ECU log formats (else I could write a short script to convert MAP-ECU3 logs to a format VD can read).

Thanks again!

16th-July-2013, 12:15 AM
Its not that we can't log the SPD input, it's just that currently the data stream from the MAP-ECU3 only has one field for the air flow meter input which is either the KVF input frequency OR the MAF input voltage. In order to log the SPD input, we have to add another field to the data stream from the MAP-ECU3. We are looking to change the data stream format anyway for other reasons so adding the SPD input frequency is a good idea. :)

16th-July-2013, 03:03 AM
That's a perfect explanation and excellent news that it may get added :)

Just an update on the AFM1000 .o2 file, I thought perhaps I could get away with replacing the factory AFR (in '02 and up Toyota started using their implementation of wideband AFR sensors in front of the cats, current-based instead of voltage hence the need for an AFR sensor adjust module) as another poster had, albeit w/ a different motor and using a different MAPECU mode, but that was not the case. I ran short on time before my workweek started so I have not yet installed the additional bung.

It did seem to read correctly using the table while I ran the truck both with the factory AFR disconnected (which threw an AFR sensor heater CEL), and with the factory AFR plugged in to the harness (to avoid the heater CEL) but not installed into the exhaust stream (which caused extreme rich readings and multiple CEL's multiple lean codes and "sensor 1 stuck" due to the factory AFR reading open air).

It may be a little longer before I have the AFM1000 connected again, as the lab grade sesnor supplied can handle much higher temps than your run of the mill LSU's and other UEGO's popular with the street scene. I am considering getting a good EGT probe & gauge to see if the temperatures in the header right where the 4 exhaust runners come in to 1 are within the operating range of my NTK as I suspect they are. I believe this would also decrease the chances of condensation causing sensor-shock during initial startup (or more accurately, reduce the time needed to wait during a cold start before powering up the AFM which in turn kicks on the heater circuit...from the product manual recommended 1 minute to perhaps 15-30 seconds, which would also have the benefit of reduced time the sensor is cold in a running motor - i.e. finding a sweeter spot between the lines of risking condensation-induced sensor shock and life-shortening operation below operating temperature of the sensor).

I look forward to the next release! Any chance of updating the graphics to look more like the iPhone screenshots in the marketing pages? It'd be sweet to have more configurable gauge display options and skins...although then I'd probably wind up buying a dedicated PC to install in the truck w/ a monitor fab'd into the dash...I have enough projects as it is lol.

20th-September-2013, 10:33 AM
I've been quite busy lately chasing down a "lean under boost" issue among other things...Just to get sane AFR's under normal driving, I had to run a table that by all rights should have been dumping so much fuel I should have needed a catch can at the exhaust tips.

I removed every vac line, redid every exhaust joint, ran myself into the ground chasing leaks that didn't exist!

After installing a fuel pressure gauge, my issue was blatantly obvious...15 PSI! Service manual says 45 PSI at idle.

Anyway, with a much improved fuel system all the way around now (fuel pump turned out to be the culprit), I can confirm the AFM1000.o2 table I attached earlier in this thread if correct.

During troubleshooting, I wound up breaking off the internal MAP nipple, so I now run an external GM 2 Bar...and as s side benefit, I can use the internal MAP now for barometric pressure correction since no hose is needed for that ;).

Anyway...just wanted to post confirming the accuracy and usability of the .o2 table I uploaded.

Have a great day!

23rd-September-2013, 08:20 PM
Hey! Thanks so much for the post. You don't know how refreshing it is to receive feedback completing the story and hearing about the end result. Have a great day too!