MicroSquirt.com read only forum (Jan.15,2018)

I'm using 2.684 code, it was slightly modified by Al so I could have a longer fuel pump prime before cranking to build fuel pressure. Anyhow I've a small query...

When setting the decel amount to 100%, to in effect not remove any fuel upon decel, i'm finding in the logs that decel is actually being triggered and between gears it's dropping the PW to ~1.0ms (see screenshot of log)

I'm primarily using X-Tau for AE now but left small values in the normal TPS/MAPdot style AE just so they dont feel left out. Is it just me or is anyone using this version of code or greater having similar issues with decel?

It's very noticeable with a manual trans car too!

[
There are two settable decel values. One is the original non-Xtau value and the other is a value that modifies tau when you are in decel mode (tpsdot < -tpsdot_thresh). I believe your drop in pw is coming from X-tau (you shoul;d be able to confirm from the data log which will show both). To reduce it, you need to reduce the XTDecel factor to say 50%. This will reduce tau NOT the pw, so the effect will be to make the valley int the pw curve into just a small dip and the lower you make XTDecel the smaller the dip. It will only come into play on decel. This is something that should be made clear in the documentation if it isn't already in there.

That said, if your table values of tau in the rpm/ map region are already 1, then the XTDEcel won't do anything because tau =1 is the lowest you can go. This is because the X-tau algorithm divides by tau and you can't divide by 0. What I have done in v2.8x code is to continue running the X-tau algorithm as if tau were 0, but when it is 0 I don't apply the correction. So everything should stay smooth when tau goes back up > 1.

Botton line - try XTDecel = 50 % and see if it helps. If it does you can optimize it up or down a bit.

I'll give 50% a try tonight. I remember when first upgrading to the 2.684 code I had similar issues but remember setting both X-Tau decel and TPSDQ to ~80% to fix it.

On another note, in this datalog, it shows X-Tau dropping/spiking to 0 all the time. I had thought it was a map-spike at first, but my map is rock solid. Is it a normal occurance, i.e. do others experience it in their logs too?. Before I start hardware fault-finding...

Cheers Al.

I tried all sorts of values in TPSDQ and XTDECEL. From 0% to 30% to 50% to 70% to 100%. All values in XTau DE seem to deliver the same result. If you would like a datalog, let me know.

Now. I thought back to the days where the car would rip my head off and turned X-Tau off and hello! It ripped my head off again! No sign of lean out through the gears right up to shifting at 6200rpm.

Good news is AMC works pretty well on 2.684 so i'll leave it for a few weeks and see how far my VE is out, also leaving XTau disabled until you get a chance to have a look at it after the missing tooth dilemma with 2.686+. From having used XTau in the car for weeks, it definately cured the lean tip in. Would it be possible to only have XTau do AE, or DE or both?

I can go racing atleast with the oldschool AE!

Cheers
Kris

krisr wrote:From having used XTau in the car for weeks, it definately cured the lean tip in. Would it be possible to only have XTau do AE, or DE or both?

I can go racing atleast with the oldschool AE!

Cheers
Kris

I'm guessing the reason XTDecel doesn't affect things is because tau needs to be < 1 in the region in which you are experiencing the problem. This isn't possible in the present code, but in the next code (v2.8x), you will be able to set tau to 0 at any point in the table. Also, if XTDecel is 0 and you are decelerating, then the X-tau fuel cut can be eliminated that way, but the X-tau effect will still be there when youi are not decelerating.

Kris,

I looked at your datalog. You don't have a hardware problem but there is something going on. If you look at the first 2 XTau = 0 points around lines 200 and 600 you will see Timingerr, IACstep and mapdot going nuts. These have absolutely nothing to do with Xtau and your PW, which does, is remaining ok. I suspect this is something going on with MT jumbling data or MS2 jumbling data going back to MT. Lance and I worked out problems like this early on. Some of it was due to compiler mishandling of integer multiplies, but I think we have all of these sorted out, plus these only occurred when you were actually doing something like hard accel/decel = here nothing is going on.

If Lance reads this he might have a better recollection than I do and might be able to tell you the best .ini and MT files to use.

krisr, Al;

My recollection is vague as well, but I'll dig into my notes, etc. I'll post back here in a bit. I'm guessing that the ini file isn't quite right, and I'l check it out.

Lance.

Thanks guys. No rush. The car is now driving like a scalded cat with the original AE bins.

Lance, the .ini i'm running is the original one you emailed me when I started testing 2.683 if that helps. I can shoot it over to you either way.

I suspect your suggestion of MT 'jumbling' data to be correct. I had a funny instance on the weekend when burning some changes to MS, power cycled the car and my CLT/IAT thermistor calibrstion had been thrown out the window (registering 0* for either sensor). I reset the thermistor calibration, reloaded the O2 calibration table, burnt my old MSQ file and it was back to normal.

Baud rate is 115200, interwriteDelay = 5.

Kris