My techie thoughts on changing carbs for EFI

[davygrvy]

I've been pondering EFI for ages. About 3 years ago I got on the diy_efi mailing list and read about everything I could find. While reading the source code (that's in assembly) for Megasquirt it dawned on me.. This isn't easy source to modify or add extra work to. It fits its needs: minimal hardware with tight code, but stops there. How do people change things like add closed-loop and change it to sequential mode? There's nothing wrong with coding things in C, especially since I swim in it daily.

What if there was a like a passive backplane panel that allowed for plug-in cards with a CPU module with plenty of idle flops left-over that ran a real embedded OS like uClinux? I looked at MicroC/OS-II, but liscensing isn't that friendly, and doesn't have much for memory management eventhough I have the book and it is quite nice.

Given an O/S executive that has a true preemptive scheduler and not some busy loop as in megasquirt, and the ability to add hardware modules such as:

1. Direct fire ignition It goes together with EFI well as both need to know absolute crank position. The MSD patents expired ages ago, maybe steal CDI ideas from it?
2. Sensor conditioners with output bus We need lots of input anyways for the MAF, TPS, crank and cam position readers, why not keeping going and take on all the responsibility for every sensor possible like oil temp, oil pressure, CHT, etc. and multiplex all the output to a dash deplexor on maybe USB?
3. injector output drivers

Well, I'm just having fun dreaming.. I'd pay double for a F/OSS platform than some locked-in proprietary one. I won't hold my breath.. might take me two years to build one how I envision it.

3-D maps sound kinda silly to me.. Why only 3 inputs to calculate a single output? I wonder if there's any truth to doing things the fuzzy logic way?

[jonas_linder]

Why look into the source of MS before using it ??

There is alot of good versions out there!

MSnExtra is killer and have all the functions you need...

Only when you map the engine with MS you see how good 3D-maps are!!

[max power]

What if there was a like a passive backplane panel that allowed for plug-in cards with a CPU module with plenty of idle flops left-over that ran a real embedded OS like uClinux? I looked at MicroC/OS-II, but liscensing isn't that friendly, and doesn't have much for memory management ...

Is it important to know what the heck Davy is talking about before going FI, specifically MS? I know exactly squat about programming and electronics (and am quite happy that way). I want to go FI, and knew I'd have to learn MUCH about it before starting, but I wonder I wouldn't be in over my head.

[jonas_linder]

If you run fuelonly and have someone build you the MSkit and do the harness all you have to know is how to read and what size your engine and injectors are.. Rest is how to set it up (hardware) and howto tune it!

The manual is really good both on the soft- and hardware part!

I'm talking about MS now!!

Anyone could get a engine run with MS, it takes a little practise to make it run good thou!

[bhowden]

I think you are missing David's point. In the true MS spirit, he wants to know why it works, not how to make it work. MS is successful because 90% of its users CAN just follow the instructions and get it working and because the other 10% keep improving the instructions and the underlying system.

The first big problem I see with the backplane idea is vibration. A car is one of the most hostile environments there is for electronices. I am surprised most MS people have not had way more problems with the connectors than they have.

Have you looked at the AVR version or the newer, richer, replacement CPU?

Brian

[raygreenwood]

I vaguely know what a backplane panel is. Lots of equipment in my industry have one (printing presses)...on various control units and computers. This is nice for stationary control upgrades and additions.....but will not do well in an automotive setting. There is very little...that is "standard"and ...unmodified ....that is computer related that will work consistantly in an automobile. I mention standard....because anyhing semiconductor based or standard pc board system based, that was made for a desk-top, laptop or staionary equipment....will rarely have enough shock,heat or vibration damping to survive longterm in tghe environment a car produces.

The backplane board is a great concept...but is unnecessary at many levels.....and being that MS's ECU case design, is already not a fabulous design as far as heat sinking, vibration damping and dust control....having another opening into the already flimsey ECU case, another set of wire loops, another board etc....will just add to the potential for vibration, heat or dust damage.

For the hundredth time...this is not a slap at MS. Its a nifty system. But if you spend a large amount of time inspecting the ECU designs...especially the enclosures.... over four decades.... that the companies with the most succesful and long lasting factory EFI systems have produced.....you will see patterns in those whose ECU's survive and those that do not.

As far as why is 3-d mapping necessary? Because correct fuel mixture....is a three dimensional problem...regardless of how many or few inputs you have. Many people do not understand this. This is why they have a very hard time figuring out where to start...and have to end up borrowing maps from those who have already done it.....so they can get started. No insults intended.
The primary problem to start with....is that lately....most people first introduction to fuel injection is from the keyboard point of view. Since many are computer literate....the first thought...is that "I can do this no problem"!...its all comuter based! From that vantage point....it simply seems to be a simple input/output table of variables verus range of adjustment. This is not totally correct. The three dimensionality of the problem comes from the fact that the ECU has no ability to change inherent flow, volume or velocity of the intake or engine hard parts....or the fuel fedding system itself. It Only has the ability to react to the baseline parameters of the pre-set size of the fuel and air delivery system , based upon what the sensors tell it is happening. There are no variables in your chart for example....for plenum volume.....unless you have say...a variable volume plenum uising bladders or flaps, that the ECU can control. It also knows nothing about fuel pressure in general. It simply assumes a given pressure...or a range of pressure based upon vacuum. Most corrections via 02 sensor..are after the fact.

The FI system...is three seperate systems. Fuel system (pumps, lines injectors). Air system (manifolds and TB's) , sensor/control system. They are totally (unlike carburettors) seperate...but interact with each other at certain points.
A chart of this would look like three spheres intersecting each other....not three flat two dimenional circles.
The reason added complexity of a board to swap in and out new parts is not really necessary....is because there is just not that much difference needed from system to system and engine to engine...internally to the ECU. Only input outputs need to be changed...to make huge differences at the engine.
For example.... Its not the ECU output changes to the injectors that is capable of making the largest changes in fuel flow...when tuning the same system from a 2.0L normally aspirated to a 3.0L turbo.......its the mechanical devices they drive. The largest inouts to the injectors... would be injector size and fuel pressure. Those two functions....the ECU has nothing to do with.
Most precisely...the input matrix the ECU has in it...is technically two dimensional......but when you add in the mechanical delivery components....its output matrix becomes three dimensional. Sorry for the length. Ray

[davygrvy]

The three dimensionality of the problem comes from the fact that the ECU has no ability to change inherent flow, volume or velocity of the intake or engine hard parts

Very true. Those are the fudge numbers. Given an RPM, a TP, and manifold vacuum (or MAF), use the lookup table to give us the answer for injector ontime (and maybe when for sequential too).

This seems to me to be a better way to do fudge based math and more like how I'd want to spend my hobby time developing.

Say I want a data logger.. Just make a new card with a flash card or a sansdisk then write the code for it.

Say I want a way to talk to the ECU.. mount an IrDA port on the dash and code up a terminal app to run over telnet..

What I want isn't about productizing.. Its about hobbyizing an engine management system.

[davygrvy]

If you run fuelonly and have someone build you the MSkit and do the harness all you have to know is how to read and what size your engine and injectors are.. Rest is how to set it up (hardware) and howto tune it!

For me though, that's exactly what I don't want. I don't want an EEM system that's single use and "just a few tweaks" to get running. I want to tweak the running guts both software and hardware.

[R2.0]

You definitely want to check out MS again. There is MS-II, with ignition control and programming in C, and soom UltraMS, with sequential injection and target AFR control with a wideband o2 sensor.

In addition, there is the aforementioned MS&S-E, which is fuel, spark (multiple methods), AFR targetting, EGT logging, and a lot of other stuff, including hardware hacks and expansion boards. Still coded in Assembler, but these guys are flogging the heck out of that little processor.

[paul_f]

There's nothing wrong with coding things in C, especially since I swim in it daily.

In Europe (and I think the US too) all safety critical automotive software must be written in C and to MISRA guidelines.
The only time assembler is allowed is in low level hardware interface sections, and only if fast execution is essential.

[raygreenwood]

Dave...I see your point in wanting to get an external functionality from an existing system. Say...like adding advance control in a system where it is not already available.
What others are noting...is that the MS-II....(I think they are saying this)...already has that option built in.

But....lets supoose there is another option you want...that is not built in to MS or another system....like....maybe a seperate cold start injector so you don't have to force the system to make difficultpulse width changes that may be above or below the accurate response range of your injectors. Or...even a speed senitive cut-off. Both of those can be done...and have been...in stad alone manner, not attached to the ECU. they are generally more dependable that wya. Of course, there are a lot of other function you could think of that do need to be attached to teh ECU programming.

That also...could be done without an external set up. As long as the system has the room in its matrix for more variables.....you should be able to add them. The object is mainly to convert the signal from whatever function or sensor you desire to use...into an input range that the EcU has an exitsing variable slot for.

For instance....lets say that MS has room for 3 temp sensors in its matrix (I have no idea so I'm just speculating here)...but you are only using one. Say you want an overspeed sensor. Ok...install the sensor....and convert what comes out of it to the same form of signal in the same range
as temp sensor. Then...yes...you will get into the issue of what value in reference to output...the ECU gives that input signal.....but in the dumb eyes of the ECU...its simply another input to add weight to its decision at any given time. It doesn't know hot or cold. Its just a parameter to add into the matrix. If the ECU allows to much wight to the signal....limit the signal. Its simpler than reprogramming...and a lot more linear.

The sandisk idea is cool...but it would as you noted...have to stay somewhere protected. Heat is not the friend of those sandisk units...but they do well with vibration. In the dash will be deadly in the summer.

Just some thoughts. Ray

[jonas_linder]

Well.. I wrote that you can do that .. look in to MSnExtra.. you can controll almost everything.. and more is coming with the switch off the ECU on MS-II !!!

[ZoSo914]

nerd alert Just kidding this really gets me thinking. im so glad you guys all like type 4's too.

[raygreenwood]

I am glad there are some "nerd/Geeks" on here. We need them. I have only dabbled with the after market injections. I know only a little about them...but know a lot about injection in general. We need a good mix of nerds and general FI people. It greatly pays...to understand injection...from the ground up...control systems aside.
The aftermarket has done little or nothing with regard to intake, plenum and TB design.....and even less with fuel supply.
These things are more critical than the control systems by a long shot.....as once they are wrong....they affect everything about how the engine runs...and the ECU.....no matter how programmable....can do little about the oversights in intake design, cam profileor exhaust .
I always suggest that people should prowl the junk yards disecting things...to learn how and why succesful injection systems were designed the way they are. Its not always a money issue. Ray

[davygrvy]

The first big problem I see with the backplane idea is vibration. A car is one of the most hostile environments there is for electronices. I am surprised most MS people have not had way more problems with the connectors than they have.

PC/104 form factor look like a really good way to go so far in place of a passive backplane. At first, I was thinking old-fashioned Vector cards. Fine for custom electronics, but not really a computing style chassis. These guys seem to have it all for PC/104. There's even enclosures , power supplies and even prototyping boards which I can use for setting up the communication logic to the outboard injector drivers and etc. (which probably shouldn't be in the computer case).

Have you looked at the AVR version or the newer, richer, replacement CPU?

No, what's that?