Communication Errors with MS3 and MShift

[mill383]

Just did a test where I loaded V1.2.4 (what came with MS3Pro) and it has the same type of protocol errors, same frequency of error, when opti-spark is spinning (bench test). No CAN are devices connected. I've tried with "writeblock = off", with no effect.

Could it be a MS3Pro hardware related failure? I am also having issues with the SDcard not being recognized.
http://www.msextra.com/forums/viewtopic ... 31&t=55797
To get the SD card issue fixed, I plan on sending it in for troubleshooting this winter. But would like to get this protocol error figured out so I can get out to the track for the last 3 test-n-tune Wed nights of the year.

After we get this protocol error figured out, I do need to reactivate the CAN devices, though I can afford to check "disable runtime data" for each CAN device, as I've figured out to input trans and Tiny parameters I need for datalogging via the CAN Parameters/CAN ADC definition. Of course, this gets filled up pretty quick when using 8 channels EGT, 4 channles from Tiny, leaves just enough for some vital trans parameters.

Thanks for your guys help on this....

Dave

[LT401Vette]

If you are connected to the MS3-Pro via the DB-9 and n FTDI based RS232 to USB adapter, yet still getting protocol errors (on thee bench no less), that does help simplify. It seems it is either specific to some setting you have or a hardware issue. Hardware issues on the ms3-pro itself are rare though.

[mill383]

Phil,

I just tired it again, comms via DB-9 RS-232 port and FTDI based converter (same one I use on my microsquirt project, without issues) and it too is showing frequent protocol errors. Doesn't seem to matter if it is BT, buit-in MS3Pro USB, or FTDI converter. This is with V1.2.4, and no CAN devices connected. No battery charger, no 120VAC inverter laptop running off of battery, etc.

I started to take a datalog and appdebug log to post, and came across the Protocol Stats screen. I watched it real-time, while the bench-opti (spin-tron) was running. I noticed that when the protocol error occurred, the overrunCount number incremented by 1. I took a screen shot of it.

Other files are zipped up and attached too, for reference. Datalog will show the frequency of the time gaps (Options-->Fill Time Gaps), which seem to occur when the protocol error/overun happens.

Thanks,
Dave

overun.jpg

[jsmcortina]

How does TunerStudio adapt to over-runs? One response would be to add an inter-character delay to reduce the chance of over-run.

James

[LT401Vette]

The protocol error is best answered by Phil.

I have been discussing the other issues with the team and it could be that you CAN bus is near capacity. Jean and I have some possible thoughts on this, but it could take some time.

James

It pauses for a period to make sure all bytes are clear, then retries the command.

In this case, he has tried setting tsWriteBlocks to off, that automatically moves the interWriteDelay to a min of 2-3ms if using the default RXTX. Which I believe he is.

[mill383]

Here is some more info.

I have been trying to prove it is not related to the Opti trigger (or it is). So as a bench test, I set it up for fuel only, non-sequential, tooth trigger, dual wheel, 4 teeth.
This was able to "trick" MS3 to still use the spinning opti, as if it was just a 4 tooth wheel, and actually gives the same rpm as the normal Opti trigger setup.

Interestingly enough, the overruns were substantially reduced, but not entirely eliminated.

Back-to-back tests at the same 2600 rpm and 5 mins of run time resulted in this:
Opti triggered: 64 overruns
Faked-out toothed wheel: 2 overruns

Seems kind of interesting...

For what it's worth, this was done using BT comms and battery charger on, tswriteBlocks commented out, no CAN devices.

Dave

[jsmcortina]

For a true "non-Opti" configuration use "Basic Trigger"

How does it behave using a direct serial connection (USB or USB-serial) instead of the BlueTooth.

James

[mill383]

2300 rpm, 5 minute run time...

Using direct serial connection:
Opti triggered: 83 overruns
Basic Triggered: 1 overrun

Using built in MS3Pro USB, everything else the same:
Opti triggered: 93 overruns
Basic Triggered: 0 overruns

To reiterate, when then spin-tron is not spinning, no overruns occur.

[mill383]

Bump...

Any more thoughts on this?

Just completed another test.

Basic trigger config, using BT comms, run time 15 mins, 0 overruns.
Opti trigger config , using BT comms, I get about 7 overrun counts per sec.

[jsmcortina]

This looks like something problematic specific to the OptiSpark code that is blocking serial interrupts. It is on my list to investigate further this week. (I could have sworn I'd replied already, but seems not.)

James

[LT401Vette]

In the mean time, it seems if you slow your comms, that should resolve the Protocol errors.

In your mainController.ini, set
tsWriteBlocks = off
writeBlocks = off
interWriteDelay = 4


That will slow your comms a good bit, but really _should_ prevent the protocol errors.

[mill383]

James, Phil,

Thanks for the replies.

Curiously enough, the ini changes as listed made the BT connection unusable. It refused to load, even with opti not spinning.
I experimented with all combinations (on/on, off/on, on/off, 0,1,2,4, etc) and only the regular config on, on, 0 worked the best for BT, spinning opti.
For USB config, the best that worked was off, off, 2, but it still had occasional protocol errors and, this time, underrunCounts.

I appreciate that the opti-triggering crowd is probably a small group of the MS3 community, and appreciate you looking into a fix.
I'd really like to keep it sequential so I can experiment with injector timing and injector trimming in the future.

Dave

[LT401Vette]

How about with USB.
I would appreciate 1 step at a time, just using a USB to RS232 cable to see if that has the desired effect.

[jsmcortina]

I can confirm that I'm seeing overruns when running Optispark on the bench. This is not expected or acceptable. I will dig into it further this week.

James

[mill383]

James,
Thank you for the update.

Phil,
I took a short log file using USB to serial adapter and the settings you suggested.
Underruncount increments about every 12 secs. Interestingly enough (to me anyhow, cause I don't know what all this means) is I do not see a timegap marker in the datalog. After seeing the Protocol Error and the underruncount increment, I tapped the TPS as a marker. MSL is attached.

Dave

[jsmcortina]

I'm going to rewind on my previous comment a little....

I have investigated this issue and part of the issue is that the processor is pretty busy running the engine at higher RPMs with high tooth count wheels. Handling serial communications is correctly a lower priority. It is preferable to have an occasional overrun than to impact engine operation.

So, they key is to minimise this and for TunerStudio to handle it gracefully. (It seems fairly good to me already.)

The original issue that was being reported of CAN passthrough problems is likely a different issue that requires further investigation. I have already done some work and the test code I sent out improved the situation in my testing. I have some more ideas to test also.

James

[LT401Vette]

What Driver are you using in the communication settings?

I'm surprised it is still getting some overruns with tsWriteBlocks off.
With tsWriteBlocks turned off, you can now adjust the interWriteDelay. Try setting it to 3,

interWriteDelay = 3

see if that eliminates all overruns, if not, try raising it a bit more until it is gone.

[mill383]

Phil,

With the tsWriteBlocks off, I get underruncounts, not overruncounts.

Screen shots of my com 1 driver, used for serial USB converter.

driver.jpg

driver2.jpg

driver3.jpg

[mill383]

James,
To aid in trouble shooting, here is a sensitivity study of the effect rpm has on underruncounts (am running latest config from Phil).

CAN devices are connected and communicating.
Data below was taken by stopping a stopwatch every time underruncount increments:

Opti rpm = 2300 rpm
lap 1 = 00:11.55
lap 2 = 00:23.02
lap 3 = 00:34.45
lap 4 = 00:45.85
Approx every 12 secs, underruncount incremented.

Opti = 4000 rpm
lap 1 = 00:11.67
lap 2 = 00:23.24
lap 3 = 00:34.79
lap 4 = 00:46.48

Opti = 6000 rpm
Lap 1 = 00:22.96
Lap 2 = 00:34.44
Lap 3 = 00:57.14
Lap 4 = 01:20.19

Opti rpm = 1000 rpm
Lap 1 = 00:45.53
Lap 2 = 00:57.15
Lap 3 = 01:42.57
Lap 4 = 01:54.35
Lap 5 = 02:06.16
Some what random...

Opti rpm = 200 rpm
Lap 1 = 00:23.77
Lap 2 = 00:34.60
Lap 3 = 00:57.78
Lap 4 = 01:20.50
Delta's either 11 or 24 secs

The problem seems to be fairly independent from rpm.

Dave

[mill383]

Phil,

Here is another screen shot for the driver. Anything look out of place for the driver?

driver4.jpg