1 ... 3 4 5
Paul_VR6
Paul_VR6 Dork
8/29/19 6:10 p.m.

It's easier to just use ms to control the lambda valve ...  I did that way back when in 2002. But your point about being able to change the slope and the switch point of the output is absolutely correct.

Knurled.
Knurled. GRM+ Memberand MegaDork
8/29/19 7:24 p.m.
Paul_VR6 said:

It's easier to just use ms to control the lambda valve ...  I did that way back when in 2002. But your point about being able to change the slope and the switch point of the output is absolutely correct.

Can we talk in PMs about using MS to control the lambda valve?  I have a friend who is married to the idea of K-jet but also wants to run coil on plug/coil near plug because you can't make very much power through the distributor on an old Audi without risking crossfire.  And he's asking me pointed questions that frankly I don't have the answers to.

1SlowVW
1SlowVW Reader
8/29/19 7:58 p.m.

In reply to Knurled. :

I may be the only one on the web asking this. 

But can you keep this conversation public and not in pm’s.

Or at least summarize it once it’s done. There are some of us still interested in vintage Bosch management and in standalone. 

With other forums dying off there’s only so many places to glean trustworthy information.

Knurled.
Knurled. GRM+ Memberand MegaDork
8/29/19 8:01 p.m.

In reply to 1SlowVW :

It also occurs to me that he's also on GRM now, too.  Either way it deserves a different thread.

 

1SlowVW
1SlowVW Reader
8/29/19 8:03 p.m.

In reply to Knurled. :

Of the millions of internet users there’s a least two interested in reading a well written opinion on the subject, probably at least three when you consider it’s written by someone with experience.

Keith Tanner
Keith Tanner GRM+ Memberand MegaDork
8/31/19 5:53 p.m.

Yes, at least three. 

Ransom
Ransom GRM+ Memberand UltimaDork
8/31/19 5:56 p.m.

Can we call it four and decided before the headcount is its own threadjack? cheeky

[Edit to put the smiley at the end of the line. This editor does some weird stuff sometimes...]

Paul_VR6
Paul_VR6 Dork
9/3/19 2:10 p.m.

Totally willing to discuss keeping CIS and controlling... someone start a thread and link me if they already haven't

engiekev
engiekev Reader
2/26/20 9:15 a.m.

Bringing this back up instead of making a new post: what is the best way to control wideband controller power without a standalone ECU that has the ability?  Knowing that waiting ~30s after start to power the O2 sensor helps save sensors from thermal shock, it seems like a necessary step.

1) Is a time-delay relay based on switched power the best option? That does assume that you would start after keying-on, but I suppose you could also add an override switch to turn off the relay when just keying-on for other purposes.

If that is the best option, is something like this ideal?

https://www.qualitymobilevideo.com/bu508td.html

2) Is a manual switch controlling the wideband power the best option?

alfadriver
alfadriver MegaDork
2/26/20 9:30 a.m.

In reply to engiekev :

If you have an output from an ECU that can switch a relay on and off, waiting from when the engine actually starts is a better timer.  The delay is to make sure the exhaust is high enough temp to avoid liquid drops- and that changes once the engine is spinning.

And instead of the timer relay that you posted, the ECU output could drive a solid state relay.

FWIW, in the +20 years of working with WB sensors and running them at crank, including down to -20F, the amount of times I've broken one can be counted on one hand.  Thousands and thousands of test starts, hundreds of cars, etc.  Some of those sensors dating back to the late 90's when they were more sensitive to cracking.  (and on a side note, OEM's will be introducing closed loop off of crank soon, as we've all figured out what the mechanism is that breaks them)

If it were me, I'd delay a 70F start by about 3 seconds, and once the engine is above 120F, the sensor would be on immediately.  Below 70, increase the time to maybe 20 sec at 20F.  Or better yet, find a way to measure the exhaust temp- and find when the temp gets above 200F in the exhaust. 

Knurled.
Knurled. GRM+ Memberand MegaDork
2/26/20 9:35 a.m.

I am glad you brought this thread back up because I am at the point with my VW that I need to think about engine management. 

 

I like the idea of using Motronic or FAST because of the integrated wideband controller (fast and sensor friendly) but MS3Pro is easier and more tuner-friendly than a Motronic bodge, and a lot cheaper than FAST XFI, and I'm not even sure it can be used on a configuration that they don't have a canned setup for.  I am hoping that a good controller (not Innovate) connected to the CAN inputs will be the best of both worlds.

engiekev
engiekev Reader
2/26/20 10:11 a.m.
alfadriver said:

In reply to engiekev :

If you have an output from an ECU that can switch a relay on and off, waiting from when the engine actually starts is a better timer.  The delay is to make sure the exhaust is high enough temp to avoid liquid drops- and that changes once the engine is spinning.

And instead of the timer relay that you posted, the ECU output could drive a solid state relay.

FWIW, in the +20 years of working with WB sensors and running them at crank, including down to -20F, the amount of times I've broken one can be counted on one hand.  Thousands and thousands of test starts, hundreds of cars, etc.  Some of those sensors dating back to the late 90's when they were more sensitive to cracking.  (and on a side note, OEM's will be introducing closed loop off of crank soon, as we've all figured out what the mechanism is that breaks them)

If it were me, I'd delay a 70F start by about 3 seconds, and once the engine is above 120F, the sensor would be on immediately.  Below 70, increase the time to maybe 20 sec at 20F.  Or better yet, find a way to measure the exhaust temp- and find when the temp gets above 200F in the exhaust. 

I would go this route, but with old mitsubishi ECUs and ECMLink, I don't believe there is an option to turn on based on engine running. There is a way to control the FPR and EGR solenoid outputs with other triggers, such as RPM but not engine run time. Yet another reason to upgrade to a standalone ECU eventually.

Paul_VR6
Paul_VR6 Dork
2/26/20 12:36 p.m.

Based on alfadriver's input a few years ago I have been actively trying to kill wideband O2 sensors, and I haven't yet. At least from cold shock, lead death is real no matter what you do. 

Most of the wideband controllers have the timers built in to not output until *ready* you just need to use a power source that comes on once the engine is *ready* the fuel pump relay 12v source (or its trigger to another relay) works very well. 

@knurled there aren't a ton of CAN enabled widebands but it's easy enough to scale your analog output if you do encounter and offset. Most of the actual fast cars I don't use the integrated wideband in the systems, they are replaced by single or dual ones that are better for the particular car (generally Ballenger AFR500v2's with the cars I tune)

Knurled.
Knurled. GRM+ Memberand MegaDork
2/26/20 12:58 p.m.

In reply to Paul_VR6 :

I was thinking CAN not for voltage offset, but for the delay factor.  FAST reacts fast enough to sensor readings that a datalog will never show a lean or rich spike, you have to tune the map and acceleration enrichment by watching the fuel trim.  Running a wideband through two different ADCs introduces enough lag that it's noticable.

 

FAST is also about 3x more expensive than an MS3Pro, and I am unsure if it can be made to work on a five cylinder.

Paul_VR6
Paul_VR6 Dork
2/26/20 1:09 p.m.

You are talking more about how well the closed loop PID works, not really the lag (which is very, very small). I have been beta testing some of the O2 PID improvements in the 1.5.2 firmware. I have cars that run single digit ETs that can run full closed loop passes with a nearly untuned VE table (including reacting to traction control events). Once the delay table is set and a little PID tuning is done, it's much, much better than previous. 

alfadriver
alfadriver MegaDork
2/26/20 1:15 p.m.

In reply to Paul_VR6 :

I'm curious what he means, too- because there's still the transport delay time from when the fuel is injected to when that combusted exhaust even passes by the a/f meter.  Which is one of the main drivers that makes the open loop compensations so good.  Closed loop can only be so fast even if the detection has zero time loss to the code.

Knurled.
Knurled. GRM+ Memberand MegaDork
2/26/20 1:20 p.m.
Paul_VR6 said:

You are talking more about how well the closed loop PID works, not really the lag (which is very, very small). I have been beta testing some of the O2 PID improvements in the 1.5.2 firmware. I have cars that run single digit ETs that can run full closed loop passes with a nearly untuned VE table (including reacting to traction control events). Once the delay table is set and a little PID tuning is done, it's much, much better than previous. 

Fair enough.  I could only relate to my experiences and it always seemed like anything with wideband control built in to the computer was ridiculously fast to respond.  It will probably be a month or five before I get to that point, plenty of time for me to put off learning about refining the responsiveness until a half hour before the first drive.

NorseDave
NorseDave Reader
2/26/20 2:28 p.m.

I have a related question - can you kill a WBO2 by running the engine and not turning on the WBO2?  Like, at all, for minutes at a time?  Early on in my Megasquirt process I had the O2 on a physical switch and often I didn't even turn it on.  Lately I've noticed the output is not as smooth as I'd expect - like sitting at idle, no changes, it will fluctuate by +/- 0.5 (lambda) or somewhere in that range.  I've just been general getting some strangish readings and I'm wondering if  I screwed it up.   

 

Knurled.
Knurled. GRM+ Memberand MegaDork
2/26/20 2:31 p.m.

In reply to NorseDave :

Yep.  They do not like being run uncontrolled.

1 ... 3 4 5

You'll need to log in to post.

Our Preferred Partners
i0dNgqRdr2BR2hOGiSwTvYFDqW87h56UTeyrLR2CGQ5ApFUhvukDQDq4OQgTOmOf