Openport Stand-Alone Logging Beta

[haproot]

I'll go check that in my car too - I'm not sure how this got broken, or if it is. Are you doing CAN or K-line logging?

Using the Can logger. So I take it the K-Line is usable on the Can bus cars like the 08 STi?
Is there much of a difference between CAN logging and K-line? advantages/disadvantages?

[cboles]

I think I am going to make a patch to the ECU code so that CAN can do RAM reads. The speed of the CAN logging is great, but not being able to read any of the juicy RAM parameters negates the advantage of it.

K-Line power baby!!

I'll go check that in my car too - I'm not sure how this got broken, or if it is. Are you doing CAN or K-line logging?

Same here, start/stop with the defogger switch doesnt seem to work. The RPM condition does work for me.

Mart

[Mart]

Colby,

SSM CAN logging is faster than K-LINE logging? By a factor of?

I think I am going to make a patch to the ECU code so that CAN can do RAM reads. The speed of the CAN logging is great, but not being able to read any of the juicy RAM parameters negates the advantage of it.

K-Line power baby!!

Same here, start/stop with the defogger switch doesnt seem to work. The RPM condition does work for me.

Mart

[haproot]

Ok so I'm gonna give K-line a try. I'm making defogger switch visible so I can see what value it is seeing.

Think this would work for a good trigger?

Code: Select all

conditionrpn = throttle,85,>
action = start

conditionrpn = throttle,84,<
action = stop


[haproot]

Ok so I'm gonna give K-line a try. I'm making defogger switch visible so I can see what value it is seeing.

Think this would work for a good trigger?

Code: Select all

conditionrpn = throttle,85,>
action = start

conditionrpn = throttle,84,<
action = stop


Ok that doesn't work too well.. well it works, but not like I intended lol.
It did take some logs for me at throttle openings above 85.
Also my defogger switch parameter is working it shows 1 when turned on and 0 when off. I'll have to try that trigger again.

I did have the direct Engine load parameter logging and I'm getting the funky values as well.

Code: Select all

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


Gives me values like: 1.10E-19
but when full throttle kicks in it'll show something like 2.03125 but I would think it would be a bit higher @ 18psi.

[cboles]

It's a little bit of an apples to oranges comparison. There are two factors:

1) The basic communication rate
2) The response latency (between the end of a request and the beginning of a response)

The SSM sequence to request and receive a parameter is roughly equivalent for the two protocols, so that overhead is the same.

for K-line:

baud = 4800 (effectively 480 bytes/sec)
SSM latency = 4ms

for CAN
baud = 500000 (effectively ~25k bytes/sec for ISO15765)
SSM latency = 5ms

So, to read 20 parameters (3 bytes/param to request, 1 byte/param received + 2tx/1rx header bytes (CAN) or 6tx/5rx header/checksum bytes (K)) it works out like this

K: (20*(3+1)+6+5)/480 + 4ms = 194ms (5Hz)
CAN: (20*(3+1)+2+1)/25000 + 5ms = 8.3ms (120Hz)

So CAN is 24x faster. There are some other protocol issues can make CAN a little slower than this calculated value, but you get the idea.

Colby,

SSM CAN logging is faster than K-LINE logging? By a factor of?

[Mart]

Thanx for the awesome information.

It matches approx. what I presently see with tactrix/K-line -> ~4-5 q/s

I do see the same rate with my custom SSM/Display tool.

I wish there was an easy way to up the baud rate

Mart

It's a little bit of an apples to oranges comparison. There are two factors:

1) The basic communication rate
2) The response latency (between the end of a request and the beginning of a response)

The SSM sequence to request and receive a parameter is roughly equivalent for the two protocols, so that overhead is the same.

for K-line:

baud = 4800 (effectively 480 bytes/sec)
SSM latency = 4ms

for CAN
baud = 500000 (effectively ~25k bytes/sec for ISO15765)
SSM latency = 5ms

So, to read 20 parameters (3 bytes/param to request, 1 byte/param received + 2tx/1rx header bytes (CAN) or 6tx/5rx header/checksum bytes (K)) it works out like this

K: (20*(3+1)+6+5)/480 + 4ms = 194ms (5Hz)
CAN: (20*(3+1)+2+1)/25000 + 5ms = 8.3ms (120Hz)

So CAN is 24x faster. There are some other protocol issues can make CAN a little slower than this calculated value, but you get the idea.

Colby,

SSM CAN logging is faster than K-LINE logging? By a factor of?

[haproot]

So CAN is 24x faster. There are some other protocol issues can make CAN a little slower than this calculated value, but you get the idea.

I definitely notice much larger logs (faster sampling) with the CAN logger than with the K-line. But if K-line will give me my extended parameters I'll have to go with that for now.

[haproot]

Is it possible to set the format of the extended parameters?
Like rpm.. It'll give me values like 3937.5 or 4342.75. Can we somehow axe the decimal? Or limit it to one or two places?

[haproot]

LOL just tried to use the defogger trigger again. And I added a couple parameters. It's all wacky now. I got like 379 separate log files. All with only 1 or 2 lines of data in them. And the data is all wrong. no way i could have an IAM of 12 and be going 122.6 mph.. i never broke 50 on my way home.

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,*

; 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 = 1

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,0,>   
;action = start

;conditionrpn = RPM,0,==
;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

;conditionrpn = throttle,85,>
;action = start

;conditionrpn = throttle,84,<
;action = stop


[Tephra]

Is it possible to set the format of the extended parameters?
Like rpm.. It'll give me values like 3937.5 or 4342.75. Can we somehow axe the decimal? Or limit it to one or two places?

Yeah if we could specify the printf format that would be good, ie %2f or %d etc etc

[Mart]

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

[cboles]

I debated that, but ultimately I figured the data files to be read by programs, like EcuFlash, Excel, Matlab, etc. There is a lot optimization for speed in an embedded environment, so my conversion from floats to ASCII happens at a lower level than a printf.

Is it possible to set the format of the extended parameters?
Like rpm.. It'll give me values like 3937.5 or 4342.75. Can we somehow axe the decimal? Or limit it to one or two places?

Yeah if we could specify the printf format that would be good, ie %2f or %d etc etc

[cboles]

Agreed. That is the big problem with CAN at this point. It's not that big of a deal to change the ROM to fix this - it's just a pain to do it for lots of ROMs. Hopefully I can do an example for my USDM car (08 STI), and other people can port that to other ROMs.

I am also artificially capping the CAN logging rate at 20Hz instead of its maximum just because my SD card file I/O is not asynchronous and occasionally the SD card becomes busy for longer periods when it has to erase / rewrite a block, which would causes samples to be skipped if things ran any faster. Once I move to async I/O, then I can go faster.

So CAN is 24x faster. There are some other protocol issues can make CAN a little slower than this calculated value, but you get the idea.

I definitely notice much larger logs (faster sampling) with the CAN logger than with the K-line. But if K-line will give me my extended parameters I'll have to go with that for now.

[cboles]

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.