Understand that I'm an idiot here, after all my car is running a Holley Commander 950 ECM. Nonetheless, I assume you have looked at the Motec M880? Also, doesn't Motorola make some fairly advanced engine management systems? Shiny Side Up! Bill
With your goal of 1000hp in a 12 cylinder engine I don't think you need two sets of injectors. (1000hp/.5 BSFC)=500 lbs/hr. 500/12= 41.667 lb/hr/injector. That's ideal of course, so add in a 20% margin and you need 52lb injectors. I've got 50s on the LS3 in my 71 Corvette and the idle is very acceptable. My old motor had 72s on it and I didn't have any issues with those either. If you got rid of that requirement you'll have a much easier time finding an ECU. Here is a link to an ECU that might work for you. It has 16 fuel outputs and will run a V12 sequentially. Also has controls for multiple ignitions including COP and dual wideband o2s. http://wpdemo.org/bigstuff3/wp-content/themes/tesla/pdf/gen3sefi.pdf
My math is about the same as yours. I’m only trying to make 850hp but I’m thinking the duty cycle should need exceed 60% because hp drop when it does giving a 57 lb injector, so 60 lb/hr is a common injector. Then comes the apples and oranges part. If your 72 lb injectors were at say a stable 1.5 ms at idle on a v8, then they would be at about 1.5*8/12= 1.0 ms on a V12 and that is a very unstable and untuneable injection time. Add to that the small cylinders with big valves and you get very poor fuel mixing at low rpm to go with the unstable injection times then throw in reversion for the longish duration cams and you’ve got basically no mixture control at idle. I have run 60lb injectors on a 308 engine (3.0l v8) and with sequential injection it did work okish but far from stellar and that was with stock ports/valves/cams so the best possible situation. Even if it could be made to work with 1 injector per cylinder, and it probably could with some playing and some give on the 60% duty cycle, it doesn’t solve the injector needs to mounted high for hp but low for idle/cruise issue. No, there will be 2 injectors per cylinder and that in not negotiable. It looks like they’ve made some software upgrades since I last looked at it. I would still need 2 of them, but that’s better than 4. I’ll take another look at it, thanks.
I don't think it's a winner. The injector staging control is very primative as are a few other things....the VEMS appears to be a better ECU for a lot less money.
I agree that idle could suffer a little but I think it's an easy compromise given the complexity and expense of the alternative. 60% max duty cycle is extremely conservative, 80% is much more common and tons of people run them higher than that. An 850hp V12 is easy to run on one set. You'd only need 45lbs per injector. Use 42s and turn the pressure up a bit. You can get the flow/pressure from the manufacturer. The Mercedes twin turbo V12 is over 600hp and 720+ ft/lbs and I'm sure that only has one set of injectors. If you're set on 2 sets than more power to you but I think you're over-complicating the situation.
Running a port injector at 85% normally costs about 5%-10% off the peak hp vs a high mounted injector at <60% duty cycle. Yes, if I was willing to set my idle up around 1500 rpm +/- I could run 1 set of injectors, but I'm not willing to do that. All the examples you list I agree would certainly only need 1 injector per cylinder but they simply are not comparable to the engine I'm building for a lot of reasons the most important being turn-down ratio, flow velocity and flow reversion. This is a flat out race engine that will be making 2.5hp/in naturally aspirated which is no small thing. If this was a track engine I would just run the 12 shower injectors and be done with it, but it's not. As I said, 2 injectors per cyl is not negotiable which is why this is the ECU design thread
10-4. Good luck with the project. I've been tuning in to your engine thread periodically and it is captivating to say the least. I have some fab skills but I'm nowhere near your level with the machining and precision.
You're about a year too early, the project for my diploma thesis will probably be designing a ECU Some more practical issues: Have you considered a model-based approach on implementing the software? Today's tools (Matlab/Simulink, ASCET...) are able to generate your code off your models/state charts, so you don't have to write everything manually in C. However, starting completely from scratch would be a bad idea anyway, there are plenty of real time operating systems around, together with an ARM processor for example you're already good to go. The best thing would probably be getting your hands on OSEK, a real time OS that's specifically designed for control units in cars. But I don't know if that's available if you don't buy less than 100,000 licenses A last thing that comes to my mind: If you want it to be completely future-proof, take a look at the AUTOSAR standard. Edit: Just saw this: http://opensek.sourceforge.net/
I don't need it for a year so it sounds like your in then right? Here's the input/outputs. GO! Maybe the way to go is to get you into the diyefi project and up to speed. There is a lot of stuff to get working and they are working out most of it. They don’t have enough drivers on their board, but it appears the processor can deal with plenty so we’re only talking about modifications to proven stuff not a complete system from scratch . Inputs: Crank trigger, hall effect on a 36-1 trigger Cam position, hall effect – 1 pulse per rev TPS , 0-5V Air temp , 0-5V Coolant temp , 0-5v Map senor, 0-5V O2 sensor (4) 0-1V (need to confirm) Wheel speed (4), hall effect with a maybe 6-12 pulses per rev Battery voltage Outputs: Ignition 1-12 Fuel 1-24 Idle control, 2 pwm Tach signal Fault light
I can't commit. I have a family and have no time available. I can help you get started though. Basically you are going to need to take what's in your head and document it using state diagrams and flowcharts. I understand you are trying to get others to design the software, and that's a good plan, but only you can design the logic. By logic I mean the scheme that tells the outputs what to do based on the sensor readings. You need to get that documented in minute detail, in a form that the software guys can understand. For example, for starters you will need to describe the logic for how the ECU establishes the initial state of the engine? Is the starter button being pushed? Is the engine cranking? Is the throttle depressed and how much? Where is #1 piston in its cycle? Is the engine cold or warm? Is the fuel injection system ready to be fired? If you can explain this to me, I'll work up some example flow charts and state diagrams from what you tell me and send them to you next week. I know very little about engine management, but will try to learn something over the next few days while I'm traveling. Same for fuel injection. All I know so far is on Wikipedia. What kind of fuel injection are you using? The more details the better. If you have already detailed this in another thread just link me there. On another topic... you mentioned traction control not being that difficult. I concur as long as it does not morph into an effort to do stability control. But that brings up another topic - networking of multiple processors. Traction control is a different process from engine management and so, to make complex things manageable, it is handled by another CPU, as is environment (heating, A/C), ABS, OBDII communication, etc. All of these processes, running on separaate processors, need to communicate with one another. In a modern automobile, they usually do so using a network called CANBUS. Every sensor and output gets an address so it can be queried, commanded, etc. If you want to have built-in hooks for putting your ECU on a bus of some sort down the road, then you might want to consider ensuring that the software you develop can be ported in the future to hardware that has CANBUS capability. See how this project can grow? The cost, in time and effort, to do this will be huge. Like others have said, this is a BIG project. Best case... if you get several experienced people with some serious hobby time to spare(not me), then you might have some working code a year from now. If you can deal with that, then what you will get will be an ECU that is yours - you can easily modify it and, perhaps best of all, you can design in features that off-the-shelf ECUs don't have. Perhaps you can approach one of the open-source efforts that is already underway and petition them to accommodate the extra features you want. Even if they are already committed to hardware that prevents this, posting your wishes somewhere might attract interest from others and help document the fact that there is a need for a more universal and flexible ECU. Worth saying one more time - this is a B I G project. But judging from what you have already done, you are familiar with big projects.
I love Matlab and Simulink. I just can't afford them! Scilab is close behind and it's free. I'm not convinced starting from scratch would be a bad idea. If you don't need most of the features of a RTOS then having to deal with interfacing with one is not worth the trouble. There is just more to go wrong. Also the idea of using an open source OS means you will have to deal with constant changes. All of this just adds hair to the project. If I were doing this I would keep it simple. As long as the goal is a standalone ECU that only does engine-management, you don't need to develop this within an off-the-shelf RTOS. You can do it all with an interrupt driven state machine. I may change my mind when I see what "The Butcher" has in mind. This is a great suggestion. Remember that the project being discussed here is much smaller. This is just a standalone ECU. (I like the fact that AUTOSAR specifies Flexray as an optional alternative to CAN. Flexray is a deterministic communication scheme. CANBUS is non-deterministic which makes it difficult to do complex digital control algorithms. For those non-control theory folk, this means it does not have the capability to determine exactly when something happened, or conversely, to cause something to happen at a specific time with a high degree of accuracy. When implementing a digital control algorithm, it is important to update outputs on a regular time period. The messages sent over CANBUS can't do this very well.)
I think you underestimate the sheer size of such a project, it's easily as big as the rest of your V12 modification, rather more. Much more. The possible diploma thesis I am talking about would be a ultra low-end ECU for a single cylinder engine (don't know the application, perhaps a bigger lawn mower), and they calculate with 40 hours a week for 6 months. When it comes to car use, it's a lot worse - I know a guy who's currently working on his dissertation, his whole work of 4 years and the base for him becoming a Doctor is one single fault detection module for a special application. You should really investigate if something off the shelf isn't the better (and especially cheaper) way for you. So I'd be in here and there with a bit of advice, but as a whole, that's *far* too big for my taste
Having free access to all those fancy tools at my University, I always forget about the price tag Yes, Scilab is free, but its interface (even in the new version) reminds me of Windows 3.1, it's generally a b*** to use, and I don't know if its code generator (the main reason to use tools like that for such a project in the first place) is on par with the commercial tools. I'm still a student, but my emphases are control theory and vehicle engineering, so I know a bit of both subjects, and I already have some electronics experience. I really think that designing a car ECU is one of these "How hard can it be?" projects that look pretty straightforward at first glance but quickly turn into a nightmare when you realize how many details there are. And Mark is already beginning to talk about special mappings and traction control, only thinking about implementing the latter scares the living hell out of me
We're even, all I know about UML cam from wiki I'll see what I can put together. The basic strategy for both fuel and ignition is very simple and straight forward, at X crank position turn on y injector for z time, repeat. All the inputs other then crank position along with a look-up table are used to calculate the injection time, or ignition timing. Ill put some charts together that show what Im thinking. Back to traction control, I dont think what Im talking about wants to be a separate controller. I basically want to engage the engine rev-limit control based on wheel slip. 4 wheel speed sensors, average the front and rear, if the rear is say <10% more than the front then (semi) kill the engine Ill get this diagramed too, but it can be a later thing.
It won't be a nightware, trust me Seriously, the specail mapping is another layer, but that's all it is. Go to the look-up table and get a number, then multiple. How hard is that
From where do you get your look up tables? One thing I'd suggest is getting your hands on some of the books from the "Yellow Jackets" series of Bosch. There are 2 or 3 afaik covering the engine management topic, showing common control strategies and such things. They're inexpensive and should be a good start. I hazard a guess and say: It won't work that easily. I have a (simplified) diagram on the ASR somewhere, I'll see if I can dig it out.
I hear you, but we have the diyefi guys working very hard writing most of the code and testing it. What Im talking about is a piggyback effort that should use 90% of what they are doing. You arent going to leave me to writing code myself are you .its been 25 years since I wrote my last line of binary code ..
They are a user input, like the primary fuel maps I'll see if I can find it Im talking about a very simple system to control run away wheel spin and Im certain this approach will produce the desired result. There are some inexpensive (about $500) systems out there that will read 4 sensor and mount between the ecu and ignition and simply pull the timing back. Im serious when I say its not that hard
Have you tried contacting these guys? Maybe they'll do it for you, just for fun. Well but someone has to set them up one time, and I think that someone is you...? I'm still not convinced that you will get acceptable results with such a system - maybe they'll prevent wheelspin, but the quality of the control will be crap, such hard cuts usually don't work... however, I'm happy to be taught otherwise!
If I were to go about such an ambitious project - I believe I would try to simulate the dedicated microprocesser system on a PC first...using standard I/O cards available and probably a high level language like C++ for development. Of course you would want to start with an engine test stand dyno, then to a chassis dyno once in the car, and finally on to road testing. All the while, the PC would make it ten thousand times easier to develop the system than changing assembly code and modifying it on the fly in a miniturized dedicated controller. Second step would be to design an ECU which would emulate the original action of your test system. Third step, of course, would be to do some very stringent environmental testing - heat, cold, G force, vibration, etc. on your developmental hardware. While I have never done such a system for automotive application, this is what I used to do when making up micro-controllers for magnetic tape drives, NC machine tools, printers, lab equipment, military stuff, etc. Nowadays I am strictly in software, as not many hard electronics engineering jobs are still around here in the U.S. But we can still dream about the bad old days!!!
I'm trying. They are in the middle of the gen 1 development and I'm certain will not be interested in what would be a gen2, but I'm also certain I can get some input into the code that will be helpful. Yes me. putting the lookup tables in place is the programming, filling in the lookup tables in the user, me or whoever. Ahh....I was talking about a "soft" rev limiter earlier and that is what I'm talking about here. It work by saying at 9300 you start to take action and by 9500 it's a hard stop. So at 9300 you drop fuel to a cylinder every say .5sec, at 9350 its every .25 sec, at 9400 its every .125 sec at 9450 its evey .0625 sec and at 9500 its all off or something like that. So you loose a larger % of the power the closer to hard stop or in this case the farther from the allowed slip %.
Can you suggest some good free or inexpensive documentation tools? Visio has UML templates, but it would be nice to have something that would nest state diagrams. At the highest level, the whole thing would fit on one page. Each state on that page could then be exploded into another state diagram on another page, etc. I haven't done this in a long time, but I'm guessing there is stuff out there that does this now? I'm not concerned about linking to a code generator, just a "telescoping" state machine documentation tool.
Very good idea, but with limits because you can't verify any critical timing parameters. For bench testing time critical applications I always built in test points (write out to extra I/O pins, etc.) and then monitored them with multi-channel scopes, op-amp circuits, etc. For example, you can put an op-amp and a tiny speaker across an I/O pin and listen to an engine rev as you toggle an extra I/O pin while you fire the ignition. Or you can put an RC circuit with an LED out there to monitor PWM. All sorts of things you can build into the firmware to make it easy to monitor. As far as re-assembling/re-compiling and uploading, etc. yep you still have to do this, but the newer development systems make this very easy. It might be useful to design this software to work on 4,5,6,8,10, and 12 cylinder engines. You set switches at assembly time, along with other options. Then you could put a cheap 4-cyl. motor on a stand and debug portions of the software. If something goes terribly wrong early on you damage the guinea pig. Of course some things just wouldn't be the same. I need to locate and read the thread on MKE's engine so I know how it is setup. Anyone have it at hand?
