True programable ecu ?

[chris_rg]

Perhaps an application for some sort of PID control? or perhaps a straight PD as im not sure where you would get your feedback loop from.

Without getting too far into it, I can't see how the 2nd deriv is useful, perhaps a quick explination you can let me know what you were trying to acheive? I could just be slow and missing the point!

Yeah its only an open loop system, there is no feedback. The aim is to calculate (based on previous trigger events only) how far in advance to start charging each of the four coils so that they get the correct dwell time. The efi computer only puts out when it wants the spark trigger, not when to start charging coils, designed for use with a 'smart ignitor'. If the engine speed is constant you can just interpolate it linearly to predict the charge point. However with this system you will see on the oscilloscope changes in engine speed cause the dwell to either disappear or go way to large. Since disappearing happens when accellerating, its not good. So from here you start looking at the derivatives, etc etc...

Anyway, i guess the point i was trying to make is that something seemingly simple can turn out a lot harder to do efficiently and elegantly when you actually start working on it.

However, we did get it going a lot better. Just a bit of time involved.

Another example of a really interesting automotive control problem is boost control. Thats where you do get quantitive feedback and PID or PD controllers must be the go. I don't have much to do with turbo cars, but always wondered if those aftermarket boost controllers use PID loops, should mean you get less lag (fast rise time). Of course they could get fiddly to tune for each unique car.

Cheers
Chris

[Cressida91GLX]

I was a fan of Micro untill I worked on a FPGA and boom. The results are so outstanding and the best part is they never hang

Yeah price I mentioned it is not 1/4 it is I guess 1/4000. Lol as FPGA are for design and ASIC is to be fabricted in IC fabrication plant( bigg $$$). Just a thought if you need high resolution with nanosec accuracy than it is for you. But for micro sec accuracy I reckon 8086 ( moto series) might do the job for you.
It is so damn expensive that toyota don't put them in the car so go figure!

[chris_rg]

FPGAs are certainly awseome gadgets, I implemented a simple MIPS style microprocessor from gate level on one. It allowed me to define "hardware" based reconfigurable instructions for special pruposes, depending on application.

Never hang... lol... that depends on how its configured, FPGAs are a generic 'sea' of logic. If i make a mistake in the VHDL on the microprocessor above it will most certainly hang in exactly the same way a normal micro does if the designers fuk up. Or if your not using a complex state machine they call a 'processor' and just using combinational logic, you can still make mistakes.

[Earlyrolla]

The MPC555 is not a friendly micro for the backyard DIY person. For starters it mounts to the board through a BGA (ball grid array) so there definitely won't be any hand soldering going on and secondly to make proper use of its functionality you will also have to learn how to program the TPU (time processor unit) which I have been told from the senior engineers where I work it is difficult even for a good programmer.

That said I quite like the MPC555 based ECU at work as it is reasonably powerful and I have been become pretty familiar with it now. For a bit of reference I spent about 3 months writing the control level software for a particular application for an air assited direct injection engine but this has a lot of extra strategies involved and a few 'tricky' bits.

This control system had about 45 files in it, I have seen other engine control systems from automotive ECUs with over 1000 files in.

IIRC the people who originally wrote the operating system for the micro spent about 6-9 months on it full time.

The AVR as I have been convinced by Nick (made his own ECU based around one) is a great micro for the DIY person as the compiler can be obtained for free and any competent person could solder the chip onto a board. The top end AVRs are more than adequate to run a port injected engine up to some pretty good speeds (easily 7000RPM). Provided you are disciplined with the programming and you will probably have to write your own math libraries etc to make the code more efficient there is no reason why the AVR is not a good starting point.

Just for comparison, the average IDE (integrated developement environment) for the 16 bit micro I looked at were around $5000, one of these will be needed to build your code. Compare that to $0 for the AVR.

It is one thing to make an ECU to run an engine, it another to make that will be reliable under all operating conditions. In designing the circuits required to interface the micro to the outside world things like radiated noise, coupling of tracks on the PCB, routing of heavy current tracks, routing of analogue tracks and routing of digital tracks are all important.

I don't think the PIC is very good idea, probably a bit limited in memory and execution speed to run an engine efficiently.

As for the dwell time calculation. Sounds a little complex to me. Would you be better off having a map of dwell time versus engine RPM and compensate for battery voltage with an extra factor? For a port injected engine, sensitive to dwell is pretty good (so I have been told by engineers at work) so being out by little bit isn't going to make much difference to combustion.

That is one of the things with ECUs, it is not a good idea to do any floating point maths or complex calculations as it chews up precious processor power. Better to use maps where the application suits it. I.e. instead of calculating the derivative of the third power of the ... just approximate it in a map and look the map up based on what it is a function of. It may not be perfect but the engine wont care.

Ahh yes, nanosecond precision, why bother? The difference calculating fuel to the nearest micro second is more than adequate for any engine application. I doubt you will ever notice the difference in driveability or emissions. There is no use using excessive precision.

Probably carried on too much there

[Cressida91GLX]

yeah too much for some people *lifts hand*

[thechuckster]

just to add some fuel to the discussion: open-source engine management system (not that i'm a supporter, merely an interested observer): VEMS

...DIY engine performance became very popular at around 2000-2001 with entry-level injection-only (batch) systems, that VEMS took to a different level with the added functionality of sequential injection ignition, direct ignition, WideBand O2, Detonation Detection and Exhaust Gas Temperature sensing and included space for hardware expansion and customizable functions.

(from www.vems.hu/ or www.vems-group.org)

It manages sequential injection and ignition timing on up to 8 cylinders, complete with 2 channel wideband lambda controller. It can be configured to run fuel injected engines and manage or monitor stuff like boost control, nitrous control, idle speed, knock detection and exhaust gas temps...

Would be an interesting thing to look at except that EU to AU currency conversion makes it somewhat expensive.

however, the development process and the method of sharing data, experience, modification, etc via a wiki is novel and interesting. It does tend to force participants to be highly knowledgable of the system and hardware.

[Cressida91GLX]

And I have heard that there will be viruses shortly travelling into the car ECU and imagine a 2020 Bug where your car decides to teach you a lesson ..... Possiblities are endless with Computer.

[oldcorollas]

i think you guys should read the current (as of jan) state of MS... it's come a long way since i was up to date with it!!

http://www.msefi.com/viewtopic.php?t=15011

[chris_rg]

As for the dwell time calculation. Sounds a little complex to me. Would you be better off having a map of dwell time versus engine RPM and compensate for battery voltage with an extra factor? For a port injected engine, sensitive to dwell is pretty good (so I have been told by engineers at work) so being out by little bit isn't going to make much difference to combustion.

Ah, yes and no. The dwell time is not the problem, in my sitation dwell time was constant. It was the time before trigger event to charge coil we are calculating (ie ignition advance time + dwell time = time before top dead centre). You can't use any 'map' for this, because its the transient events that cause problems. I need a diagram. We didn't get as far as battery compensation, but thats easy.

We mainly use PICs at my work, but the devices are fairly simple. They are a very elegant design, not the must powerful things out there though.

The latest megasquirt stuff is getting very interesting indeed. The CAN network stuff especially. But i don't really have an application for it.

[chris_rg]

EarlyRolla,

Do you mind me asking who you work for? there is not a great deal of embedded control systems designing done is australia.

Cheers
Chris

[Earlyrolla]

Orbital Australia.

Yeah not many places in Australia. The only other place in Perth is AEC.

Re-read your post again (plus a bit more awake today) so got a better idea of what you are doing now. I can see how it would be difficult only using the trigger from the ECU and working backwards during transients. Sounds like your ideas are pretty good, I assume you are trying to compensate the dwell time based on engine acceleration during transients?

Pity you can't use the crank position sensor signal from the ECU to give you better angular resolution (easier to detect engine acceleration). Maybe fit a second crank sensor dedicated to your ignition module or tap into the original signal?

I wasn't trying to dismiss PICs overall, just thinking the RAM and processor power would be a limiting factor using one to control an entire engine management system.

The MS stuff looks good at first glance.

[thechuckster]

Pity you can't use the crank position sensor signal from the ECU to give you better angular resolution (easier to detect engine acceleration). Maybe fit a second crank sensor dedicated to your ignition module or tap into the original signal?

fwiw: the 24 tooth toyota dizzi wheel, or the 32 tooth EDIS crank wheel gives you reasonable resolution. Bosch also use 62 teeth crank wheels to provide accurate crank positioning (accompanied with a single-tooth cam wheel).

32 tooth wheel going into my 18R so i can run waste-spark...

wheel roughly fitted to work out what to change on sensor mount:


trigger wheel showing missing tooth for crank positioning


For the MS setup, you can remove two of the teeth on the wheel inside the dizzi to create a 12 tooth crank wheel (2 crank rotations per 1 dizi rotation requires). As the dizzis that easily fit the 18R dont have the 24 tooth wheel, i decided to get an EDIS wheel from the states.

[timbosaurus]

I know what you mean about the MPC not being user friendly... It's certainly something you need a development kit for, and there goes a fair wad of cash straight away!

Looking back, until the likes of AVR's came along with their reliable IDE using open source GCC, simulators, libraries and home made programmers (all absolutely free!) and hardware in-circuit real-time debuggers/programmers for around $50USD(!), there wasn't really any other option! Everytime I use AVR's i smile at how easy, user friendly and cheap a development environment can be!

Speaking of BGA's, some ppl are very good at what they do... the tech I work with has few problems soldering them just with a little bit of ingenuity, solderpaste, steady hands and a hairdrier! But then again, he's pretty damn skillful. i'd have no hope!!! I think a bigger problem is making a home made board capable of such a fine pitch.

The dwell of a system should be constant (except for battery voltage compensation) with respect to rpm. one of the major problems with points was the dwell at high rpm's being a 10th of that at idle! So for engine management a fixed dwell is fine!!

[takai]

Quite a few years ago now i managed to write a fairly kludgy ECU on a PIC. Except i only had 1 input to run off (TPS) and was only using a single injector as output. But the state-based scheduler was running at under millisecond accuracy, with most A-D conversions taking in the order of 10-15microseconds, and D-A the same.
Ive since used that same scheduler to put together a simple sweeping robot, and when i get around to it im going to build an automagic vacuum cleaner out of it. But thats a digression.

The biggest advice i have to give for anyone even attempting to write your own ECU is to learn about state-machines/automata and rigouous(sp) programming and specification. Even a simple state machine can do quite well (as it did for me), even if you are only controlling a lawnmower engine.

[Cressida91GLX]

yeah state diagrams rocks. My only problem is that I never take in to account any thing when I sit for programming... All the state, program structure and upward/downward compatibility goes to hell. When it starts working than I have got little motivation left to improve/ make it more structured.

And I am never able to understand other people code that is why it takes me less time to program the same thing than to understand other people code.

And debugging a hardware error which appears randomly sucks big time and sometimes you just want to set every thing on fire.... That is why now I am going towards alogrithm/ development and evluation of systems. It seems easy but the whole bit of probabillistic modelling makes it even worse.