Map sensor changes readings for no apparent reason

[dlenardu]

I've been working on a twin cylinder motor for a little while now. This is actually my second one that I have done but I seem to be having a problem when adjusting the VE tables on this unit. I'm not sure if it is something I'm doing wrong, a map sensor problem, or a software problem. I have a microsquirt with 2.89 embedded code. I'm using version .995.1 in tuner studio and on this motor I am using the GM 3-bar map sensor from DIYAutoTune. The problem that I am having is that the map sensor will change its readings for no apparent reason. It started off that I will make adjustments with the motor running and get the engine running really well say at about 3800 rpms and a map value of around 60-70 kpa but as soon as I hit "burn" the map values will jump up to 90-100 kpa and run like crap without changing anything else at all. Then I can change another cell and hit burn again and the map value will drop back down to the 60-70 kpa and run great again. The thing is if I don't change another cell and hit burn again and get it back to the 60-70 kpa value that I had it all tuned at it throws the entire ve table off and the machine doesn't run well at any rpm. Now it does it constantly. I can get the machine running really well and then for no apparent reason it starts running like crap again. I thought for a while I just didn't have it tuned well, I used the same tune that I had on my other machine and then adjusted it for this machine. Now I see that I am having an issue with the readings of the map sensor and that is what is throwing the tune off. I installed another 3-bar map sensor and it did the same thing. I tried to reflash the embedded code but it still did it. I am completely at a loss. I'm attaching the msq and a log. When you look at the log start looking at time 1290 you will see everything is steady and then at time 1300 the map sensor jumps to a reading in the 90-100s then at around 1376 it jumps back down into the 60s-70s and everything starts running normal again. The throttle is fixed so there no fluctuating there. The rpms change because the map sensors starts reading incorrectly. As I said in the previously I installed a new map sensor and it still did the same thing. It did it other times as well I just remember this as the longest time. At first it seemed like it was only doing it when I made a change to the VE table and then hit burn, sometimes it did it and sometimes it didn't, now it seems to also be making this change while running. It will be running great one minute and then run bad later.
Thanks in advanced

[Matt Cramer]

This sounds like a firmware corruption issue. Try reloading the code, but do not reload the old MSQ - export your VE and spark tables, and copy the rest over by hand. Does the problem still occur, or does that fix it?

[dlenardu]

Thanks Matt,

I will give this a try and see what happens.

[dlenardu]

Matt,

It worked for about 6 hrs of run time and then it started acting up again. I hooked the laptop to it and the map readings were off. I changed a couple of cells on the VE table and hit burn and it went back to its normal readings. Changed another cell and hit burn again and the map readings jump high again. Could there be something wrong with my embedded code file? When I reflashed the code into the microsquirt and then loaded the tune my hand it ran great, I could change cells in the VE table and hit burn and everything would stay like it should. The machine ran great and gave no problems but after we had about 6 hrs of run time it all started again.

[grippo]

In looking at your datalog around 1280 to 1320, you will see that the MAP going nuts is related to your trigger+/- column. The errors count down (missing wheel pulses) and then they stabilize and map also stabilizes. This may mean there is a noise in the VR circuit that comes and goes. Also the trigger+/- is extremely high - this number should stay very small - mostly there is just some small changes at startup and when you cut off the engine.

Your msq appears to be ok, but keep track of it.

[dlenardu]

In looking at your datalog around 1280 to 1320, you will see that the MAP going nuts is related to your trigger+/- column. The errors count down (missing wheel pulses) and then they stabilize and map also stabilizes. This may mean there is a noise in the VR circuit that comes and goes. Also the trigger+/- is extremely high - this number should stay very small - mostly there is just some small changes at startup and when you cut off the engine.

Your msq appears to be ok, but keep track of it.

Grippo,
When you say the trigger +/- column are you referring to the task masking signal? I have not adjusted anything for the trigger +/- columns I left that at the default settings. I'm not sure where the noise is coming from. Can I put a filter on the VR line somewhere?

[grippo]

The trigger+/- is not something you have control over. The code keeps track of the time between teeth, and if one of these times is out of whack, either way shorter or way longer than the previous time, then it counts up for an extra tooth or down for a missing tooth.

It doesn't appear that the long/ short tooth counts are causing any loss of synch because the rpm never goes to zero and the code is capable of correcting for one missing/extra tooth as long as there are not 2 or more consecutive ones. So I'm not sure this is coming from the VR sensor. It appears to be more related to the fact that you have the laptop plugged in, or if not that, there may be some flaky connection, maybe in the map sensor, that comes and goes. When map jumps around like that, the fueling will jump around and this will definitely make the engine run like crap. If you drive around without the laptop connected, does any problem occur ?

[dlenardu]

If you drive around without the laptop connected, does any problem occur ?

Yes, I reloaded the embedded code and then reinstalled the .msq entering everything back in by hand (as Matt suggested) instead of loading the .msq file. The machine ran great for about 6hrs and then it started acting up again. I then connected the laptop to it to see what it was doing and saw that the map was reading high again. I changed a cell in the VE table and hit "burn" and the map reading dropped back down change another and it will jump up again (it doesn't do it everytime but very close). I have also noticed that If I change anything in any of the settings it will also cause the map reading to jump. I soldered all of the connections and I have tried wiggling the wires at the map sensor but I can't seem to get it to change by doing that, I tried another new map sensor and had the same results.

I just looked back at datalog and notice that at about 1295 the tachcount drops to zero and then the map sensor starts reading high. What does it mean when the tach count goes to zero and what can I do about it?

Also I looked at a datalog of another machine that I did that is identical to this one and noticed that the trigger +/- column on it did not move much at all. I noticed that it might move up or down 1 throughout the entire dataloog where this machine the trigger column runs up and down constantly. BTW this other machine runs great and has had no issues. Can the air gap between the vr sensor and the trigger wheel cause this?

[grippo]

The tachCount is set to 0 at synch or resynch and then incremented on every tach pulse thereafter. There are only 2 lines of code for this. The count will overflow at 65535 and go back to 0, but what I see it doing is ramping up as it should but when it gets to around 30000 it resets to 0, then it counts up to 5000 and again resets to 0. But the processor itself is not resetting, because secL would then go to 0. So this means you are losing synch due to noise in teh VR sensor input. But what is puzzling is that this usually shows up as rpm dropping to 0 very briefly.

Yes the air gap can cause a problem, but it usually shows up at low rpm where the signal is naturally weak. The Trigger+/- definitely should not be a very high number,

If you can get a second unit from another car and load it with the same msq I would try that to rule out a hardware problem. Meanwhile I will test the msq on the bench and see if there are any problems, but this really looks like a hardware issue, either with the car/ VR sensor or the microsquirt.

[dlenardu]

Grippo,

I just got through converting the 3rd machine. All of three of these are identical units and I have used identical components, wiring layout, etc. The third unit that i just finished, I loaded the msq into and test ran and the unit runs great. The trigger +/- column doesn't move until the tach count gets to 65535 which is when the tach count resets, which is normal. The first one and the third one run great, but this second one is giving me a headache. I would say that it was something that I did wrong but since the first one and third one run great and I did everything the same then I'm hoping its not me. Maybe there is something wrong with the vr sensor? I can take it back and get a another one and then recheck my connections, but do you think it is safe to say that it is in the VR circuit somewhere?