Thoughts on replacing 911 SC ECU with Raspberry solution
 

Hello everybody
and especially all Porsche lambda, raspberry loving and ... coding cracks. :-)

These days I was thinking of enhancing the lambda control by using a "wideband" AFR gauges "0-5v" output possibilities.

All I would need is a unit to tell via 12v PWM output the Frequency valve to operate at specific PWM rates, means duty cycles.
This unit would get the input via the 15c temp switch, the 35c temp switch, the micro- and the throttle angle switches at the throttle body and ... the 0-5v voltage signal of the AFR gauge system.

And so .. the closest way would be to set up a Raspberry Pi for this, as it comes with GPIOs (including PWM pin!).

What do you mean?
Any thoughts, infos, cents on this? :-)


PS: I already checked this thread but seems to handle WUR as subject only:
http://forums.pelicanparts.com/porsche-911-technical-forum/997787-lets-discuss-digital-wurs-replacing-k-jet-lambda.html


EDIT: Its getting hot:
https://tutorials-raspberrypi.de/raspberry-pi-gpio-erklaerung-beginner-programmierung-lernen/
English sources are very welcome as well :-)

You could probably use a Pi Zero for what you are looking at doing.
In fact... you could probably use an Arduino.

Keep in mind that there are a few other things that need to be addressed beyond just the I/O signals being transmitted to various sensors.

Subscribed. I'm always wondering what I'll do when/if my stuff under the passenger seat dies.

Just rip it all out and go full EFI. Benefits everywhere.

It has crossed my mind, that's for sure. $$$ though. Just coming off a full engine rebuild, so the wallet's a bit light.

Search for old threads about simplifying the CIS. You don't need the frequency valve. It was a late CIS bandaid for emissions and used to compensate for aging/worn components to keep the mixture in compliance. You can setup and tune CIS without it - but I wouldn't bother.

i concur.

no point in investing in upgrading an annoying addon on addon system invented by porsche to make life difficult and complex.

wait a little while longer, save some pennies, and once your CIS gives up or starts failing (it will), go bitzracing kit. 2.000 USD and you rip all that old **** out. I'm almost 2 years with EFI now and there's no way i'll ever go back to CIS.

It would be a fun project but it would be even more fun to have full control of injection and ignition!

@jpnovak
There have been a dozen threads where people asked how to remove the freq valve but .. as the Lambda based 930/16 engine comes with a diff. fuel distributor you can't just compensate the resulting leaning out of the system when the freq valve has been removed as the pressure of the FD's low chambers would simply be screwed up.

As the original ECU is very simple and based on a narrowband O2 Sensor it comes with some slightly noticeable disadvantages like i.E. a slight hunting idle.
This is due to the very inaccurate narrowband 0-1v voltage jumps provided to the ECU.
But thats just one issue.

Also in Germany this inaccurate and prehistoric type of 3-way lambda control won't let pass the 930/16 based cars to obtain a "green sticker" permission to drive within cities where only cars with green stickers are allowed to drive.
With a very accurate lambda and therefore AFR control incl. a more modern type of catalysator it could be that the emissions will be within the "green sticker" specs.

"As the original ECU is very simple and based on a narrowband O2 Sensor"
This makes the village idiot (me) have dumb question;
If the control loop for the freq. valve is based on input from the O2 sensor, what happens to the freq valve output signal if you don't have an active O2 sensor??

It goes open loop. 50% duty cycle.

I think of the FV system as an adjustable fuel pressure regulator, electronically controlled using a simple PVM signal. It can used for more than just emissions with an updated controller such as the one Andrew is looking at. Adding more sensors is possible as well.

Last I checked, these hobby ECU's were relatively cheap and yes, this is on my project list someday !

Hmmmm.

So I would need

- a temp sensor or even using the existing 15c and 35c temp switches
- a narrowband- or even a Bosch LSU 4.9 wideband oxygene sensor
- a Raspberry Pi
- an A/D and D/A converter

And a code which reads the input voltage of the sensor where a controlled 12v PWM duty cycle would be provided to the frequency valve brining/keeping the AFR to stoich.

Beside this, if the the Throttle switch is beyond 30% or/and the temp sensor provides below 15c the duty cycle provided to the FV would be 65%. And if the temp is below 35c, then when passing the 5° angle on hitting the gas pedal the duty cycle to the FV would be 75% for 3 Secs.

So using C or C++ there would be an if/then Loop where all the input from the switches and sensors would be read out which affects the PWM voltage duty cycle provided to the FV.

So ... someone has skills on how to attach an A/D converter to the Raspberry Pi which provides the sensor voltage and the position of the switches at the throttle body?
And also attaching a D/A converter providing the correct 12v PWM based duty cycle to the FV.

Running a Linux system for such a simple task seems a bit of an overkill to me. A Raspberry Pi boots quickly but it still needs a few seconds.

If the temp switches are of the on/off type you can directly use the GPIO pins on the RPi. If they provide a variable voltage you need an A/D converter. I don't have experience using them on the RPi but it seems like an easy and cheap thing to do:
https://learn.adafruit.com/raspberry-pi-analog-to-digital-converters/overview

The Arduino hobbyist ecosystem looks like it has off the shelf boards for all these components above.

Yes, Arduino seems a nice way to go

https://forum.arduino.cc/index.php?topic=448191.0

Have you read the 'FrankenCIS' thread?

It's the same journey as you are wanting to do to a degree.

Andrew,

I've been busy lately and have been meaning to reply.

Here are my thoughts. This is a subject I've been thinking quite a bit about.

First, the K-Jet w/ Lambda box. Yes, it's 1980's tech. But the thing is you really don't hear much about these boxes failing. Not that it doesn't happen, of course, but you really don't hear much about them being a common problem source.

What you're talking about could certainly be done. I think there are a few issues:

1) I'm not sure the Raspberry pi/Arduino is the right platform. You might have better luck with using a Megasquirt ECU.

2) It would take some time & testing to account for the various states to reverse engineer the Bosch box. Take a look at this post by javadog. This gives a nice summary of the various states (or conditions) you'd have to account for.

3) I tend to agree with others that if you were going to go this route, it would be better to go with something like Megasquirt.

If you look at engine theory, you will come across the term BMEP (Brake Mean Effective Pressure). BMEP is the equivalent average pressure acting on the piston during the entire volume change in the cylinder. It turns out BMEP is a great way to compare most internal combustion engines, regardless of displacement.

When BMEP increases for a given engine, it is either because the engine was a) able to extract more power or b) the engine was able to draw more air (VE, or volumetric efficiency increase).

So why am I saying this?

If you play with the math, you can see that -- at least on paper -- there is latent power gain potential for most of our engines. The question is how much power can be gained by extracting more power and how much can be gained by increasing VE and at what expense?

The reason that people say turbocharging an engine is the cheapest HP gains is because a turbocharger dramatically increases volumetric efficiency. Now whether a given engine can handle turbocharging without blowing the motor is another question.

Take a stock SC 3.0 motor and convert it to EFI. You can do things like change the intake, cams, flow the heads, change the exhaust, etc to help the engine breathe. Those things will affect VE. The change in ignition and fuel delivery will allow precise control of the fuel delivery and spark timing which will help extract more power. Of course, you can increase displacement and compression ratio, but that is yet another cost increase. (If you HAVE to do an engine rebuild, that's one thing... but if you don't have to...)

The problem, at least as I see it, with an EFI conversion is that it isn't a simple swap out of CIS->EFI to get real gains. You'd probably want to change cams, intake, exhaust, etc. which adds additional cost on top of the EFI conversion itself. Now maybe you can do these things as incremental steps so financially you don't have to do it all at once, but my point is these are the kinds of things you want to eventually do if you want to reap the rewards so eventually most people will care about the total cost involved. (PS, some people claim that the domes shape of CIS piston are not ideal for EFI either.) The costs begin to add up quickly and there are many variables that affect the potential for real HP gains which makes it difficult to arrive at a meaningful cost/benefit analysis.

What I've been wondering is if there is a viable intermediate step in CIS->EFI conversion -- a "partial" upgrade to CIS to get some of the easiest gains without all the expense.

In a CIS K-jet w/ Lambda system, there are a few things that affect normal operating fuel delivery:

1) warm control pressure (regulated by the WUR)
2) throttle position
3) frequency valve & narrowband O2 sensor

(I'm going to ignore the bits that affect cold start for now.)

Basically, K-Jet regulates fuel delivery based on engine load conditions. EFI does the same thing and a lot more.

I like the FrankenCIS idea because you get a wideband O2 which gives you the ability to have better data and to do data logging. You also avoid the analog nature of WUR calibration, plus you can replace the frequency valve functionality too. To get the most potential out of it though, you'd want to be able to somehow know the engine load and also control the spark. Jonny (of Classic Retrofit) mentioned that he has played around with this idea and I'd like to see the idea developed more. To me, combining the benefits of his CDI+ electronic ignition timing control, multi-spark up to 10,000 rpm and more precise fuel delivery seems like it would be possible to get enough (but certainly not all) of the gains of an EFI conversion at a much lower initial cost. It is hard for me to say.

The alternative would be to integrate the Megasquirt/FrankenCIS ECU with some other ignition system to control spark timing.

A digital replacement for the WUR (AND the AAR -- why not?) would also improve reliability and reduce some of the troubleshooting hoops we usually have to go through.

Sorry for the long-winded answer, but you asked. :D

These are ideas that are rumbling around in my head. I'd welcome more discussion on this.

Hi Tirwin,

thanks for your reply!
I have been reading many of your posts in here, i.E. the PLX wideband->narrowband issue when connecting to the original 911 sc ECU.

Im aware of all states of the ECU, means the 15c and 35c state and also in combination with the micro- and throttle switch.

My target is to keep the CIS as original as possible, means no further EFI upgrades or similair changes.
I just wanted to find a "programmable" solution for using instead of the old only electronically based original ECU. Thats why I startet this here.

To me its also difficult to unterstand why Porsche still used a WUR in a lambda and therefore ECU based CIS system where the ECU influences the fuel pressure via the frequency valve directly. The WOT acceleration feature via throttle switch where the ECU enriches the AFR mixture, makes the vacuum in the WUR therefore not needed anymore. Thats why the engineers dropped the vacuum feature and this shows the capabilities of the ECU based AFR mixture.

So as Im a bit in programming C language I thought an optimized programmed DIY ECU could be a nice option for less amount of money compared to mega squirt or similair.

Beside this – as o2 wideband sensor device I am thinking about purchasing the Innovate LC-2 lambda sensor/controller combination which also provides the narrowband simulation.
Where there only issues with the PLX narrowband output in your case or did you test the innovate LC2 narrowband output as well? Cause from some users I read that they had now problems when connecting directly to the original ECU.

Looking forward to your reply
Andrew

We live in an age where cheap electronics and 'modules' are all over the Internet and eBay. Whilst I applaud this for hobbyists, it is leading to the assumption that electronics is 'easy' and all you have to do is connect a bunch of modules and you have a product.

The same thing happened with software in the 90s with the emergence of 'easy' languages like Visual Basic and Labview. There is nothing wrong with these languages except that they led to 'everybody' skipping the requirements and design stages and diving straight in to 'coding' - a term that grates with me on a number of levels. I have made a very good living from the mess this left behind.

Good software isn't about writing the code, it's about understanding the requirements and choosing the correct design. The same is true for electronics.

You are jumping straight into implementation by putting forward an Raspberry Pi as the solution without considering the requirements. Its a bit like asking whether a pizza is the right solution for a dinner party. It could be, but it depends who the guests are, what they like to eat and what the ingredients are.

You are focussing heavily on the central control function. This is the 'exciting bit' so it is understandable but your design will be worthless if it cannot run in its intended environment. The Internet is littered with 'it works great but I get the occasional glitch/reset/odd behaviour'. And then it died....

You need to do some homework on how electronics is protected from the harsh electrical environment.

If you think that cars run off a nice stable 12V supply then this graph might surprise you. It shows the typical transients that occur on the 12V live in a car. Sadly, many ECUs and controllers do not have any circuitry to protect against these.


http://forums.pelicanparts.com/uploa...1532084461.png

That's just the 12v line. Every input will also have noise and need proper signal conditioning and isolation.

If this project is for your own entertainment then fine. If you are thinking of putting it out there then stop, do some more homework and consider contracting an EE with automotive experience.

(not wanting to piss on your chips, just experience talking)

Thats why Im starting this thread, not to just assemble and doing the code, but gaining from the experience of others and from sharing ideas.

And for sture its not for my own entertainment, if yes then I wouldn't be here asking this in a forum where many with experiences do share their knowledge and could help on for example this idea.

You aren't pissing on my chips at all, but a real gain would be i.E. a statement what could be used so issues like you mentioned above won't harm an adurino set up when using in a car electric environment. I know there are many details I/we should be aware of, so ... as you mention it ... give me some homework ;-) as ... I would apreciate it.

Cheers

If you are primarily interested in messing with the lambda Frequency valve control then there are a couple of choices for ready made hardware

1. MicroSquirt with the FrankenCIS firmware
This gives you as close to automotive capable hardware as you can get on a budget of a few hundred dollars
Owning the hardware gives you permission to modify the MicroSquirt source code to your liking as long as it is only run on genuine MegaSquirt hardware. Our additional code module for CIS is licenced under Apache 2.0 so you can pretty much do as you please with our portion of the code and integrate it into anything else.

2. Speeduino https://speeduino.com/forum/app.php/page/buy
A more DIY project at around half the cost of the Microsquirt, but has the advantage of being Arduino based with fairly mature firmware that runs engines, bringing across the CIS specific code from FrankenCIS shouldn't be too difficult. You could also easily start from scratch with your own implementation

both run similar main power circuitry which I would rate as 'sufficient', protection designs on inputs and outputs varies from absent to marginal between the two.

CDI can be driven by either system with a little circuitry to do the AC signal, or go fuel only control and use CDI+ from Jonny for ignition

I spent most of 2015 designing and prototyping specific custom hardware for FrankenCIS only to abandon the idea as it became obvious there was no commercial value over the currently available products. Those that could afford EFI were converting and those that couldn't were after something really inexpensive. The I like CIS so I'm staying for the fun of it group could be counted in single digits.

My idea here also was to feed a new DIY ECU with a wideband signal instead of a narrowband one.
Yesterday I received the LC-2 Wideband Controller/Gauge from Innovate, coming with a BOSCH wideband LSU 4.9 O2 sensor.
It works just fine and on the first test run beside the wideband output it also simulates a 0-1v narrowband output which works flawlessly with the original ECU.
This controller provides a ready to use 0-5v signal which can easely be interpreted by an Arduino setup. ... But I will keep a narrowband 0-1v option in this DIY ECU project as well. So no expensive wideband controller and sensor would be needed to make it work but a narrowband "bouncing" signal will be less precise compared to a wideband one.

So I ordered a lot of stuff, like an Arduino Nano, a step down DC converter to keep a safe liniear 12v input, and all other needed electronic parts.
As Im in C programming language I wanted to crack this nut and decided to start this project, as for this less money it could be really worth it.

The signal of the existing VDO 15°c and 35°c temp "switches" shurely will be taken into account as well as the obligatory throttle switch and Microswitch

The WUR is retained on Lambda systems for warmup and base mixture control

make sure you read through http://forums.pelicanparts.com/911-930-turbo-super-charging-forum/820323-digital-wur-plus-frankencis.html

Good luck and have fun :)

Hi Steve,

thanks, and yes, I had a look at many threads here like the Franken CIS ... and in the arduino forums. A lot of useful information which makes this project funny.

Cheers!

Yesterday I got the Arduino Nano

http://forums.pelicanparts.com/uploa...1534420379.jpg

... and all needed components for a first rudimentary set up.

It works very well!
Providing at 70Hz a PWM signal / duty cycle from 5% to 95%, based on the input voltage (0-5v) from a wideband Sensor/controller like the Innovate LC-2. The wideband voltage here is simulated by an external power supply.
When the sensor voltage goes below 2.5v it leans the mixture by decreasing the duty cycle, same logic in case of voltage rise and therefore needed enrichment.
How fast the duty cycle will be decreased or increased depends on how far away the AFR is from the stoichiometric optimum at 14,7:1, means 2.5v as output in case of the innovate controllers default.

https://vimeo.com/285265087

Now, ... adding the support of the CIS switching component inputs like throttle switch, temperature switches, micro switch etc. Here I won't just set the duty cycle to fixed 65% if an acceleration will be recognized but to an optimal AFR target (like 12.5:1) value like for best effective acceleration performance.

Have a nice weekend and cheers from Cologne

The Nano is a great device for the application. You could easily add the ignition function with as few as 50 lines of C code.

Hi Dave,

the few lines of C code ain't no problem but the interface to the ignition units and ... the proper timing advance/retard, done by the Ardino setup are the real challenge and ... do enjoy my respect ;-)

That's not that difficult, i.e. I've done it! You can easily use the 911SC distributor output as a timing signal. Driving the CDI box is simple too, i.e. easier than for an inductive discharge ignition.
Yes, the Lambda control part is the easier effort.

Ok, that really sounds very nice!

It's a fully functional proof of concept prototype for an inductive discharge ignition system directly driving an ignition coil.
The timing signal input is three pulses per engine revolution. There's a provision to measure load via a vacuum input,
e.g. using a vacuum sensor (upper right) as an input to the AD converter on the Nano.

Keep up the good effort! You're basically there.

Since the Lambda system is a control system with gain and feedback (O2 sensor), system stability is critical.
The 911SC with Lambda typically has about +/- 25-50 RPM variation at idle in closed-loop. If the mixture is too rich
or lean, the system can become unstable resulting in large swings in the idle RPM. If the feedback O2 loop gain
is too great, or the feedback voltage phase is positive, the idle RPM will oscillate greatly.

I ran an Arduino-controlled DWUR for well over a year with no issues whatsoever related to the Arduino system. You can check it out here: http://forums.pelicanparts.com/911-930-turbo-super-charging-forum/889347-another-digital-wur-project-arduino.html

@Dave
Yes, and lets see how it behaves in the real worl test later.
As the the original o2 measuring is done via a narrowband sensor, this gives a very less precise "bouncing" voltage output which could cause the oszillating idle.
My routine doesnt increases the duty cycle by a fixed vaue but with a value depending on how far the ideal cycle is away from the expected volatge which equals to a 14.7:1 reading.
So cycle adjustments at round about the 14.7:1 value range are more detailed compared to a suddenly occuring lean out or enrichment condition like acceleration or deacceleration.

@ Dr J
Thanks for your link! Very interesting.

How are you protecting the Arduino unit from ambient stress like temp change, vibration, etc? Or am I paranoid?

The DIY ECU will be mounted to the same place where the orig ECU was/is, means under the passenger seat.
The projet in its final stage will be completely soldered on a circuid board.

BUT ... that Arduino project is that funny that I'm thinking about putting it to the center console i.E., cause I made a little control display using a vintage looking green 2x16 LCD display where all the actual details are shown, means here Voltage of the wideband sensor, AFR, duty cycle and the equivalent CO value of the current sensor reading :-)
Or this display could be mounted within the ashtray, so it can be visible on demand, ... lets see.

http://forums.pelicanparts.com/uploa...1534977855.jpg

The vehicles 12v will be connected to Arduino via a specific DC step down element, which provides stable 5v and prevents from voltage peaks as well.

The Arduino forums are full of valuable information and Im very exited about its capabilities.

Nice progress!

Little status update: It works.
Yesterday evening I connected the arduino setup in a simple way to the existing wiring of the original ECU for a fist test. The Plug to the orig ECU was disconnected.

On a first "fixed duty cycle 50%" run, although the Frequency valve was fed by 12v at Herz 70, the mixture was a bit too rich. So I regulated it. Here when regulating the mixture by using the CO-screw I used the CO value on the new display and set it to approx. 0.5-1.0 CO. The idle then was smooth and the working Freq Valve sounded as expected. Even the throttle valve switch worked and pushed the cycle up to 65% as expected when passing the 30% throttle.
So I connected the voltage output from the LC-2 to the arduino and the regulation of the AFR by the varying duty cycle started. Everything was working as expected.

The only thing is, sometimes after driving when the engine changes to idle, independent from the arduino, the LC-2 sensor controller outputs an error and the arduino then interprets the 0v error output from the sensor controller as it should be, means it switches to a fixed 50% duty cycle (like if it was disconnected). When changing from idle to crusing or higher rpms the LC-2 sensor controller starts working again flawlessly.
Here I guess I would have to make a new sensor calibration or check the connections of the LC-2 controller

Wow. Sounds like things are moving along great. Congrats. I’m very interested in your work.