Hi from Canada

[polm]

Hello!
My name's Pierre and I'm a mechanical engineering student. I drive a BMW e34 535i and I'm looking forward in helping with the dev of this great project. I've had 3 programming courses so far: java, c and matlab. I have experience with megasquirt and motec. I just bought a frankenstein board and a chip from digikey and will be assembling all this once I get all the stuff. Looking forward in helping with the development of the speed density algorithm.
Cheers!

[kb1gtt]

Welcome along, and good to hear from you. If you have any questions feel free to ask. Do you have a specific project / engine setup you are looking to get running? While you wait for parts you could start some kind of system schematic. Something that shows how the hip bone and leg bone connect and what wires go where. I once made one using "Dia" a software very similar to Visio. I also tried one with GIMP. I wasn't happy with either attempted. Dia was the better attempt. I post some about it at the below link.

http://rusefi.com/forum/viewtopic.php?f=3&t=360&start=162

Welcome along.

[AndreyB]

Welcome I am shipping your box in an hour.

You would also need a bag of 0805 - see http://rusefi.com/forum/viewtopic.php?f=4&t=212&start=30 You might want to get some soldering paste - see http://rusefi.com/forum/viewtopic.php?f=4&t=425

May the Force be with you for the whole soldering phase

[polm]

Thanks guys! For now I will have my car run as it is using this efi. However, in the long run its going to be turbo, thus my interest for the speed density algorithm. I will be using altium designer for the schematic. Thanks for the link for the 0805s, i'll buy that bag from ebay. I have experience with surface mount soldering already so it should go well! Have youguys ever thought about translating some of the free ems functions into the source code of the rusefi? It could be a good start for functions such as accel enrichment, boost control, etc. Anyway i'll be building my power supply soon and have this baby running in no time!

[AndreyB]

Have youguys ever thought about translating some of the free ems functions into the source code of the rusefi? It could be a good start for functions such as accel enrichment, boost control, etc.

Writing code is not the problem, the problem is knowing what to write... Also I doubt the systems are so compatible. Unfortunately we would need to re-do all this ourselves. Hopefully one day we will figure all this out.

Right now still looking to get reliable fast start

[polm]

Yes what I meant by that was to use the principle of the code of the functions of the free ems. What I mean by "translating" is using their idea (giving them credit of course) for a given function and implementing it in the source code. That solves the part of knowing what to code. You know that X code works for X function, you just have to adapt it for your specific board/chip combo. Of course there are several things to look at while doing this such as the architechture of the chips, the pins and so on, but it's a good place to start in my opinion.

[kb1gtt]

One key difference from FredEMS is that Fred wrote it specifically for the hardware he choose. This has made FredEMS very non-portable. Fred did it that way such that he could leverage some features of that chip, but did it at the expense of porting to another chip. In rusEFI the use of an OS for most of the major features has led to a far more portable system, which can be ported to other platforms more easily. The rusEFI system sacrificed some low end speed and overhead to get this portability as we are relying on some off the shelf drivers provided by the OS. For example, FredEMS could be accurate to something like around .1uS while rusEFI is accurate to around 1uS. At something like 9kRPM .1 degree crank wheel accuracy is around 1.85uS so russian decided that portability to other future platforms was more important than excessive accuracy at very fast RPM's. The STM chip should be fast enough at 9kRPM, so make it portable instead of making it work also at 12kRPM.

The best we could try to use FredEMS is to try to learn the general concepts of what the features are. Then it would have to be re-written from scratch using the OS to implement the algorithm. Because the general algorithms are not Freds work and because we would not be copying Freds work, he would not need credit.

There was another platform out there that might have some portions that could be used, it was called open5XXXecu or o5e. It was written with a basic OS, and many of the OS features might be semi easy to port to this platform. However the way that memory was handled (shared global variables between ETPU memory) is something that russian is not crazy about. It's common for programmers to not like shared global variables, as those have potential for memory leaks, ect. Because of this core difference under the hood, we would again have to recreate everything from scratch and use only the general algorithm concepts.

rusEFI has the ability to have a great many features and great many algorithms for how those features could be implemented. The issue has been priority. Basically what features are most important, and how to implement them in a flexible way. So far russian has been focusing on what he can do with his test mule. Other features require more time resources as he doesn't have direct access to the system.

[polm]

The best we could try to use FredEMS is to try to learn the general concepts of what the features are. Then it would have to be re-written from scratch using the OS to implement the algorithm. Because the general algorithms are not Freds work and because we would not be copying Freds work, he would not need credit.

First, thanks for the detailed explanation, I wasn't quite convinced until I read this. Now I understand what you mean by having to start over. However, using these algorithms could save us a lot of time when writing the functions for this ecu as the general idea of the function is already understood. Therefore, coding it is a lot easier as you alread know what you need to code and what you want to end up with ultimately.

On a side note I ordered this psu which should do the trick http://www.dx.com/p/dc-5-36v-to-dc-1-5-32v-converter-step-down-power-module-142531#.VIKzpjGG9HU
I'll let you guys know what I think of it.

[kb1gtt]

About the power supply, it's probably good enough. I might recommend picking up 2 or three just to play it safe. Often these power supplies are not automotive rated, and voltage spikes that are common in automotive applications could damage your supply leaving you up a creak, and leaving you to pay $20 shipping on a $3 part. So I would recommend picking up multiples to prevent the shipping delay and expense. When I say automotive grade, I mean ISO 7637-2 which includes spikes up to 100V for short periods of time, and dips down to 4V for short periods of time.

On Frankenso, I used that same core switching buck chip, but added some upstream components in my attempt to snup the 100V spikes. So I think you'll get a good enough output voltage, but your board probably doesn't include that upstream surge suppression. Also on Frankenso, I added a PI filter to help remove the bits of ripple it might have.

Sorry about the long winded thing below. I got on a roll and didn't stop for some reason.

About other references, and implementing algorithms, we are trying to learn from many sources of information, then we are deciding what and how we should implement features. For example, below are several algorithms, with descriptions of each.

Algo A, which assumes MAP directly correlates to load. Load directly correlates to your fuel pulse. So 100% MAP = 100% fuel pulse, and 0% MAP = 0% fuel pulse. This makes for really easy math, which can be done very fast gobbling up minimal CPU cycles. However it doesn't quite cover everything, so the real world application is typically fuel pulse = MAP + correction factor. Correction factor can be a number that is increased and decreased based on some sporadic and semi randomly triggered events. For example, TPS was noticed to move rapidly, so XTau wall wetting adjustments need to be made. So when TPS is noticed some bit of code simply goes and adds to that correction factor, which increases the fuel pulse for a while. Or as O2 feedback which can be on the order of seconds indicates rich vs lean, or as IAT changes it lets you know that your MAP is different, ect. So lots of things can semi randomly adjust this correction factor. Then you can update your fuel pulses every rotation at the beginning of the scheduled fuel pulse, as the math will be done before a short pulse has been completed. This algo allows math only when it's needed, minimizing the CPU cycles which can be used for other stuff. Also note that this algo could nearly be done with out the computer. You can nearly take your MAP voltage send it to a Voltage Controlled Oscillator (VCO) which then runs your fuel injector. That would generally provide you with a 90% solution, if you dump extra fuel, you could run an engine this way. So it's a very simple approach. Many people like KISS. Also tuning is easy, you basically tune for low MAP and aim high, then you tune for full MAP and aim high.

Now lets consider Algo B. Which assumes load is based on RPM and MAP. This is the popular table look up thing. Basically at a specific point before your fuel pulse, you go look up the load then use that as your initial fuel pulse. This takes a pinch more CPU cycles than Algo A, but uses less CPU cycles than Algo C. While Algo A can be done with out an MCU, Algo B requires a MCU but can be implemented on some very small MCU's. A down side is that you have to populate that table some how, and most people don't have access to a DYNO. So they will generally use a "butt" DYNO (AKA many passed on a hill if you have one) to find the correct fuel for specific RPM's and and MAP's. You can tune for max power by changing the fuel until it feels like you are hitting peak power for that RPM and MAP. Or you can turn with a WO2 until you get the desired rich / lean. Once you have a pile of points, you then fudge the remaining points by eye ball. Or you keep spending time turning every point. Some people don't like this as you are fudging several parameters. If you fudge in a lean condition, you can cause internal engine damage. If you fudge your fuel to high, you can get a cherry hot exhaust which can ignite combustibles like carpet, oils that may be under your car or on your transmission or your seat. So you can fairly easily damage your car if you don't do this correctly. However it can be done with nearly no math or complicated algorithms, and it can be done by small MCU's, so it's been around for a long time which has contributed significantly to Algo B's popularity. This algo also tends to have that correction factor after the initial look-up table. As your injectors get gummed up, or you get carbon build up, ect, your MAP will become inaccurate. Rather than re-doing the butt DYNO, corrections are typically made based on O2 feedback, temperature, ect. This algo is more accurate at high loads / high RPM's, and less accurate at low RPM and low air flows. So it is commonly preferred for high performance applications, or applications with small diameter intake manifolds.

Algo C would be to simply do PV=nRT calcs and update based on pure math. These types of algo's take more CPU cycles, to get the fuel pulse. They also tend to not be tuned. You generally specify things like bore, stroke, intake air flow resistance, exhaust gasses resistance, ect. You can generally choose your sensors % tolerance and know exactly that your fuel pulse is with a known tolerance on your accuracy. As well when things go wrong, you can generally decode the match to find out what sensor is failing, or exactly where the problem is coming from. As algo A and B are simply fudging this math, you loose the potential to have insight into lower level details. However it takes more CPU cycles and it takes more time to debug the code.

Algo D would be Alpha or MAF while Algo's A to C are speed density instead of MAF. OEM's like MAF as they are very much like Algo A, as the MAF directly correlates to O2's entering the engine, so you directly correlate this to your fuel pulse. OEM's like this as you make one ECU and put it on many engines of various sizes, and cyl counts. There is almost no electrical tuning. Basically you use a MAF sized for your intake, tell the ECU that 1V = blah O2's and your done. MAF provides more accurate measurements at lower air flow rates, so it's typically more accurate at low RPM and low loads.

Algo E would use MAF at low RPM / low load when air flow is moving slowly. Then some how switch over to MAP at higher RPM and higher loads. Many OEM's have started doing this, as emissions are eased for full load conditions. You need power to get into traffic and prevent safety issues, so emissions have been eased up for those situations, while low load requires better accuracy to maintain emissions and regulator issues.

Algo D is To Be Determined. I'm sure I forgot at least one general algorithm. I don't think any of the above include the Long Term Fuel Trim (LTFT) or Short Term Fuel Trim (STFT) that you get from your OBDII scanner. So we'll call Algo D an OEM friendly algo with details that are TBD.

Each Algo has probably 10 different sub algo's. For example, do you calculate the correction factor by adding up all the factors on every cycle? AKA temp correction + O2 correction + XTau correction + blah correction done each rotation, or do you have one correction that can be increased and decreased based on correction events. Such that an even happened, so add some or remove some from the correction factor. Then each rotation only adds or removes what ever number is in that correction factor. Then under that you have to choose if you are going to do floating point math, BIN math, or hexadecimal math. Once these higher level decisions are made, then implementing it is relatively easy. The issue is that once you decide on one approach, you'll have several people that want the other approach. This situation is very similar to the IO issue that russian just solved with the FlexIO. He found a way to allow for people to have a large variety of options with the IO.

So the short version, was "Writing code is not the problem, the problem is knowing what to write." Once you know what needs to be done, writing the code is the easy part. If someone had a setup with a MAP, I'm sure it would be quick work to make it predict fuel. I seem to recall that the code has already been drafted, just not tested and used. The issue is that there is a layer above the fuel predictions that wants to be addressed. The long story short, if you want or need MAP, go for it.

[AndreyB]

Speaking of power supply, please be aware of a known issue with the silkscreen of the screw-in 3 position terminal:

9) "5v 5v GND" silkscreen on the back is wrong - one of the pins is 3v. todo: check power silkscreen on the front

[polm]

I get what you mean by knowing what to code. I personally have only worked with speed density systems where you have to map all the cells of the fuel and ignition tables. As far as i'm concerned, an option like algo a would simply be too limited in the accuracy of the mapping it can provide. Simple factors like humidity which plays a very important roles in the actual amount of air but not so much in its volume, are left unconsidered. Algo b seems like a very viable option. I would imagine this being good as you can add a number of compensations for x conditions which in term leads to a better control over the mapping. There are indeed several other algorithms to work with, however just as you said, the kiss choice is usually the better/more reliable choice. I'm glad to see you guys are well documented, it's nice to be able to talk about what you read in the books to real people!

Thanks for the advice on the power supply.

Oh and yes my goal is to run a map. I'm not so fond of alpha n, its not like my car's a race car... As for maf, you need alot of transient compensations in order to have a car thats drivable.

[AndreyB]

I am hoping to try running the car with SD maybe today maybe tomorrow - the code is there for a while, it's just that no one has tried it on a real vehicle yet.

[polm]

I am hoping to try running the car with SD maybe today maybe tomorrow - the code is there for a while, it's just that no one has tried it on a real vehicle yet.

That's good to hear. I'll assemble everything once i get the parts and make a patch harness so i can swap easily between ecus and perform tests. I have an iat and map lying around also so i'm ready to go. Should be ready within less than 2 months if you consider the resistors should arrive in 3 weeks....