Openport Stand-Alone Logging Beta

[Mart]

yea but Romraider cant discover the OpenPort 2.0 like the 1.0 ( I tried to add some USB define in the linux kernel with no luck as well..):(

For the record, I was able to retrieve my logfile from the tactrix under linux

Yes - an OP2 with a SD card should appear as a USB composite device that consists of a Mass Storage Class device and a Communications Device Class (COM port / modem) device. Most operating systems have built in drivers for these. OSX has some bugs that prevent the CDC device from working properly in the composite device case that I have been bugging them to fix (and one of their devs *has* fixed), but it doesn't seem like the fix gets rolled into any of their releases.

[cboles]

It certainly could... maybe I could add a special function to the DLL to provide that information. EcuFlash does discover the OP2.

yea but Romraider cant discover the OpenPort 2.0 like the 1.0 ( I tried to add some USB define in the linux kernel with no luck as well..):(

For the record, I was able to retrieve my logfile from the tactrix under linux

Yes - an OP2 with a SD card should appear as a USB composite device that consists of a Mass Storage Class device and a Communications Device Class (COM port / modem) device. Most operating systems have built in drivers for these. OSX has some bugs that prevent the CDC device from working properly in the composite device case that I have been bugging them to fix (and one of their devs *has* fixed), but it doesn't seem like the fix gets rolled into any of their releases.

[Tephra]

good stuff Colby.

I am still hanging out for an slightly improved priority scheme, yours or mine - doesn't matter.

[cboles]

Actually - I understand what you are saying now. The issue is that I haven't built a J2534 library/dylib for linux yet...

yea but Romraider cant discover the OpenPort 2.0 like the 1.0 ( I tried to add some USB define in the linux kernel with no luck as well..):(

For the record, I was able to retrieve my logfile from the tactrix under linux

Yes - an OP2 with a SD card should appear as a USB composite device that consists of a Mass Storage Class device and a Communications Device Class (COM port / modem) device. Most operating systems have built in drivers for these. OSX has some bugs that prevent the CDC device from working properly in the composite device case that I have been bugging them to fix (and one of their devs *has* fixed), but it doesn't seem like the fix gets rolled into any of their releases.

[cboles]

I'm still not getting the actual scenario where you really need beyond 2 priority levels. The current scheme logs the fast stuff fast, and the slow stuff reasonably fast with very little performance hit on the fast stuff, while keeping the logging interval constant at all times. Adding a third priority level wouldn't make the fast stuff any faster, and could only make the slow stuff a little faster, so it doesn't really seem that helpful.

Put another way, assuming the fast stuff is fast enough, unless you have a really long list of slow stuff to log, the slow stuff should be acquired at a reasonable speed too (probably faster than the intervals you currently have them set to). Can you give me a sample of what you are typically logging with your software (I don't care what the params are, just a count of how many at what intervals). I could do a different scheme with phased modulo counters similar to what you are doing but that gives a more tightly optimized worst-case sampling interval, but I'm just not sure it's worth the users time to be messing with the sampling periods of individual parameters so finely.

good stuff Colby.

I am still hanging out for an slightly improved priority scheme, yours or mine - doesn't matter.

[Tephra]

Well the perfect example is fuel trims:
I don't care when they are updated, as long as they are updated occasionally, ie once every 250+ loops is fine.

In my logger I had them set to 250 which meant over the course of a pull there is a low chance of those items being requested and slowing down the logging speed of the other items.

Currently in your logger including the FT's impacts the low priority items - because they are rated at the same priority as them.

eg I have TPS, WGDC and Airflow as low priority - I don't need them updated as often as knock/rpm/psi/afr but I still want to see them throughout the pull.

Including FT's in the same priority means that TPS/WGDC and Airflow now take a heavy hit in logging speed. In fact they all get updated almost half as often.

Really we just need a different priority level for fuel trims, which would be ultra low priority and I wouldn't care that it impacted on the P2 items...

At the moment I am getting about 80 rows of data over a pull, previously (With my logger) I was getting 100+ and I was getting the data I wanted at the rate I wanted.

Thoughts?

[cboles]

It looks like some of the Subaru issues are related to having a large number of parameters (or total parameter bytes). I have some guests in town, so I can't do too much work on the computer until tomorrow night. It should be easy to fix though. Thanks for your patience!

c

[williaty]

Colby, I've downloaded the software from the first post. I've deleted the .dll from EcuFlash's directory. I've initiated a ECU read operation that has triggered the OP20 firmware update. I've placed a logcfg.txt on the microSD copied and renamed from your "Subaru K-Line" example file with no changes. When I plug the OP20 into the OBD-II port, the lights on the OP20 illuminate and do their little dance. The OP20 is not connected to a laptop via USB. After running the car at idle for a bit, no log is created. An empty logcfg.out is created.

Any idea what's going wrong?

[cboles]

The more I think about it, this issue is really more a philosophical one as to if the logging needs to remain periodic or not. I think the difference between the 80 and 100+ samples/pull is mostly due the saftey margin I am adding when acquiring the data periodically plus some synchronous disk I/O, versus letting the acquisition free-run. If you take the periodic approach (as I am trying to), any parameter that you request in addition to everything else once every 250 samples is a time slot you need to leave space for every sample to remain periodic - which means you might as well fill that slot with samples of something the rest of the time. I'll check into adding P3, but it won't do much for you unless you are monitoring more than one fuel trim parameter. What my current method won't work well for is a scenario where you need to log a couple of parameters at full rate, and you need to log a bunch of things at say, 1/2 that rate. I know good ways of doing that as well, but problems can arise where the user can pick a lot of odd (e.g. prime) logging rates for parameters and create very slow worst case logging rates for a relatively small number of parameters.

Well the perfect example is fuel trims:
I don't care when they are updated, as long as they are updated occasionally, ie once every 250+ loops is fine.

In my logger I had them set to 250 which meant over the course of a pull there is a low chance of those items being requested and slowing down the logging speed of the other items.

Currently in your logger including the FT's impacts the low priority items - because they are rated at the same priority as them.

eg I have TPS, WGDC and Airflow as low priority - I don't need them updated as often as knock/rpm/psi/afr but I still want to see them throughout the pull.

Including FT's in the same priority means that TPS/WGDC and Airflow now take a heavy hit in logging speed. In fact they all get updated almost half as often.

Really we just need a different priority level for fuel trims, which would be ultra low priority and I wouldn't care that it impacted on the P2 items...

At the moment I am getting about 80 rows of data over a pull, previously (With my logger) I was getting 100+ and I was getting the data I wanted at the rate I wanted.

Thoughts?

[haproot]

It looks like some of the Subaru issues are related to having a large number of parameters (or total parameter bytes). I have some guests in town, so I can't do too much work on the computer until tomorrow night. It should be easy to fix though. Thanks for your patience!

c

Ahhhhhhhhh... I commented out a whole bunch of parameters I don't need. That seems to of helped a lot. I will continue playing around.
Defogger switch trigger seems to be working now.

Here's my logcfg.txt

Code: Select all

; uncomment the line below to minimize the information written to logcfg.out
; this will greatly decrease the startup time to begin logging if you already
; have a working logcfg.txt without any problems
;
; debug=noout

; sample logging configuration file for openport 2.0
; must be named logcfg.txt and be placed in the root directory of the
; microSD card inserted in the openport in order to work

; this sample logs using the SSM protocol over the K-line, which works
; for both CAN-based and older Subarus

;----------------ssm----------------
; log channel settings

; we are logging SSM via the K-line
type=ssmk            

; each parameter gets a name you chose
paramname = RPM            

; the paramid is used in the SSM request
paramid = 0x0E            

; how many bits in the returned value (defaults to 8, so you usually don't need to specify this)
databits = 16            

; how to scale the results using a RPN (http://en.wikipedia.org/wiki/Reverse_Polish_notation) notation, with data and operators seperated by commas
; the operators are as following:
;       + : add
;       - : subtract
;       * : multiply
;       / : divide
;
;       x : represents the raw (unscaled) parameter
; 123.456 : example of a constant
;
; if no scaling is specified, the raw value will be used
;
; the OP2 has no FPU - it must do floating point calculations in software which can
; create performance issues, so be efficient in your RPN expressions by doing the following:
;
; * minimize the number of operations; e.g. ((x * 2) + 1) * 2 => x * 4 + 2
; * don't divide by a constant when you can multiply instead; e.g. x / 4 => x * 0.25
; * don't make constant expressions that can instead be pre-calculated; e.g. x * 3 / 4 => x * 0.75

scalingrpn = x,0.25,*   

; continue specifying other parameters
paramname = load
paramid = 0x07
scalingrpn = x,0.3921569,*

; commented out here is an example for reading a direct RAM parameter, a 32-bit float in this case
;paramname = load
;paramid = 0xFF6578
;isfloat = 1 ; the raw data is a 32-bit floating point number (no need to set databits = 32)

;Engine Load (4-Byte)*
paramname = ELoad
paramid = 0xFF6578
isfloat = 1

paramname = speed
paramid = 0x10
scalingrpn = x,0.621371192,*

paramname = IAT
paramid = 0x12
scalingrpn = x,0.40,-
priority = 2

paramname = coolant_temp
paramid = 0x08
scalingrpn = x,0.40,-
priority = 2

;paramname = battery_volts
;paramid = 0x1C
;scalingrpn = x,0.08,*
;priority = 2

paramname = mrp
paramid = 0x24
scalingrpn = x,128,-,0.145098,*

;Manifold Relative Pressure (4-byte)
;paramname = MRPress
;paramid = 0xFF6398
;isfloat = 1

paramname = MAF
paramid = 0x13
databits = 16            
scalingrpn = x,0.01,*

paramname = throttle
paramid = 0x15
scalingrpn = x,0.3921569,*

paramname = timing
paramid = 0x11
scalingrpn = x,128,-,0.5,*

paramname = WGDC
paramid = 0x30
scalingrpn = x,0.3921569,*

paramname = IPW ; injector #1 pulse width
paramid = 0x11
scalingrpn = x,0.256,*

;Feedback Knock Correction (4-byte)
paramname = FBKC
paramid = 0xFF7F14
isfloat = 1

;Knock Correction Advance (4-byte)
paramname = KnockAdv
paramid = 0xFF7F10
isfloat = 1

paramname = IAM
paramid = 0xF9
scalingrpn = x,0.0625,*
priority = 2

; some samples of logging "bitfield" values that are not whole bytes
; if you want to log more that one of these efficently, group them by
; paramid and the OP2 will only issue a single request to get all of
; the bits within each paramid

;paramname = ignition_sw
;paramid = 0x62
;databits = 1
;offsetbits = 3

; to still acquire a parameter (perhaps for triggering or a calculation)
; but not record it in the log, set isvisible equal to zero (it is 1 by default)
isvisible = 0

;paramname = AC_sw
;paramid = 0x62
;databits = 1
;offsetbits = 1
;isvisible = 0

paramname = defogger_sw
paramid = 0x64
databits = 1
offsetbits = 5
isvisible = 0

;paramname = blower_sw
;paramid = 0x64
;databits = 1
;offsetbits = 4
;isvisible = 0

;paramname = clutch_sw
;paramid = 0x121
;databits = 1
;offsetbits = 7
;isvisible = 0

;paramname = brake_sw
;paramid = 0x121
;databits = 1
;offsetbits = 3
;isvisible = 0

;-------------calculated parameter---------------
;
; you can derive calculated parameters from other parameters
; using RPN expressions
;
type = calc            

paramname = IDC
scalingrpn = RPM,IPW,*,0.0008333333,*

;-------------triggers---------------
;
; note that parameters must be previously defined
; before defining triggers using them
;
; triggers allow you to control when logging starts and stops
; this example sets up triggers such that logging only occurs
; when the engine is running (RPM > 0)
;
; triggers consist of a condition (a RPN expression using comparison operators)
; and an action. the RPN comparison operators match those in the C language:
;
; > < >= <= == != && ||
;
; if the condition evaluates to a non-zero value, that action is taken

;conditionrpn = RPM,2000,>   
;action = start

;conditionrpn = RPM,1900,<
;action = stop

; here is a second triggering example using the rear defogger switch
; uncomment it and comment out the sample above to use it

conditionrpn = defogger_sw,1,==
action = start

conditionrpn = defogger_sw,0,==
action = stop


[MattS00]

What I would like to see would be the ability to log different parameters under different running conditions. For instance log fuel trims and what not during closed loop, and log AFR/RPM/Knock/ect during open loop. That way you only log what it needed during WOT, but you can still go back and look at fuel trims without making changes to the logcfg.txt. It would also make finding the WOT parts easier to find in excel.

[cboles]

What I would like to see would be the ability to log different parameters under different running conditions. For instance log fuel trims and what not during closed loop, and log AFR/RPM/Knock/ect during open loop. That way you only log what it needed during WOT, but you can still go back and look at fuel trims without making changes to the logcfg.txt. It would also make finding the WOT parts easier to find in excel.

Keep in mind that the long term goal here is not to be looking at CSV files or excel - I will have a nice GUI that will make finding regions of interest easy.

[cboles]

Just an update: I have found the SSM K-line related bugs and should have a release out during the weekend. It also fixes the float problem. If you have an 08 STI, I will also have a ROM patch for you that allows fast CAN logging of RAM parameters. The patch could be adapted to any Subaru CAN ROMs...

[mshoemaker]

So with the release at the head of this thread should I be able to use the ssmk type to enable me to log RAM parameters on my 09 WRX, or does this fall into "k-line related bugs?"

Also will your ROM patch work on the 09 WRX?

If you want/need any help with GUI let me know, I would be happy to lend a hand.

Matthew

Just an update: I have found the SSM K-line related bugs and should have a release out during the weekend. It also fixes the float problem. If you have an 08 STI, I will also have a ROM patch for you that allows fast CAN logging of RAM parameters. The patch could be adapted to any Subaru CAN ROMs...

[cboles]

you will have two issues with ssmk in the current release:

* floats won't work (actually, any 32 bit values won't - i accidentally deleted a line from a bit-mask table)
* large parameter sets won't work (if you get more than 27 data bytes coming back)

So with the release at the head of this thread should I be able to use the ssmk type to enable me to log RAM parameters on my 09 WRX, or does this fall into "k-line related bugs?"

Also will your ROM patch work on the 09 WRX?

If you want/need any help with GUI let me know, I would be happy to lend a hand.

Matthew

Just an update: I have found the SSM K-line related bugs and should have a release out during the weekend. It also fixes the float problem. If you have an 08 STI, I will also have a ROM patch for you that allows fast CAN logging of RAM parameters. The patch could be adapted to any Subaru CAN ROMs...