Optispark Trigger Option appears to cause Overruncounts

[mill383]

This is an old problem I've been chasing, on and off, since last Summer, but am just getting back to it. Over the winter break, the MS3Pro had been back at the OEM getting reworked to get an SD card issue fixed, which it is now.

Original thread:
http://www.msextra.com/forums/viewtopic ... 9&start=40

I wanted to start a new thread, in hopes of getting other Optispark (Opti-spark) users to see this, possible duplicate the issue, and perhaps achieve critical mass on resolving the issue. Or perhaps prove this is a unique issue with my setup. My project is as follows:

1994 Z28 Camaro, LT1 engine
Factory Opti-spark (65K miles)
This is a drag car, not a daily driver
MS3Pro, current SW version 1.3.4
Otpi-triggered, Sequential fueling
Single ignition coil, still using the opti as the distributor
Opti module is powered by same 12V that powers Ms3Pro
Lo and Hi Res Opti signals are pulled up to sensor 5V source thru 1K ohm resistors, soldered directly to MS3Pro board

This started out by noticing data drop-outs in the log files while reviewing data from 1/4 mile passes. The drop-outs showed up in the MegaLogViewer as vertical yellow lines in the strip chart. But to see these lines, first you need to go to the "Options" tab and select "Fill Time Gaps". Then the yellow lines will appear where data is missing, due to a comms issue. I determined these time gaps were corresponding to when a "Protocol Error" would flash on the TS display, as well as incrementing the "overrunCount" value. This value is viewable by selecting "Tools" then "Protocol Stats" in TS. Normally the only thing incrementing in this window is "canData" and "okCount". But with engine running (i.e. optispark spinning) then I get the "overrunCount" incrementing also, at about a 0.5 to 1 hz rate. To rule out electrical noise I have duplicate this behavior on my bench-top Optispark, with injectors and ignition coil depowered. I also depowered the IAC to rule that out. This issue does not seem to be sensitive to different communication methods. It happens on RS232 (via usb adapter), on the buit-in USB MS3pro interface, and on Bluetooth. It happens on a laptop, on a desktop, and on a Raspberry Pi2 running a Linux version of TunerStudio. As long as the opti is spinning, these counts occur.

Now here is where things get interesting...

To further isolate this to the optispark interface, as a bench test experiment, I tried setting up my trigger as a Basic Trigger. This was simple enough to do, under Ignition Options, change Spark Mode from Opti to Basic Trigger. Then under Basic, Engine and Seq. Settings, turn off Sequential. Problem goes away. "OverrunCount" never increments, and speed is rock solid (as before) through the full operating speed range. To prove to myself the basic trigger is using the Low-Res signal, I disconnected the Hi-Res signal, and it ran just fine, in basic trigger mode. So the code must be triggering on the end-of-slot of the Low-Res shutter windows, where there are 8 equally spaced edges. Makes sense. Obviously, batch fuel control is not the desired solution to this problem, as well as giving up all the other nice sequential features (individual fuel trimming, etc) that come with the MS3 system.

This proves to me that there is an issue, in the MSExtra software, with the Optispark decoding algorithm that is some how affecting serial communications. Generally, it is not speed dependent. It occurs at all speeds I've tested, 0 to 7400 rpm. Some speeds seem to be more sensitive then others (3000 rpm for example) where the counter increments at a slightly faster rate.

So, with all that said, are there any other Optispark users observing similar drop-outs with their laptop-recorded datalogs?
Anyone with a bench top Optspark able to duplicate this on their setup?
For those optispark users, please reply to this thread whether you see this issue or not.

Thanks,


This shows the overrunCount incrementing, and I just caught the Protocol Error flashing on with the screenshot.

counts.jpg

This shows the Opti Trigger settings. Note Ign Input Capture has to be set to Falling Edge, opposite from what MS3Pro manual says.

trigger.JPG

This shows the Basic Trigger setup, that solved the problem.

basictrigger.JPG

[mill383]

Picture of my Optispark bench test setup consisting of a cannibalized Opti driven by a 3-phase induction motor powered by a variable frequency drive. Speeds are controllable from 200 to 7500 engine rpm.

Picture of the high res signal disconnected, when I was running it in Basic Trigger mode.

[jsmcortina]

A few changes were made in the pre-1.4 firmware to somewhat mitigate this issue, but fundamentally the Optispark and Nissan CAS generate a lot of processor interrupts and serial overruns will occur.

James

[mill383]

Update.

I tried the latest ms3-pre1.4beta12 code. Ouverruncounts still increment on TS, as it did with the 1.3.4.

I did a data recording test, with rpm running at a constant 3000 rpm. I blip throttle when I see the protocol error as a data marker.

When I review the data, I no longer find time gaps. No vertical yellow lines. And the data appears to be continuous. So... not sure what changed, but I'll be happy if this continues to work on a running engine. I'll update when I get chance to try this on a running engine. Probably a month or 2 out from engine crank.

Update:
Just did same test using latest release version, V1.3.4. Glad to report I had same results as with the the beta. No more time gaps.
I still get the annoying flickering yellow "protocol error" indicator, but I can delete that if it really bugs me.

So maybe your changes to CAN comms (since pre-1.3.3) is the difference. And/or TS is handling it better.

Thanks for the continuous improvement!

[jsmcortina]

Older versions of TunerStudio were causing gaps in the data if there a was an overrun. This was fixed recently.

James