Communication Errors with MS3 and MShift

[mill383]

I am also having a similar problem, related to TS to MS3pro comms. I was fat, dumb and happy until I started seriously digging into tuning and noticed Time Gaps in the data logs. Actually noticed it after reviewing datalogs from several 1/4 mile passes.

So I learned about RunTime Data Rate gage on TS, which is erratic with engine running. Am using BT adapter from EFIAnalytics. USB is also erratic. BT RunTime Data Rate hovers around 13 samples/sec. With engine not running, Protocol Stats reports all zeros (except Candata and OkCount, which stick together). When engine is running, then I get overrun Counts incrementing somewhat erratically, about once every 5 secs. Also I see protocol error setting about the same time overrun increments. I've isolated Alternator (disconnected it), no battery charger, Laptop inverter is off, bypass MSD6A box (trying to minimize EMI). All MS3Pro grounds, MSShift, MSEgt grounds go the same location on the head. The controllers have a dedicated power wire to the ignition switch. All MS wiring greater than an 1" away from sparkplug wires. MSD spiral wound wires. When I drop Rate to 5hz, this gives the impression of working better, but just decreases the chances of it hitting. It still has interrupts if you watch it long enough.

What variables can I look at to see if this is a CPU reset issue?

msq and datalog attached.

Thanks,
Dave

[mill383]

When using BT, the USB cord is unplugged from laptop.
When using USB, I leave the BT-to-232 converter attached to MS3Pro (and powered) but unplug the dongle from the laptop thus breaking the connection. Whilst troubleshooting, I did try removing the BT-to-232 converter completely, but USB still had the time gaps and unstable runtime. I’ll try to get that other data tonight or tomorrow.

Dave

[mill383]

Two TunerStudioAppDebug.txt files attached, one using USB, one using BT.

USB was all over the place, with drops, at max rate, about 40 hz.
BT was turned down to 5hz and seamed to work ok.

Let me know if anything looks odd.

[LT401Vette]

It looks like you are getting a a Protocol over-run on the requests sent to the MShift.
What is sent looks Ok.

I would guess that if you click "disable runtime reads" from the MShift in the Project Properties on the "CAN Devices" tab, you will get good communications with the ms3-pro.

what version firmware is on the MShift?

[mill383]

Am running MShift version 4.144.

I'll try "disable runtime reads".

[mill383]

Thanks for the reply.

Before trying what you mentioned, I did a baseline with car as is. Powered up the system (eng not running) with data recording, then started engine. This is the data "USB1". Sometimes I get a couple "Protocol Error" when engine not running, but usually its pretty quiet. But when I start the engine, it gets pretty noisy, lots of Protocol errors and subsequent time gaps in the data logs. Max data rates were ~40hz.

Then I tried checking "disable runtime reads". I don't like doing this, because I lose my ability to data log transmission parameters and real-time gages like "line press" and "trans temp" and "eng oil press". But I tried it. It made no difference. This is data "USB2". Max data rates went thru the roof, ~100 hz.

I then tried disabling MShift CAN bus
Tools > Can Configuration (MSHift) > CANbus disable
This too made no difference.

I then tried changing "Get all Vars" to "Get only required vars".

Any other ideas?

LT1 opti-spark engine, MS3pro pre-1.3.3 beta 2 code.

Dave

[LT401Vette]

If the engine running is making a good difference, it may be simple old noise.

If you have a USB to RS232 cable, I would try connecting that to the DB9 instead of using the USB port. That is much more resilient to EM noise.

[mill383]

I tried a serial to USB adapter that I use for the MShift and microsquirt units.

It acted the same way, with time gaps in the data logs. More pronounced when engine running, but still sometimes occurs when engine off, just like with built-in Pro USB or using BT. msl attached.

Then to trouble shoot the noisy power-bus theory, I put some caps across the fuse that powers the MS3pro (also in parallel with MShift). I used a 2200 uf cap, one 0.1 uf, and two 1000pf ceramic caps. It didn't help.

Any other ideas?

Dave

ps, I am in the process of assigning MShift parameters that I want to monitor and log to Generic Sensor Inputs via CAN. Am having pretty good luck with that. When I'm using runtime data for MShift parameter monitoring, BT rate is a slow 13 hz. When I disable MShift runtime, it jumps up to 25 hz. That's goodness. I'll be adding a TinyIOx soon, so this is good practice.

[LT401Vette]

If you open the ini in a text editor and turn off tsWriteBlocks, that may fix it.

Open the file:
[YourProjectFolder]/projectCfg/mainController.ini

Search for the line:
tsWriteBlocks = on

either comment that out or change it to:
tsWriteBlocks = off

I believe there was a discussion earlier where sending the data to the MShift too fast was causing a problem, this may be what you are seeing. Turning off tsWriteBlocks will slow the speed TS sends the data.

[mill383]

Tried the "tsWriteBlocks = off", no luck. Noise remains the same. Tried it both maincontroller ini and also MShift (in case there was a typo).

To recap, noise (protocol error and time gaps in data log) show up more often with the higher cut rate data streams, such as USB. Built in MS3Pro USB and external 232 converter act the same. BT drops are less frequent, but so is data rate.

Would reloading firmware into MS3Pro make any sense?

Am curious what all this means, from the TunerStudioAppDebug.txt. CRC mismatch sounds like the code wasn't loaded correctly.

9/27/14 5:50:24 PM :Info: Communicating with MS3 pre-1.3.3 beta 2 20140720 21:09GMT (c) JSM/KC ********
9/27/14 5:50:24 PM :Debug: Reading ECU Data, 0.0 complete
9/27/14 5:50:24 PM :Warning: CRC Mismatch!!!!
9/27/14 5:50:24 PM :Info: CRC from controller page 1:x9F x8D x2E x43 ...C
9/27/14 5:50:24 PM :Info: Local Data CRC for page 1: xF0 x99 x91 xA2 ....
9/27/14 5:50:24 PM :Info: Opening port: COM3
9/27/14 5:50:24 PM :Debug: Port not valid: Unable to open port: COM3
Please check your Communications Settings.
9/27/14 5:50:24 PM :Debug: Read page time: 141ms.

[LT401Vette]

I doubt reloading the firmware would make a difference.

The CRC errors are just on the tune data. It is common to get those on some pages during interrogation. It just tell TS it needs to refresh the tune data on that page.

We set up a MS3 with an MShift here and it seems to be working fine.
We are now switching to the same firmwares you are using.

If you can send/post a Project Archive, it will help us best reproduce your current setup.

[mill383]

Phil,
How best to send this to you? I removed all but one msl, removed all msq's and still the project is 1,270kb. Upload limit is 716kb.

Regards,
Dave

[LT401Vette]

When creating the archive there is an option to not include log files, but it can still get big.
Email it to support at efiAnalytics dot com.

[mill383]

Phil,

Ok, email sent.
FYI, I tried reloading the firmware into MS3Pro, pre1.3.3beta2. Also tried 1.3.2a. Same issues were observed.

Dave

[LT401Vette]

Ok, unfortunately we are out of the office on travel he next 2 days. I'm sorry for the delay.

I am more concerned with the version of firmware you are running on the MShift. While trying to reproduce your set up, it looks as though that version was pulled down. I don't know what the reason was at this point, but generally old versions are only removed from the download site if there is a serious problem.

[jsmcortina]

FYI, I tried reloading the firmware into MS3Pro, pre1.3.3beta2.

I've spent a number of hours testing on the bench with a CAN sniffer and debug code and I think I may have found something. Please PM me your email address and I'll send you a test code to try.

James

[mill383]

James,

Tonight I tried the MS3Pro.s19 you sent. No luck.
For kicks, I tried loading up a newer version of MShift, 4.145, a released version. No luck, same issue as with 4.144 that I was using before.

Regards,
Dave

[mill383]

Hi James,

I did an interesting experiment tonight. I dug up my spin-tron that I used during the project's bench testing. It is a hacked up opti sensor driven from a variable freq drive.

DSCF9846 (Large).JPG

I observed the same protocol error and time gaps in the datalogs as when the engine was actually running. What is interesting about this test is ignition was off, injectors were off, no battery charger, using a different desktop computer connected via BT. The only things powered up on the car were the megasquirt units (MS3Pro, MShift, CAN-EGT, TinyIO). As an experiment, I also turned off idle air stepper motor (in case that was generating noise). That wasn't it either. I noticed sometimes it takes 30 sec to a minute of running before the errors start. Sometimes they happen right away.

I will email you a log file that includes an RPM sweep up to 7000 rpm and back down.

Update:
Did some more testing tonight. Some times it can take 3-5 mins of bench running to get the protocol errors to start happening, but once they do, they keep happening. The time before the errors start seems to be random. James, this may be why you thought you found a fix last time. Tonight was the first time it took so long, though. Maybe due to the more constant rpm signal from the spin-tron, instead of an actual running engine? And for what its worth, Lost Sync Coutner and Reason remained 0 the whole time.

Dave

[mill383]

Just did a test where I pulled the fuses for the CAN devices (MShift, EGT, Tiny) and removed these devices from the project all together.
With nothing but the MS3Pro connected to TS, via BT, the protocol error is still there. This was with 1.3.3 beta 5+ SW.

I vaguely remember seeing protocol error during initial bench testing, but honestly, I thought it was declaring a trigger error, related to opti. Didn't understand protocol error is comms error between TS and MS. I am going to load the original firmware that came with the MS3Pro (V1.2.4) and see what happens.

Dave

[jsmcortina]

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