Openport Stand-Alone Logging Beta

[cboles]

I was curious if there is a way to control the logging start/stop via a switch, etc the Set/Coast or Resume/Accel switches, defogger switch, ac switch?

Thanks,
Matthew

Yes - it can already do that. What car / ROM do you have? I can make up an example.

[Tephra]

Cool.

I actually don't mind that it doesn't start at 0

Priority (loop skipper) would be my biggest item on a wishlist

[cboles]

Looks good.
Can we implement a priority type option - ie 1 = get this entry EVERY loop, 2 = every second loop, 20 = every 20th loop

That way I can put fuel trims @ 200 to save logging speed for rpm/knock/afr etc

I already have it implemented a different way for EcuFlash, so I was planning on sticking with the same method. I like the simplicity of your option, but depending on how it is implemented, you get a problem where you may need to sample many more things than you do on average logging intervals at the common multiples of your priorities, which jitters the sampling intervals of your paramters.

The method I am using works like this:

* *all* priority 1 items are sampled once per logging period (think of this as an inner loop)
* *one* priority 2 item is sampled every logging period. if there are multiple priority 2 items, it rotates through which one is requested each period. (think of this as an outer loop). so if you have 1 pri2 item, it logs at the same rate as pri1 items. if you had {2,3,4} items, the rates would be {1/2,1/3,1/4} respectively.
* *one* priority 3 item is sampled each time the priority 2 loop completes instead of requesting another priority 2 item.
* etc.

The result is that there is a constant number of requests per logging cycle. You don't directly control the request rate of the items - the number of items at each priority level will determine that. You don't really have control of the logging rate of priority 1 items anyway, since the speed of the logging channel will determine that for you. I'm trying to keep people from overspecifying the sampling rate for each of their parameters when the software really knows best in this case. It also makes it easy to log more parameters without playing with rate/priority settings on others.

[Tephra]

ok.

In the most basic example:

logging rpm, load and knocksum every loop (because they are super important)
logging long term fuel trim every 200 loops (because its not important)

In your setup I can't see how you would tell the unimportant item to log MUCH less often?

Don't worry about explaining it if you think its good enough

I know my priority system can cause a staggered output, ie when all the non important items log they will cause a longer gap in the important items - but that's not too big a problem...

[mshoemaker]

Yes - it can already do that. What car / ROM do you have? I can make up an example.

I have a 2009 Subaru Impreza WRX, AZ1G401V

Thanks,
Matthew

[cboles]

it's sort of a philosophical question really. i came from a biomedical engineering / signal processing background where regular sampling was essential. here i can see how it can be a bit less important. however, if you are trying to calculate any derived quantities that use your reported time intervals (e.g. acceleration, horsepower), you would want the sampling intervals to be accurate.

so if you require periodic sampling and you are resampling your data to a single output logging rate (so you appear to have a value for each parameter at each time interval), and the ECU is not instantaneous in its responses, you have a fixed number of "slots" each interval in which to request and receive parameters, and you might as well use all of those slots each time. so yes, the fuel trim will be logged more frequently if it is the only pri2 parameter, but this is only because this is still gives the best-case periodic sampling rate. no harm in sampling something too often if you have the time for it. the sampling rate for this param will slow down if you have more long term items, but they will all continue to be sampled on regular intervals and will never affect the sampling intervals for the pri1 parameters.

Take S as the single parameter sampling rate and first compare the two method using your example of 3 fast parameters (Pri1) and one slower one (Pri2):

[pri1 logging rate] [pri2 logging rate] [sampling interval error rate] [sampling interval error magnitude]
tephra S/3 S/200 S/200 S/3
cboles S/4 S/4 0 0

Also look at a case where you have 15 Pri1 params, and 10 Pri2 ones (Priority = 200, for example):

[pri1 logging rate] [pri2 logging rate] [sampling interval error rate] [sampling interval error magnitude]
tephra(1) S/15 S/200 S/200 S*10/15
tephra(2) S/16 S/200 S/20 S/16
cboles S/16 S/160 0 0

In case (1) I am assuming all of your Priority=200 samples are in phase and happen at once. This has a low error rate, but high magnitude.
In case (2) I am assuming all of your Priority=200 samples are dephased using some software smarts. This has a higher error rate, but lower magnitude each time.

So in the first example, you get a ~25-33% improvement in (average) logging rate at the expense of sampling interval errors that happen every 200 samples.

So in the second example, you get a ~7% improvement in (average) logging rate at the expense of sampling interval errors that either happen very often or are very significant.

Depending on what your goals are, each method has it's merits. I am pushing for accuracy over slightly faster but occasionally irregular sampling. Yours also has the benefit of specifying the low-priority sampling rates.

ok.

In the most basic example:

logging rpm, load and knocksum every loop (because they are super important)
logging long term fuel trim every 200 loops (because its not important)

In your setup I can't see how you would tell the unimportant item to log MUCH less often?

Don't worry about explaining it if you think its good enough

I know my priority system can cause a staggered output, ie when all the non important items log they will cause a longer gap in the important items - but that's not too big a problem...

[ladams00]

Unless Colby has something really cool (as I'm not certain of the logcfg.txt syntax of how to pick off individual on/off bits in these 8bit values we monitor (I can't make the defogger button work on it's own)), here's what I currently use to start/stop logging on my 05 sti:



;define the following parameter which monitors a hand full of on/off switches ie Clutch, Brake Switch, Brake Light, Cruise Resume, Cruise Coast, etc
paramname=clutchbrakecoast
paramid = 0x121

;set start of logging at 95% throttle
trigparam=throttle
condition=gt ; gt lt gte lte eq ne ... > < >= <= == !=
value=95
action=start

;set stop of logging with: clutch, brake pedal, and coast button depressed simultaneously
trigparam=clutchbreakcoast
condition=gte
value=208
action=stop

Yes - it can already do that. What car / ROM do you have? I can make up an example.

I have a 2009 Subaru Impreza WRX, AZ1G401V

Thanks,
Matthew

[cboles]

Unless Colby has something really cool (as I'm not certain of the logcfg.txt syntax of how to pick off individual on/off bits in these 8bit values we monitor (I can't make the defogger button work on it's own)), here's what I currently use to start/stop logging on my 05 sti:]

It does support bitfields and bit offsets - I hope to have time to post an example later today...

c

[ladams00]

Ohh yeah, one other thing Colby..

Initially I wasn't able to update the firmware on the OP2 to 1.10....only from 1.6 to 1.7 with the latest build of EcuFlash.

I found that the updated op20pt32.dll that the beta logger installs goes into my C:\Windows\System32 directory.
Upon firing up EcuFlash, it opens the older version which sits in C:\Program Files\OpenECU\EcuFlash.

So I copied the newer file over into C:\Program Files\OpenECU\EcuFlash and when attemping a read operation the firmware update completed successfully.

I don't know if my machine's environment is different from others here that would cause the issue for just myself (perhaps different library pathing or something?). WinXP Pro OEM SP3 with some other junk.

No matter, works well now.

[cboles]

Ohh yeah, one other thing Colby..

Initially I wasn't able to update the firmware on the OP2 to 1.10....only from 1.6 to 1.7 with the latest build of EcuFlash.

I found that the updated op20pt32.dll that the beta logger installs goes into my C:\Windows\System32 directory.
Upon firing up EcuFlash, it opens the older version which sits in C:\Program Files\OpenECU\EcuFlash.

So I copied the newer file over into C:\Program Files\OpenECU\EcuFlash and when attemping a read operation the firmware update completed successfully.

I don't know if my machine's environment is different from others here that would cause the issue for just myself (perhaps different library pathing or something?). WinXP Pro OEM SP3 with some other junk.

No matter, works well now.

Thanks. I am aware of the problem. I'm going to start removing that DLL fromm the EcuFlash directory in future installations.

[Tephra]

Hi Colby,

ok I understand.

With my example you can manually stagger the phase of the unimportant items, ie 199 for one, 200 for another, 201 for another... Its not too big a deal

Does your priority work in the current firmware? I would like to give it a whirl.

Also for Mode23 are you sleeping to maintain a regular logging interval? (ie why the time is going up in constant amounts)

Cheers
D.

[cboles]

I have posted yet another version at the top of the thread. You will want to download that before trying this example, as it more efficient at requesting multiple bitfield items over SSM than previous firmware. Here is an example for triggering via the rear defogger switch:

Code: Select all

; 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 CAN, which only works
; with newer CAN-based Subarus.
;
; note that everything is the same as the K-line example, except that "type=ssmcan"

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

; we are logging SSM via CAN
type = ssmcan            

; 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 (defaults to linear, which is of the form y = s1*x+s2). scale1 defaults to 1, scale2 defaults to 0
scaletype = linear         
scale1 = 0.25

; continue specifying other parameters
paramname = load
paramid = 0x07
scale1 = 0.3921569

paramname=speed
paramid = 0x10
scale1 = 0.621371192

paramname = mrp
paramid = 0x24
scale1 = 0.145098
scale2 = -18.572549

paramname = throttle
paramid = 0x15
scale1 = 0.3921569

paramname = timing
paramid = 0x11
scale1 = 0.5
scale2 = -64

; 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

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

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

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

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

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


;-------------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 some evaluation of the form [trigparam] [condition] [value]
; and a resulting action which is done if the evaluation is true

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

trigparam = defogger_sw
condition = eq   
value = 1
action = start

trigparam = defogger_sw
condition = eq
value = 0
action = stop


Unless Colby has something really cool (as I'm not certain of the logcfg.txt syntax of how to pick off individual on/off bits in these 8bit values we monitor (I can't make the defogger button work on it's own)), here's what I currently use to start/stop logging on my 05 sti:



;define the following parameter which monitors a hand full of on/off switches ie Clutch, Brake Switch, Brake Light, Cruise Resume, Cruise Coast, etc
paramname=clutchbrakecoast
paramid = 0x121

;set start of logging at 95% throttle
trigparam=throttle
condition=gt ; gt lt gte lte eq ne ... > < >= <= == !=
value=95
action=start

;set stop of logging with: clutch, brake pedal, and coast button depressed simultaneously
trigparam=clutchbreakcoast
condition=gte
value=208
action=stop

Yes - it can already do that. What car / ROM do you have? I can make up an example.

I have a 2009 Subaru Impreza WRX, AZ1G401V

Thanks,
Matthew

[cboles]

Hi Colby,

ok I understand.

With my example you can manually stagger the phase of the unimportant items, ie 199 for one, 200 for another, 201 for another... Its not too big a deal

If I understand how your method works correctly, 199,200, and 201 would be the sampling _periods_ of those 3 items, which most of the time would not be overlapping, but would occasionally pile up at common multiples of 199, 200, and 201. You could instead keep them all at 200 and add an actual sampling phase offset to each, but it starts to get tricky when you have many different sampling periods (a fun programming puzzle, actually...).

Hi Colby,
Does your priority work in the current firmware? I would like to give it a whirl.

Also for Mode23 are you sleeping to maintain a regular logging interval? (ie why the time is going up in constant amounts)

Cheers
D.

Priority is not in this firmware rev yet. I need to rework some of the SSM code (which gets all of the params in a single request) to build new requests on the fly. It's much easier for the MUTII / "mode23".

In the current release of the "mode23" I am not sleeping for the rest of the interval - I am free-running and resampling the output for the log file. I am going to switch back to requesting each param only once per interval though, now that I have a good handle on the performance. The issue really came down to estimating what was the worst case interval in which I could request and receive a certain number of parameters (to auto-determine the logging rate). Due to other CAN bus activity and variable ECU response times, the worst case was much worse than the average case, which would lead to generally conservative and disappointing logging rates. The current version samples continuously at the maximum rate and the resampling makes the output rate unaffected by whether 0,1,2 or more samples of a parameter have been acquired during the logging interval (except of course for the aliasing jitter of *when* the sample was acquired within the interval). I do want to get back to one sample per interval though, for all of the reasons of time accuracy that we have been discussing previously.

[cboles]

The card doesn't matter too much speed-wise, except that it better to format it FAT-16 as the OP2 ends up having to write less to it each time it has to update the FAT data. That said, in FAT-32 with a large cluster size, it should be able to hit all of the FAT-32 maximums. There is really littler reason to get a card more than 1-2GB since that is a ton of logging data, perhaps for the life of your car!

What would the best SD Card to get, for people buying new cards?

A 2GB card formatted FAT-16?

Does card speed only matter when copying files to your computer, or could the card be over run when logging?

Does the OP 2.0 have any size limitations? SDHC 2.0 32GB Max or FAT-32 2TB Max?



Thanks, can't wait to try this out and not have to bungy cord my laptop to the passenger seat anymore.

[Tephra]

Colby - just for your information this is my current priority list:

rpm = 1
knock = 1
psig = 1
afr = 1
load = 1
wgdc = 2
tps = 3
airflow = 3
fuel trims = 200 (there are 2)
octane number = 200

The only reason I log TPS to "easily" identify sections of interest in the log, ie pull or other weird things when driving (ie something weird happened, 100TPS so I can find it in the log)

I don't particularily care about the priority 200 items, i dont want them to affect the logging speed, but i do want them logged occasionally, *just incase they deviate too much from the norm*

The main thing about logging, is getting the MOST samples possible so that I can adjust the tune - maintaining timing is secondary (timing useful for horsepower calcs etc)

If its not too hard then maybe implement my simple method too???