toplessFC3Sman

iTrader: (1)

Another possibility would be to compare the input duty cycle staging parameter with the DC from normal operation, EGO correction and WUE instead of actual DC that includes acceleration enrichments. This way, if they're set to stage at 80% and you're at 75% with a spike to 85%, the primaries will take care of this extra load by themselves. It'd be unlikely to hit 100% DC with an accel enrichment, and even if you do, 100% for a fraction of a second won't hurt the injector.

Depends whether you think of this as a problem with the secondaries staging when they dont need to, or whether you're using the AE at close to the limit as "priming" the secondaries since its likely they'll need to come on soon.

Jobro

iTrader: (2)

I will try staging by PW @ 80% as that sounds like a good idea. I just checked my datalog and my PW with the secondary staged in never exeeds 38% because I have 51psi fuel pressure and 550/870s on a non turbo 12A.

Jobro

iTrader: (2)

What code did you give to topless? You mentioned something about messing with 02 in the code that you gave both of us?

I tried closed loop 02 for a bit with that code and I noticed that its working the best it ever has. And it will actually track onto the target and stay within 0.3 AFR. In all my tests with the MS2e1.0.2 closed loop O2 control seemed basically useless...

muythaibxr

The code I gave him should not have had my mods in it, nor should the code I gave you.

Both of those should've been the same as 1.0.2 (and the behavior for me in 1.0.2 and 2.1.0 was the same for O2, although I'm working on changing it now so it'll work better).

Ken

toplessFC3Sman

iTrader: (1)

Have there been any additions to the code since last november when you sent it out? I tried downloading the newest 2.1.0 from the beta files folder (http://www.msextra.com/ms2extra/files/beta/), but it would not read the engine speed correctly, whereas the one you sent me did.

Also, is there a write-up or explanation of some of the variables related to the PWM closed-loop idle? It's been acting very strange with MS2, and i can't get it to consistently catch the engine when i'm pulling up to a stop sign or something. What would be especially nice would be an idea of what the PID delay, PID ramp to target time, PID lockout terms, Close delay and whatnot did, just so make sure i'm not making the wrong assumptions for how to adjust them.

Running the MS2 also seems to require larger VE numbers for the same req_fuel than MS1 did to maintain the same AFR's, and the AFR's bounce around a lot more (even with accel enrichments, EGO correction and whatnot turned off).

muythaibxr

Send your settings. Nothing has changed that should cause that, but if you just loaded your old MSQ it might've gotten a setting wrong.

There is a thread over at msextra.com that has guidelines and what each number means. Usually a stall pulling up to a light means the PID lockout settings are wrong, and PID is engaging before the engine has settled down.

The thread is here:

http://www.msextra.com/viewtopic.php?f=91&t=30441

It is written for those using stepper IAC, but PWM uses the same variables for the most part.

As far as needing larger numbers, I think that might be because MS1 used the RTC section to open/close the injectors, which in ms1 was interruptable. I think sometimes the MS1 could be off by a couple of tenths of a millisecond because of this.

The MS2's calculations are done at 1/100th of a microsecond resolution where the ms1's calcs are done at 100 microsecond resolution. The ms2 is far more accurate. The ms2 also controls the injector pulse-width down to 2/3rds of a microsecond resolution where ms1 only had .1 millisecond resolution. If you need a higher VE on ms2, the newer VE is probably correct.

The AFR's bouncing around a lot more is not something I've noticed. In fact, everything I've done, even with AE and EGO correction turned off has shown a much smoother AFR. If your AFR is bouncing a lot, you might be getting MAP jitter (which can happen more with ms2 due to the ADCs being more accurate). You should adjust the MAP sample % mask until you get the least MAP jitter, and then you can slightly lower the MAP lag factor as well. The lag factor will hurt responsiveness though. You can also put a restrictor on the MAP line. Also, make sure that your vacuum source pulls from all the runners and not just one of them.

Ken

toplessFC3Sman

iTrader: (1)

So far i've noticed that the numbers have had to be about 20% larger, and I still have barely gotten into tuning the atmospheric portion of the map and beyond. I'm still playing with it, and am gonna go over my settings and everything for a bit more, especially after reading through the link you provided for idle control. I did have the lockout settings a bit wrong, so i'll play with them tomorrow. Does the lockout load value for PWM refer to the map, or does it refer to the load variable that i've seen in megalogviewer?

As for the map signal, its coming from the plenum, and running thru a physical filter, as well as a 50% map mask, bit i can still turn that up a little. I'll play around with all the settings for another couple days and see if i cant quiet it down a little.

On a much better note, there have been absolutely no problems with lost sync or anything with this code variant. Are the changes you made to it going to get implemented into any of the betas , b/c the one released on april 13th, 09 still has the sync problems.

muythaibxr

The lockout load value refers to the load variable (which is also what's used for VE and spark table lookups).

So it's coming from a "collected" location?

the 50% MAP mask can be lowered to 0. I find that 20-30% works best for my install.

Very recently (the last beta) James made a change to the way that 2nd trigger wheels are decoded that *should* help with noise issues not hurt. That was only in the very last beta though.

I have used it on my rx7, and we ran it on eage8's car for 6 hours on the dyno a couple weeks ago, as well as on a 650 mile trip home from GA without a single issue, so I'm confident that the code is solid.

I just released the 2.1.0 RC1 build as well, which I've updated in the firmware thread.

Also, if you're having what you think are noise issues, go grab tunerstudio (can be found in the firmware thread in this section) and use the "diagnostics tab" to look at the signals that the MS is seeing. You can use the "tooth logger" to see those signals. You can also turn on the noise filters and then turn on the composite logger to get a graph that would look at home on an oscilloscope.

Ken

toplessFC3Sman

iTrader: (1)

Ok, I think i get the idea with the lockouts, i got them working a lot better tonight

yea, its a collected location. With a 50 averaging lag factor and 50% sample mask, its been pretty smooth. I havent really played around with the sample mask value too much though,.

I'll take a look at tunerstudio, but based on the megalogviewer data, there isnt much noise.

She was running much more smoothly tonight than last night; almost no bucking around, especially under light throttle, and the O2 fluctuations were comparable to those I saw using MS1, plus tonight the VE's for most of the operating range were much closer to those from MS1. I played with a few other settings, and hopefully one of them was my issue.

Anyhow, thanks for the help Ken, you've been great!

Pete

muythaibxr

[QUOTE=toplessFC3Sman;9185201]Ok, I think i get the idea with the lockouts, i got them working a lot better tonight



yea, its a collected location. With a 50 averaging lag factor and 50% sample mask, its been pretty smooth. I havent really played around with the sample mask value too much though,.
[quote]

You should be able to use 80-90 for MAP lag factor if you have the MAP line filtering and the sample mask set up correctly. With lag at 50, the engine isn't going to be very responsive to blips for things like rev-matching downshifts.


Glad you're getting somewhere with it then.

Ken

toplessFC3Sman

iTrader: (1)

Well, she's been running pretty well (about the same as MS1 so far, but i still have some fine-tuning to do), except for one small problem. Over about 4000 RPM there is the occasional miss, and it becomes more common as load increases. It doesn't sound or feel like knocking, it just feels like the spark doesnt fire, and is always accompanied by (or caused by) a sync loss of ~10-20 cycles. In the logs it just looks like a brief RPM spike of 200 or so. Just free-reving in neutral to those engine speeds rarely causes any sort of problem and only the occasional single missed cycle.

It seems to me like the sync error is causing the miss, but i'd like to see what everyone else thinks. Im considering moving the VR pickups closer to the wheels and going over the wiring to see if that'd solve it.

Also, what are the "Status1" thru "Status5" quantities in megalogviewer? status1 seems to be a toothcount, but I could just be seeing it wrong.

muythaibxr

sometimes misfires can cause noise... what is your dwell set to? What is your timing like in the areas that you've seen have the problem.

I've seen cases where I was getting misfires that looked like they were caused by sync-loss, but then I changed the timing in that area, and the sync-loss went away (which means the misfires caused the noise that caused the sync loss, not the other way around).

Those status vars are mainly used to display the indicators at the bottom of the screen in MT. Some of them are not currently used, except by James and I as debug counters when we need them.

If you're using a recent 2.1.0, then the sync loss errors should be accompanied by a sync-loss reason... Could you look for those in your datalog, and post the "reasons" you see?

Ken

toplessFC3Sman

iTrader: (1)

the version i'm using is 2.1.0 but the alpha version you emailed to me about 7-8 months ago. I'll try getting a newer version and running that to see about the reasons. I'm planning on checking the timing again with a timing light tomorrow, since I havent done that since upgrading to MS2 (altho it was zero-ed for MS1 and im pretty confident in my math). The engine seems to miss at all sorts of loads above approx 5k RPM, and it seems to occur a little more often when there is a large change in RPM, such as running to redline in 1st or 2nd.

The timing above 5k is approx 40 bTDC at 20 kPa up to about 30 bTDC at 100 kPa, up to 20 bTDC at 140 kPa which is the highest boost I've run. Even based on the stock maps, this seems slightly conservative, but not enough to cause misfires

toplessFC3Sman

iTrader: (1)

Well, no luck with the timing light, but then again i think its the same ancient thing that my dad used to use on his VW bus in the 70's. Basically, as soon as I hooked it up, it'd kill the engine. Oh well, time for a new one i guess.

Anyhow, i loaded up the most recent 2.1.0 beta (the one released in april), and once I realized that it shut off rotary trailing, it seemed to be running well. No more recorded losses of sync and it felt much smoother at higher RPMs. However, there were some new misses around 2000 RPM and the occasional one at idle where recorded RPM dropped to 0, but the lost sync counter did not increase for them. However, a lost sync reason showed up at a few occurances. Is there a place where I can look up what the lost sync reason number corresponds to?

I racked up reason #17 3 times, all at around 2000 rpm, and reason #11 8 times, all at 4000 rpm and above.


EDIT: Also, would the noise filters have any effect on the lost sync problems? If i'm understanding it correctly, the noise filter just ignores any pulses that are less than the lookup table value, and the tach period rejection rejects any pulses that are greater than the time given or longer than the percentage of the total cycle? I may be way off on that tho.

muythaibxr

Try the latest RC, which is RC3.

The noise filters *could* help. Honestly the thing that helped me the most was grounding pin 14 on the lm1815 2nd trig circuit.

You are basically correct on how the noise filters work. You should also turn on "polarity checking" which helps a lot. Basically that just checks to see if the polarity of the pin is correct when entering the interrupt. The idea being that if it isn't, it was a short noise spike that we can (and do) ignore.

Sync loss reason #17 means that there's probably noise on your primary trigger ... it means that we counted 12 teeth and looked for a second trigger without finding it where we thought it would be. Usually this means noise on the primary trigger. This will actually cause the code to reset itself... meaning clear out all variables and resync to the wheel.

Reason 11 means there was a second trigger when we weren't expecting it. This can be as a result of what caused #17, or it could be noise on the second trigger input. We don't actually resync to the wheel in this situation.

2nd trigger noise can be helped with the addition of a .01uF cap across G+ and G- where they enter the lm1815 circuit (you do have G- running all the way to the lm1815 circuit right?).

Primary trigger noise is a bit more problematic, and usually indicates that your VR wire shielding is probably not working, or you have a noise source very near your VR wire.

Ken

toplessFC3Sman

iTrader: (1)

What do you mean by the latest RC?

I'll double-check, but im 99% positive i have the G- running to the LM1815 board, and connected to the ground at that point. I'll toss that cap in there too, and play with the noise filters. I can also try running a shielded cable from the DB37 inside the MS to the LM1815 board (its in a seperate enclosure since I wanted to clean up the previous circuit in the proto area).

Doesnt grounding pin 14 put it into fixed-arming mode? I dont have the data sheet in front of me right now.

toplessFC3Sman

iTrader: (1)

I also noticed in the datalogs that the idle valve was getting activated between shifts, basically as soon as the throttle got below 2% (which is what I set in the closed loop idle window). It seemed to be ignoring the RPM + RPM_adder condition. Idle RPM is set to 800 and adder to 250, with lockout rpmDOT at 20 and locout load at 30% (idles at 41 kPa pretty steadily, with decel between 20 and 25) but the valve opens at each shift, anywhere from 2000 rpm to 7000 rpm. It seems to just open to the previous value at each shift (most of the time), with no active control. Is this the way CL idle is supposed to work?

Also, I've been seeing a bunch of occasions where TPSaccel enrichment has been activated, but megatune records no TPSdot or change in TPS value. I've changed the TPSdot threshold from 4%/sec to 15%/sec and it doesnt seem to have affected the frequency or magnitude of these random disturbances.

muythaibxr

The latest release candidate.

Grounding pin 14 takes it out of the RC timing mode, and puts it into zero-crossing mode. IF you have not done this, you should. It was the single most helpful thing I did on my lm1815 board and several others that are on rx7's now.

Ken

muythaibxr

That is how it works. What you're seeing is the dashpot code at work. The code has no way of knowing whether you're shifting, or if you're going to drop back to idle, so it opens it every time you let off the throttle in order to "catch" the engine and keep it from stalling if you are letting it go to idle in neutral.

I don't remember which beta I changed this in, but the TPSdot calculation was off by a factor of 10 (too low). With that change, you need to multiply your threshold and all your rates by 10.

having it set to 4% or 15% will both cause it to trigger way too often. You might not see the TPSdot value change if they are quick changes as the datalog resolution is too low to see quick events like that.

Ken

toplessFC3Sman

iTrader: (1)

Ok, i'll continue increasing the TPSdot threshold. What are some good ball-park numbers? Are the values for the enrichment table also off by 10? I am running the beta released in April (found here:http://www.msextra.com/ms2extra/files/beta/). If this isnt the latest RC, where could I find the latest?

I was expecting the idle valve control to not start until both the TPS and RPM constraints were met, but if its just TPS based, then that would account for the activity. The idle valve is active whether in neutral or if coasting down in gear (not that it would know the difference unless another RPMdot term was used).

Turning on the noise filter seems to have taken care of all of the type 11 errors, but there are still a couple type 17's that I need to take care of. I'll solder the cap between the G+ and G- lines and doublecheck pin 14 tonight (i had been thinking of pin 5 in my previous post; the LM is using the RC circuit for the arming threshold at pin 7). Is there any downside to leaving the noise filter active even if its not necessary?

muythaibxr

Whatever you used before, literally multiply by 10 for the numbers. Only the accel rate numbers change, not the enrichment numbers.

The latest RC is at http://www.msextra.com/ms2extra/files/rc

The dash-pot activates based purely on TPS. The PID loop does not engage until other thresholds are met, including RPM (RPM + adder). If you're coasting down in gear, then you'll need to make sure your lockout settings are good... the MAP lockout setting should be slightly below your lowest idle kPa, and the RPMdot setting should be as low as possible to avoid accidentally going into PID when you shouldn't.

As long as your noise filter curve is not set to values that are too high (I typically use settings of 100 at low revs, and in the 50's at higher revs if I need it) it should not hurt anything to leave it on.

That said, I usually turn it off if I don't need it just because it's extra code that's running that isn't needed if you don't have noise.

Ken

toplessFC3Sman

iTrader: (1)

Is the TPSdot multiple problem fixed in RC3?

toplessFC3Sman

iTrader: (1)

Thank you again Ken! with the latest RC and with the LM1815 in zero-crossing mode, I havent had a single loss of sync. She's running very well now.

I think i may be getting a bit of TPS noise, especially at full throttle, because the TPS plunger is actually vibrating on the cam actuating it, since I dont see nearly as much jitter in the TPS and tpsDOT signals when the car is off or when running on the highway at 2000 RPM with the throttle fully planted. Is there a way of turning off acceleration enleanments when in boost? I remember that option from MS1, but cant seem to find something similar. Maybe its just time to ditch the plunger and go with a real rotational-type sensor, altho I dont know how i'd fasten it since the throttle cable pulls are on one side of the shaft and the OMP rod is on the other.

toplessFC3Sman

iTrader: (1)

Looking thru the logs, i've noticed that with the staging occuring at a duty cycle of 80%, that acceleration enrichments near the limit trigger the staging code for a split second, then it turns off, then it triggers again once the duty cycle without enrichments passes the setpoint. I was wondering if it'd be possible to put a time-based hysteresis on the staging too; so that once the secondaries come online, they wouldnt be able to turn off for a user-specified amount of time. This could also have benefits when shifting at full throttle, so they wouldnt be phasing in and out.

muythaibxr

No, the original problem is that the TPS was 10x less sensitive than it should've been. It wasn't accurate to the actual rate.

The "10x multiple" is correct, it was broken before...

Ken