Openport Stand-Alone Logging Beta

[LM_logger]

Cheers,

Is that where you're based... Seattle?

Not sure if many in USA use it, and it would be a costly exercise to send mine back and forth and risk charges on return.

I'll see what I can do on EvoM to try and get one your way if the following is no good, or enquire further re sending my own. Would the data from LM-1 output to COM, piped to a file be what you are looking for or be any help? My nix box is down at present, and wouldn't know how to achieve in windows, but could if I got other up and running soon

[mfb]

I kinda figured out the ground and attaching the lc-1 to OP2 when it is off. haha Well that was the last course of action after doing recalibration for 3 times in a span of just a week. I have OP2 take care of the afr scaling (as per your txt file in the installation directory) and I dont believe its the issue I have. I used 01 parameter insted of 02. 02 is set for something else I think and using 02 gives me 250 plus values instead of of 01 which is the expected 2 digit afr values.

My issue is more of the LC-1 thinking I sent a command for a recalibration. I will follow your tip and ensure I just plug in when lc-1 is off. With the recent calibration, everything seems to be a tad richer. Cool weather makes us run richer or leaner based on same maf scaling and open loop fuel table? Its either that or something wrong with my recalibration.

Thanks again for this post, you confirmed it

I think I covered this somewhere before - it is basically a minor hw/sw design flaw in the LC-1 that can cause it to lose its settings when you you plug it into another device. What happens is that the tip terminal of the 2.5 plugs can get grounded as you plug them in, which is not a big deal in itself since it is an input, but some unfortunate protocol choices can make that glitch look like some sort of "clear calibrations" command. This isn't speculation - I heard this from the engineers at Innovate. So the solutions are to:

1) Plug the LC-1 in to the OP2 only when the LC-1 is off
2) Let the OP2 take care of the AFR scaling so that you don't notice the problem

Hi Colby,

Can you check on possibility that the external jack intermittently sending out a signal back to the lc-1? This is my third time to experience getting an error on my afr reading that makes me do another recalibration. When this happens, I see the blue light go on longer a bit before it starts blinking for can. At this time, I know that AFR already needs recalibration. Im thinking that I need to enable the logger first (one then off) prior to inserting and logging with the lc1.

Also, there was an instance before that I wasnt able to log even after I pressed the defogger to on. Observing it, there's a long blue led light when I press the defogger switch for the first time before it starts to blink. When I turn it off and later turn it on again, this no longer occurs. Not sure if its connected to what Im experiencing.

[mfb]

Colby,

What about having the OP2 just giving out a blue light and not logging after pressing the defroster switch? When this happens, I just remove and reinsert. I'll do a test log to see if it blinks then if it does, can confidently go on . I failed to log before because it was just stuck in blue led. Is there a limitation to the number of csv files generated? Thinking maybe there's a problem with it as it only started to happen when I reached 300 plus. What could be the cause of it getting stuck? Innovate LC-1 not ready or still blinking when I try to log?

[cboles]

I'm not sure what the problem is. Do you have a bad set of trigger conditions that could make the OP2 generate a large number of new files?

The OP2 looks through all of the .csv filenames when it first boots to determine what number it should use for the next CSV file. After that initial time penalty, there shouldn't be much effect to having a large number of files. It would start to take more time to traverse the FAT table for free clusters and such, but it really shouldn't be that bad. Does the problem go away when you delete some of the files? My plan with EcuFlash is to have an option to automatically drain the CSV files to log files directory on the PC whenever the OP2 gets plugged in.

Regarding the LC-1, since that is passive data, the OP2 never waits for it. The ECU data drives the logging process and the LC-1 data is just added to it as it comes, using the ECU logging timebase.

Colby,

What about having the OP2 just giving out a blue light and not logging after pressing the defroster switch? When this happens, I just remove and reinsert. I'll do a test log to see if it blinks then if it does, can confidently go on . I failed to log before because it was just stuck in blue led. Is there a limitation to the number of csv files generated? Thinking maybe there's a problem with it as it only started to happen when I reached 300 plus. What could be the cause of it getting stuck? Innovate LC-1 not ready or still blinking when I try to log?

[mfb]

The problem went away when I deleted the bigger csv files I have. However it seems to be a temporary fix. It previously did that already (hanging, blue light) and I didnt have much logs then. Im currently at 484 csv logs and majority of those are from my "checking" if its logging or not. I should see a blinking led before I actually trust that my next run will be logged. All my logs are activated via defroster.

Just now, I did a run but OP2 did not log. Upon parking, I see the blue light steadily on. Removing and reinserting it, I press the defroster button then there was a momentary pause before it started blinking again. It seems the op2 hanged. This is the third time it happened ever since I started using it. Can this be fixed?

Regards

[cboles]

Obviously it has to do with being unable to read or write the SD for some reason. The unfortunate thing is that when something like this is happening, the OP2 has no way of writing any error output to a log either. You might consider taking all of the files off and reformatting the SD card to see if that helps. You also might try another SD card. If it turns out to be specific to the card, but the card is not corrupt and otherwise seems functional, maybe I can swap cards with you so I can see what is happening.

The problem went away when I deleted the bigger csv files I have. However it seems to be a temporary fix. It previously did that already (hanging, blue light) and I didnt have much logs then. Im currently at 484 csv logs and majority of those are from my "checking" if its logging or not. I should see a blinking led before I actually trust that my next run will be logged. All my logs are activated via defroster.

Just now, I did a run but OP2 did not log. Upon parking, I see the blue light steadily on. Removing and reinserting it, I press the defroster button then there was a momentary pause before it started blinking again. It seems the op2 hanged. This is the third time it happened ever since I started using it. Can this be fixed?

Regards

[kewlboxer2]

Im having this issue as well. Its a 1gb transcend card. I have it setup for coolant temp on and rpm 0 off. Sometimes it will work sometimes it wont. green light flashes when i have the car off. when i start it up the blue flashes once, then its just red and green flashing(normal), but the blue never comes on to start the writing.

I think i have the card formatted for fat32. maybe i should try ntfs? or a whole new card

[mfb]

The initial blue light when i press the trigger (defroster) for the first time upon attachment to obd port will not log anything. The subsequent ones will log for sure. So what I do as work around is to press first and wait. Once i see it blinking, that's the time I will continue logging. However, sometimes this does not work as there is no writing that occurs.

Im using a transcend mini sdhc class 6 which is already fast. Only way to make it faster is to reformat this to use more bytes. We previously did this for Palm devices so cards will be read faster. I just dont know how it affects write speed.

Suggestion:
Can you make OP2 initialize the card whenever it plugs even without the trigger? Kinda like mounting the card the way smartphones use the sd card. My old Palm Centro does this so when I need to access, its always there. If its not mounted, maybe you can have one of the led (red) light up steadily to warn there is a problem. In this way, it will be ready for the trigger when its already triggered and logging can always occur.

[cboles]

NTFS wont work. Only FAT16 and FAT32. I'll need to look into what is going on. Unfortunately, I haven't seen any problems here.

Im having this issue as well. Its a 1gb transcend card. I have it setup for coolant temp on and rpm 0 off. Sometimes it will work sometimes it wont. green light flashes when i have the car off. when i start it up the blue flashes once, then its just red and green flashing(normal), but the blue never comes on to start the writing.

I think i have the card formatted for fat32. maybe i should try ntfs? or a whole new card

[cboles]

The card is already mounted right from bootup - it should be ready to go. Additionally, all of my file i/o after startup and reading the config file is queued to a 4k buffer that runs on a different thread. So even if there was some delay in writing (which there can be with SD cards when it needs to do and erase-before-write cycle), there shouldn't be any problem. That's why I went through the effort of queuing the file operations... Card speed shouldn't be an issue in any case as the logging rates are pretty slow.

It sounds like you have a repeatable case where the initial defroster trigger always doesn't work, right? Maybe you can post your config file and I can try it on my car. What car is this for?

The initial blue light when i press the trigger (defroster) for the first time upon attachment to obd port will not log anything. The subsequent ones will log for sure. So what I do as work around is to press first and wait. Once i see it blinking, that's the time I will continue logging. However, sometimes this does not work as there is no writing that occurs.

Im using a transcend mini sdhc class 6 which is already fast. Only way to make it faster is to reformat this to use more bytes. We previously did this for Palm devices so cards will be read faster. I just dont know how it affects write speed.

Suggestion:
Can you make OP2 initialize the card whenever it plugs even without the trigger? Kinda like mounting the card the way smartphones use the sd card. My old Palm Centro does this so when I need to access, its always there. If its not mounted, maybe you can have one of the led (red) light up steadily to warn there is a problem. In this way, it will be ready for the trigger when its already triggered and logging can always occur.

[mfb]

The card is already mounted right from bootup - it should be ready to go. Additionally, all of my file i/o after startup and reading the config file is queued to a 4k buffer that runs on a different thread. So even if there was some delay in writing (which there can be with SD cards when it needs to do and erase-before-write cycle), there shouldn't be any problem. That's why I went through the effort of queuing the file operations... Card speed shouldn't be an issue in any case as the logging rates are pretty slow.

It sounds like you have a repeatable case where the initial defroster trigger always doesn't work, right? Maybe you can post your config file and I can try it on my car. What car is this for?

The initial blue light when i press the trigger (defroster) for the first time upon attachment to obd port will not log anything. The subsequent ones will log for sure. So what I do as work around is to press first and wait. Once i see it blinking, that's the time I will continue logging. However, sometimes this does not work as there is no writing that occurs.

Im using a transcend mini sdhc class 6 which is already fast. Only way to make it faster is to reformat this to use more bytes. We previously did this for Palm devices so cards will be read faster. I just dont know how it affects write speed.

Suggestion:
Can you make OP2 initialize the card whenever it plugs even without the trigger? Kinda like mounting the card the way smartphones use the sd card. My old Palm Centro does this so when I need to access, its always there. If its not mounted, maybe you can have one of the led (red) light up steadily to warn there is a problem. In this way, it will be ready for the trigger when its already triggered and logging can always occur.

I hope you get to fix this as you always do. Please see attached LogCfg.txt

[adamw2]

Hi guys

I'm really struggling to get the 2.5mm stereo plug input working with the LC-1.

The LC-1 is configured, calibrated and the standard ratio is correct (gasoline, 14.7:1). Running the logworks software included with the LC-1 shows sensible AFRs (14.4'-14.8'ish at idle).

This is what I have in my logcfg.txt

paramname = mylc1.afr
paramid = 0x0102
scalingrpn = x,14.7,*

I have tried 0x101 as well and tried scalingrpn = x for both.

The figures I'm getting from the above should be between 14.4, 14.8 but I'm getting values from to 499.8 to 762.4.

ECUFlash version is 1.43.3000 and OP2 device firmware is 1.10.2996, J2534 API 04.04 and J2534 DLL version 1.00.2997.

Any ideas ?

Thanks
Adam

[LM_logger]

Do you have the type=inno line in cfg file above those declarations?

[adamw2]

Do you have the type=inno line in cfg file above those declarations?

Thanks!
Something has changed, but still no joy.
It's logging all zeros for mylc1.afr now.

Will check the settings in LMProgrammer and check out the AFR in Logworks to see if that has changed somehow.

[LM_logger]

Noticed also that your paramid is ok for lamda and multiplier but you've dropped a zero in the afr paramid when mentioned

; paramid parameter
; 0x0101 LC-1 #1 AFR
; 0x0102 LC-1 #1 lambda