MS2/extra alpha 3.3.0b (2012/02/27)

[piledriver]

Having what appears to be a (new) repeatable glitch at ~5300 RPM, but I'm still trying to see if its some new VE table issue or setting.
(I don't usually run it that high, that's about 75MPH in third)

What exactly is the "engine" variable?
It changes in exact sync, along with step functions in PW and gammae. (also, what's is gammae, exactly)
I don't recall ever noticing it change before.

(The logs are very large from my commute, will grab burst log and post if it isn't something silly on my end)

Changed revlimiter from CLT based to 6000 soft/6200 hard to Tshoot this just in case, no effect.

[piledriver]

same issue after fattening up ve map and reshuffling the rpm columns, new issue with this FW

msq

2012-03-13_06.24.36.msq

repetitive pw drops at >5200 rpm.

(84.85 KiB) Downloaded 17 times

burst log

2012-03-13_06.24.50b.msl

(459.51 KiB) Downloaded 17 times

[gslender]

same issue after fattening up ve map and reshuffling the rpm columns, new issue with this FW

msq

2012-03-13_06.24.36.msq

burst log

2012-03-13_06.24.50b.msl

To be clear on the issue, you are talking about the PW taking a dive in about 3 random points - down from ~13ms to ~9ms.... is that the issue?

[pit_celica]

It seems to coincide when MAPdot oscillation are greater than MAPdot enrichment. I know the symptom is a PW enleanment, but I think you should try to remove the MAP accel and TP accel by setting mapdot and tpsdot treshold at a very high value. At least, it will remove the accel variable.

It's interesting how the MAP signal is getting more noisy from 4000 to 5500 RPM. This noise is more hard from 5200 to 5500. The best way to look at it is looking MAPdot in the log. It's pretty interesting.

Sam

[piledriver]

Yes, sounds/feels like rev a limiter but it's not.
I'll turn up the thresholds and see what happens tonight.

I have some much better logs showing it, but they are an hour long.

Just to close the loop, raising the thresholds resolved the issue, the new sampling code is going to require reworking a few things, but will be worth it in the end easily.

[gslender]

It seems to coincide when MAPdot oscillation are greater than MAPdot enrichment. I know the symptom is a PW enleanment, but I think you should try to remove the MAP accel and TP accel by setting mapdot and tpsdot treshold at a very high value. At least, it will remove the accel variable.

It's interesting how the MAP signal is getting more noisy from 4000 to 5500 RPM. This noise is more hard from 5200 to 5500. The best way to look at it is looking MAPdot in the log. It's pretty interesting.

Sam

It is defintely a MAPdot decel event. Caused by the map AE code.... I think Ken will need to fix this and probably could be resolved by reducing (or removing) map AE.

With TPS smoothing in the next mod I've released, you could probably just rely on TPSdot AE.

G

[gslender]

You have decelfuel amount set to 70. This isn't a good value and would probably be the reason you have this PW starving.

Change to 100% so that it doesn't decel fuel at all, and I'd recommend against going as low as 70%, but of course with MAPdot swinging like it is, then I guess the issue is why is MAP averaging behaving so poorly?

At least the issue is solveable - switch off MAP averaging and go back to the previous MAP sampling mode.

G

[piledriver]

Thanks for the quick read on this, pulls to 7k clean and fat with the threshholds raised.

I actually turned the thresholds up to 300 and it's gone, card drives much better too.
I drives strangely well for having accell amost turnrd off, do have eae on.

I haven't jacked with the accell much sice the code change, I was dealing with 30-35kpa swings through the rpm range (happy intake manifold/good tri-y header, and fixed sample angle on ms2)

It's so much more stable and easy to tune with the new code I'm very disinclined to switch back, I just need to redo parts of my setup. I'll be loading your new pass at it tomorrow now that I know this is just a loose nut behind the wheel, not a fw issue.

The new sampling code/filters may make setting up accell again easier.

[gslender]

Thanks for the quick read on this, pulls to 7k clean and fat with the threshholds raised.

I actually turned the thresholds up to 300 and it's gone, card drives much better too.
I drives strangely well for having accell amost turnrd off, do have eae on.

I haven't jacked with the accell much sice the code change, I was dealing with 30-35kpa swings through the rpm range (happy intake manifold/good tri-y header, and fixed sample angle on ms2)

It's so much more stable and easy to tune with the new code I'm very disinclined to switch back, I just need to redo parts of my setup. I'll be loading your new pass at it tomorrow now that I know this is just a loose nut behind the wheel, not a fw issue.

The new sampling code/filters may make setting up accell again easier.

In my 2.4.3 fw mod I used a similar appraoch to TPS for smoother inputs, so if you are getting good results with alpha 3.3.0b then you'll be laughing with the new TPS sampling. Unfortuantely I may have bugged up the Voltage Compensation code (the new Adaptive Voltage Compensation works, just the older original voltage comp code) so I could be pushing out an update tonight - tentatively a 2.4.4 release with hopefully a fix in there for the standard Voltage Compensation.

[piledriver]

I'll wait until its up then, just ran another 80 mile commute with it, smooth as glass except at idle, cant quite get the recovery nailed down like I had it before, needs more tweaking on my part.

I could previously just about dump the clutch in second and it would climb "out of the hole" with no assistacne, even with no IAC.
It's too bad we can't use timed sampling at idle, and switch to average above it

[nitrousdave]

Is there a certain version of tunerstudio to use with use? I tried the latest release and beta version (of tunerstudio) and tunerstudio will continuously go online/offline and not stay connected.

[piledriver]

Is there a certain version of tunerstudio to use with use? I tried the latest release and beta version (of tunerstudio) and tunerstudio will continuously go online/offline and not stay connected.

You may need to turn down your sample//update rate.

I'm using 1.21b and running max sample rate through a real live 16550a serial port ATM, as I'm running VEAL again due to some changes in the setup.
Zero problems, although I haven't figured out what that rate actually is, the setting is maxed out.

For my USB, I can do ~25Hz, 20 dead reliable.
For my BT setup, I have to turn it down to 10Hz or I get connect/disconnect and/or corruption issues in TS.
(all of the above on the same PC, running Linux. Windows XP seems significantly slower in this case, esp. serial port, YMMV)
Logging to my phone is no issue at ~10Hz.

You can set your update rate in the communications tab.

[nitrousdave]

Just seems weird that 3.2.1 works just fine with standard settings, but I'll have to give it a try.

[gslender]

Just seems weird that 3.2.1 works just fine with standard settings, but I'll have to give it a try.

The later versions have more stuff being sent in the log, this in turn means more time needed to send it, which means a slower send/recv rate is needed. So it is possible that later versions will need a slight reduction in the sample/update rate.

[nitrousdave]

I tried evey different rate tonight and none of them worked. You don't have to close TS and reopen it each time you change the rate do you?

[piledriver]

I tried evey different rate tonight and none of them worked. You don't have to close TS and reopen it each time you change the rate do you?

The latest versions of TS seem to do more error checking (or something) it seems much more finicky.
It does work awesome on a machine/serial port that works.

Might want to bug the dev, there are a couple error handling options as well, but IIRC they are primarily for BT and USB comms driver beating.
Some of the USB adapters/drivers out there play fast and loose with the specs.

[robs]

I've just started looking at the MAP sampling code with a view to merging my moving anchor mapDOT changes. There are quite a few new flags whose names suggest what they do, but I thought I'd check in isr_rtc.s to make sure they were used as I expected. Now this has only been a quick look, but I just want to check that a JMP or RTI hasn't been missed. Here's the snippet in question:

Code: Select all

continue_norm_map:
   ldd      ATD0DR0
   addd     map_temp_sum+2
   std      map_temp_sum+2
   ldd      map_temp_sum
   adcb     #0
   adca     #0
   std      map_temp_sum
   ldd     map_temp_cnt
   addd    #1
   std     map_temp_cnt


map_sample_lowest:
   ldd      map_start_countdown
   beq      cont_map_check

   ; MAP sampling time?
   subd     #1


So we have "normal" map sampling, which is the new averaging approach. It accumulates the sum and count as you'd expect. But then it falls through to the "sample lowest" code, which looks to be the old approach of waiting for a sampling window and selecting the lowest sample when that window is in play. Feels to me that there should be a jump of some sort rather than falling through to map_sample_lowest.

I emphasise this is from a quick look and maybe I have completely the wrong idea. Could do with a sanity check. BTW, this is from the code posted at the top of this thread: isr_rtc.c 1.63. Perhaps I missed an update somewhere.

Have fun,

Rob.

[Trumpetrhapsody]

I tried out the new MAP averaging and it ran horribly. Had to give it throttle to even get it started, and could barely keep it running. It seemed like the reported RPM was lower than the actual engine RPM, and might not have been firing on all cylinders.

I attatched a log but it's in traditional mode, i'll do another with it in averaging mode later tonight. As you can see the RPM and MAP are still pretty jagged. TPS is better, and it drove pretty smooth. I hadn't tried the TPSdot smoothing yet from gslender's code, but I'm hoping that will clean up the dirty TPSdot.

I've always had to run pretty aggressive lags to get decent looking logs, I was hoping the averaging would help.

[Trumpetrhapsody]

Looks like my MAP value hangs at the initial startup value... which would explain alot.

Now gurus, why would enabling map sample averaging mode cause this?

[racingmini_mtl]

You're not using the standard code. Please post this in the appropriate thread.

Jean