OpenPort 2.0 + Chrome logging without laptop

[mjannusch]

Anyone who is using Chrome 2.0 should already have an OpenPort 2.0 to perform flashing, so here's the easy way to datalog using the OpenPort without needing to have your laptop connected to the OpenPort and running EvoScan.

Needed:

Flashable 3/S ECU ('98, '99, "Clone", etc)
Chrome v2 flashed onto ECU
A 3000GT or Stealth
2GB or smaller MicroSD card, formatted as FAT16

How it works:
The OpenPort adapter functions as a MicroSD card reader whenever it is connected to your laptop with a USB cable. You should see the MicroSD "disk" mount as a drive letter. If it doesn't mount, and you get a warning message that the disk is not readable, you probably have to format it. Format as "FAT (default)" for best results. I've had success with FAT32 on mine as well, but the OpenPort guys say that there's a lot of additional overhead writing to FAT32, so to keep it streamlined use FAT (default).

Once you have your MicroSD card set up to work in the OpenPort adapter, you need to put a logcfg.txt file on the card that contains the connection method, baudrate, and parameters that you want logged. We use the MUT2 method of communicating with the ECU for logging. You could use OBD2, but its parameters are more limited and the rate of logging is slower.

The default baudrate for Chrome is the factory rate of 15625, so unless you specifically went in Chrome and changed it and flashed it to your ECU, you will want to leave that at 15625. For OpenPort logging, changes to baudrate don't make any difference in how fast logging works, so only change the baudrate if you want quicker EvoScan logging. The OpenPort is communicating with my ECU at 62500 baud just fine, and EvoScan gets about a 25% increase in logging rate at that baudrate. Only worry about that after you've gained some experience with logging and feel totally comfortable messing with such things.

I've attached a text file which is a sample logcfg.txt that you can use with Chrome. It has all the parameters defined that I think you would want to be able to log at some point. Many of the more extraneous parameters that you probably won't log on a regular basis have been commented out. This means that the lines for that parameter begin with a semicolon: ";". To log these additional items, or stop logging a parameter that you don't need, either remove or add the semicolon from the lines associated with that parameter.

Near the end of the file is a section labeled "logging conditions". This defines when the OpenPort logs the data to the MicroSD card. The first set of conditions have the OpenPort log any time the engine is running. The second set of conditions (which are commented out) log anytime the throttle position sensor (TPS) shows more than 75% throttle.

Some of the parameters have "sampgroup" definitions on them. Sampgroups allow you to have some parameters polled less often than others. By default, a parameter is sampled for each line of log output. Setting a parameter to "sampgroup=1" will log it every other polling period. "sampgroup=15" is the highest you can go, and is recommended for use with parameters that don't change rapidly or ones that you don't need real-time information from, but would like logged as a general reference (ie: battery voltage, fuel trims, etc.).

If you want to change the order of the parameter columns in the output file, you can change their positions in the logcfg.txt file.

If you run into issues with logging, look at the logcfg.out file on the MicroSD card - it will contain log messages from the OpenPort and generally tell you why your logging isn't working if you've messed up a parameter or something like that.


Here are the results of testing with the two different baudrate choices for those who are curious:

15625 baud:
Evoscan: 173 samples/sec
OpenPort 2.0: 10 lines/sec (140 samples/sec)

62500 baud:
Evoscan: 220 samples/sec
OpenPort 2.0: 10 lines/sec (140 samples) with 14 parameters
OpenPort 2.0: 6.66 lines/sec (153 samples) with 23 params all top priority
OpenPort 2.0: 10 lines/sec with 18 params but some in different sampgroups

[Greg E]

Thanks Matt! This was one of the things on my long list if things to do. :)

[Toni]

Yup one of the things I want to get running myself. Thanks for the info. I think Forest posted some info about how to do this as well.

[Jimvr4]

Awesome Matt !!

[J. Fast]

Excellent post Matt!

[mjannusch]

Once I started using this, I just had to share - and figured I'd just map up all the parameters so anybody can log anything they want. There's some older examples out there for the DSMs and Subarus that don't use the newer features like sampgroups and multi-byte parameters, so I figured I would just throw a sample config out there that uses all the new stuff and supports everything we need. Hopefully it helps! I'll try to keep it updated if there are any other new features added to the OpenPort 2.0, and for future versions of Chrome as well.

[mjannusch]

Note that as ECUFlash gets updated, there are typically updates to the OpenPort firmware as well. If a new firmware is available, it should get installed to the OpenPort when you go to Help -> Licensing in ECUFlash with the OpenPort connected to the laptop.

[TwIzTeD_3kGt]

AWESOME POST! Thanks, I've been wondering how it was done since I read it on the box! :D

[Jimvr4]

Just getting around to setting this up. Suggest this thread be made a sticky

[Chris@Rvengeperformance]

I guess I didn't make this thread??

http://www.3sgto.org/3000gt-stealth-gto-related-topics/8652-standalone-tactrix-open-port-2-0-datalogging.html

[mjannusch]

I guess I didn't make this thread??

http://www.3sgto.org/3000gt-stealth-gto-related-topics/8652-standalone-tactrix-open-port-2-0-datalogging.html
I searched for something when I started looking at this, but didn't find your thread.

There are some updates in the OpenPort firmware that I take advantage of (logging conditions, sampgroups, native two-byte logging, Chrome v2 parameters, boost logging, etc.), so you may want to take a look anyways.

Wish I would've found your thread first - it probably would've saved a lot of research time.

[Jimvr4]

I guess I didn't make this thread??

http://www.3sgto.org/3000gt-stealth-gto-related-topics/8652-standalone-tactrix-open-port-2-0-datalogging.html

Sorry Chris, you were ahead of your time for me. When Matt's thread popped up I actually had purchased Chrome and Tactrix 2.0 but last year didn't have a clue.

[striker2]

and this thread was older still. lol
http://www.3sgto.org/tuning-engine-electronics-ecu-discussions/11884-tactrix-data-logging.html

a stickied thread regarding setup of the tactrix logging would be a nice place for people to post their log.cfg files for others to reference.

[mjannusch]

Forest Gump and Striker2, your logcfg files both had "setpinvoltage=1,-2" in them. When I tried that, I'd get a constant Check Engine light (or maybe it was ABS - I don't remember for sure). Does that happen on your cars? That line was in the example file that came with the OpenPort, and removing it got rid of the warning light and didn't cause any other side-effects.

[striker2]

nothing of the sort on mine.

[Chris@Rvengeperformance]

Nope no cel for me


Sent from my RM-845_nam_vzw_100 using Tapatalk

[Greg E]

I will get the ABS light sometimes when leaving the tatrix cable plugged in and turning off the ignition then turning it back on. Think I know why this happens. Sometimes the tactrix doesn't switch off the ground for pin one and this disables the ABS ECU which then triggers the light. This happens sometimes in 1G cars with the old data logging cables.

[mjannusch]

Forest and Striker, what year are your cars?

[Chris@Rvengeperformance]

my car is a 95. I also has this on a 92 and no cel.

Now, I do have the ABS light lit when the tactrix is not plugged in to a pc, but is plugged into the logging port standalone, but no CEL. It could have something to do with the initial settings. Those settings were compiled from what some of the older evo guys were using as I couldn't find anything on using it on a 3/s at the time.

[mjannusch]

Now, I do have the ABS light lit when the tactrix is not plugged in to a pc, but is plugged into the logging port standalone, but no CEL. It could have something to do with the initial settings. Those settings were compiled from what some of the older evo guys were using as I couldn't find anything on using it on a 3/s at the time.
Yup, that must be what I was thinking of. Try taking out the setpinvoltage line from your logcfg.txt and the ABS should work normally when using OpenPort logging.

[striker2]

I have a 93 with a 99 SL ECU and adapter harness. no CEL or ABS light when the tactrix is plugged into the OBD2 port that came with the adapter harness, either stand alone logging or via USB

[mjannusch]

I suspect that only '94 and later cars with the built-in fully populated OBD2 type port would have the ABS light problem, since the earlier cars will have a OBD2 plug with only the pins for ECU access and not the ABS diagnostic pin. Just guessing there, but it seems to make sense.

Either way, removing the setpin line from the logcfg.txt should make sure you don't see an ABS light and should work fine on any year car.

[Jimvr4]

I've been using this method for logging and one question I have is how does it know the injector scaling for the IPW and IDC% calculations?

[Chris@Rvengeperformance]

I've been using this method for logging and one question I have is how does it know the injector scaling for the IPW and IDC% calculations?

the size doesnt matter. ipw is just the number of ms the injectors are open and idc is a percentage, so the flow is not considered.

[mjannusch]

Right, the formula basically looks at how many ms the injector is open out of the number of ms available at the current crank RPM rate and results in a percentage. Note that when logging, all these values aren't "snapshotted" at the exact same time and stored for retrieval - they are updated at various times and as the logger routine makes a pass over the data it captures whatever is in those memory cells. So sometimes you may see IDC % fluctuate a bit or have values over 100% which don't make sense. Look at it more over several samples to get a general idea of where your IDCs are, not at single samples. That would likely be the case for any value that's calculated off multiple parameters.

[Jimvr4]

So what you're both saying is IPW is just the pulse width in milliseconds.

When using Evoscan on the Netbook I get 7.6ms IPW and 22% IDC for a TPS of 52% and RPM of 3343. At warm idle I get 1.5-1.8ms IPW

On the Tactrix standalone I get 33ms IPW and 92% IDC for a TPS of 54% and RPM of 3343. At warm idle I get 7ms IPW

Both use 0.256 * x for the IPW scaling so I don't see how they get different results. The only thing different I can think of is the injector scaling for Evoscan logging. I have 600 in there.

[mjannusch]

The injector scaling *shouldn't* come into play... Looking at the Evoscan formula and what's in logcfg.txt it should result in the same values, unless somehow my RPN in the logcfg.txt is incorrect. I don't see how, but it isn't like I write RPN formulas on a regular basis. I dunno! Strange. I'd certainly like to find an answer as to why the results are different.

[Greg E]

So what you're both saying is IPW is just the pulse width in milliseconds.

When using Evoscan on the Netbook I get 7.6ms IPW and 22% IDC for a TPS of 52% and RPM of 3343. At warm idle I get 1.5-1.8ms IPW

On the Tactrix standalone I get 33ms IPW and 92% IDC for a TPS of 54% and RPM of 3343. At warm idle I get 7ms IPW

Both use 0.256 * x for the IPW scaling so I don't see how they get different results. The only thing different I can think of is the injector scaling for Evoscan logging. I have 600 in there.

Double check to see if both are reading the same request. I can't remember off the top of my head which request its supposed to be.

IPW has Injector scaling factored into it because that calculation is done within the ECU.

[Jimvr4]

Both are using request 2B for the front IPW and 29 for the rear IPW

[Chris@Rvengeperformance]

Double check to see if both are reading the same request. I can't remember off the top of my head which request its supposed to be.

IPW has Injector scaling factored into it because that calculation is done within the ECU.

IPW is influenced by injector scaling, but the reporting of it should not be. Whether you have 1000cc injectors or 550s the logger should still see 2 ms or whatever the ecu is commanding and not need to scale it.

[Greg E]

IPW is influenced by injector scaling, but the reporting of it should not be. Whether you have 1000cc injectors or 550s the logger should still see 2 ms or whatever the ecu is commanding and not need to scale it.

That's what I said...

[Jimvr4]

That's what I said...

So why do request 2B and 29 give different IPW between Evoscan v2.9 and Standalone Tacrix 2.0 (they both call for x * 0.256 )? What the heck am I doing wrong?

Is it possible the request ID's are not actually the same?

[Greg E]

So why do request 2B and 29 give different IPW between Evoscan v2.9 and Standalone Tacrix 2.0 (they both call for x * 0.256 )? What the heck am I doing wrong?

Is it possible the request ID's are not actually the same?

Okay I see where the confusion is coming from. Request 2B is the Front bank IPW and 29 is the Rear bank IPW.

Now, the way my EVOScan file is reading IDC is its reading the request 21 which is RPM but it's in hex. So EVOScan is doing all the math at once where Matt is just having the logger do the calculation using RPM and IPW instead of reading the request off the ECU and converting it.

That *shouldn't* make any difference though....


Try replace the 2 definitions in the logcfg file with this:


;paramname=F_InjDutyCycle
;paramid=0x21
;scalingrpn=x,31.25,*,F_InjPulseWidth,*,1200,/
; Requires F_InjPulseWidth params to be logged above

;paramname=R_InjDutyCycle
;paramid=0x21
;scalingrpn=x,31.25,*,R_InjPulseWidth,*,1200,/
; Requires R_InjPulseWidth params to be logged above

[Jimvr4]

Yes I know that the IDC calculations differ between you and Matt.

The issue is not the IDC calculation, it is the IPW. Again in Evoscan request 2B gives 1.5-1.8ms for IPW while Matts gives 7ms for the same request 2B.

The only thing different I can think of is the injector scaling for Evoscan logging. I have 600 in there.

[Greg E]

Yes I know that the IDC calculations differ between you and Matt.

The issue is not the IDC calculation, it is the IPW. Again in Evoscan request 2B gives 1.5-1.8ms for IPW while Matts gives 7ms for the same request 2B.

The only thing different I can think of is the injector scaling for Evoscan logging. I have 600 in there.

Oh you're talking about that input in the upper right corner. That can be disregarded. Back in the day, the EVO guys used that to calculate engine load. It's not used in the IPW calculations anywhere. I might have told people otherwise years ago but that was wrong.

I have no idea why you'd be seeing 2 different values...

[Jimvr4]

Spent some time on OpenEcu.org and couldn't find a thing on it. Is this a question for Colby??

Also logged the car with both methods and again confirmed the IPW request yields different results just like I wrote. Looks like I have to use the netbook method to get good data. That won't be bad if I can figure out how to display the WB scaled on a gauge widget :)