Nice to see another option in this space. I shall have to come back to this when it comes time to resume on various engine-related projects I have on backlog.
A question for any of you more familiar with this project: Does it support MAF sensors for measuring intake air? Or is this purely a speed-density system? Scanning the documentation, I see mention of different MAP sensors, but a search finds nothing for MAF sensors. If this is presently only a speed-density system, is support for mass airflow on the roadmap, or this intended to remain only a speed-density system?
At this stage it's Speed-density / Alpha-N only and I don't have any real plans at this point for adding MAF support I'm afraid.
The easiest way if you really want to keep the MAF would be to use a hardware based frequency to voltage converter and such devices do exist. Otherwise, any reason not to convert to MAP?
> Ever wondered why black box, aftermarket engine management systems can cost thousands of dollars?
There’s actually a pretty good reason. I can’t imagine starting a new engine management project in 2020 without using an FPGA to interface with engine positioning sensors and outputs. Modern engines tend to be way too complicated to coordinate without paying close attention to your modeling of where all the fast moving mechanical bits are currently.
It’s cool they released this as open-source but the tech would have been novel circa 1992.
I'm not aware of any aftermarket EMS's using FPGAs, and there are quite a lot of them. The engine position sensing isn't something that requires a lot of specialized hardware: The sensors are usually one or two reluctors or hall effect sensors that give, say, 12 to 64 clock edges per engine rotation. Determining engine position is pretty easy with most microcontroller's built-in timers. I know that megasquirt, and freeems use hardware timer capture inputs for this purpose.
It is certainly something that is easy to cause engine damage if you get it wrong, but the application for these is usually offroad vehicles. There is a community of people that do convert their engines to use these systems. I've eyed rusefi for a while, I've personally used freeems, and even started to write my own EMS for fun (https://github.com/via/viaems/).
I don't think engine position sensing has changed even with the most modern engines, though the direct injection engines certainly have more specific timing requirements for fuel injection.
I looked closely at FPGAs and they have their pros, but they add a lot of complexity as well. Keep in mind that the original idea with this was to be able to load the entire system onto a cheap board and be able to test it on the bench without any extra hardware (Obviously not on an engine).
The other major reason not to use one is simply because these days I'm not sure they're really needed. The 'high speed' inputs to an ECU really aren't that fast, even at the highest end you're only looking at somewhere around 16Khz. With high speed MCUs (70+Mhz) available for a couple of dollars, the value in the FPGA is somewhat limited given the complexity of adding them.
I work on ECUs and surrounding software for various smaller engines, and it requires a lot of massaging, but you can scrape the bottom of the barrel and still get alright results. An FPGA isn't strictly necessary, save maybe some extreme cases in the high end of the automotive market. If you happened to have the expertise on hand, it may be easier, but you can certainly make do without one.
Well, My 1999 motorcycle (Kawasaki Concours ZG1000) is still carbureted.. If there is an affordable product to improve fuel efficiency and reduce emissions without giving up my privacy to corporate black boxes I would totally be interested.
I'm not sure the inputs and outputs are that much more complicated now than they were in the 90's. Cam/crank position sensors, knock sensors, O2, MAF, TPS, etc, on the input side. Outputs, I suspect, haven't changed that much either. Variable valve timing, running on fewer than all cylinders, etc, isn't all that new, and the other outputs (injectors, spark, and so on) haven't changed. They got by with MCUs and EEPROM maps for a long time.
While I love that this is possible you have to be very literate in electronics for this to make sense. A lot of car guys just aren't going to rip apart their wiring harnesses and do testing to make sure it'll work with their onboard sensors. That being said I'm currently looking into this for a turbo econobox. Haven't decided whether to go this route or a standalone but I still have plenty of time to source parts.
>A lot of car guys just aren't going to rip apart their wiring harnesses and do testing to make sure it'll work with their onboard sensors.
I'm not so sure about that.
My go-to mechanic is an older gentleman, late 60s, and oftentimes I'm surprised how quickly he updated his workshop to include electronics. He went from barely having a multimeter and not knowing how to use a computer in the early 2000s to having a well equipped electronics bench with oscilloscopes, scan tools, soldering equipment, etc. He told me he went to a bunch of courses to get updated on modern car technology because his clients started bringing newer cars. Keep in mind this is in a developing country (Mexico) so he has to keep repair costs down to keep clients, because the more affluent people will go to dealerships to get a proper fix. A lot of his repairs that I've seen involve what I'd charitably call "bodging" using parts that aren't original or intended, but they get the job done on a budget.
Similarly with car guys I hang around here, there has been a noticeable uptick in electronic knowledge, maybe not to the level of custom ECUs yet, but stuff like making an arduino controlled radiator fan or making a custom box to read the CAN-bus to get the steering wheel controls do stuff they weren't intended to do is pretty commonplace.
People working with cars are already used to complexity and learning new things, after all, so I don't think electronics will scare them off. We don't see as much of it yet because of all the lockdown and manufacturer's insistence at straight up replacing parts, but now that modern-style fully electronic cars (2010 or so) are becoming affordable enough to be "project cars" for average car guys, we'll see more and more stuff like this. A car guy might not want to rip into the wiring harness on his daily driver that he paid 15k for, but a 3k shitbox he bought as a second car for fun? Well, people are already doing that.
To be fair, it seems to me that most car guys are not necessarily literate in electronics. And for them, there's various aftermarket options that are a bit more plug-and-play than this. And that is fine, IMO. But for nerds like me whom are inveterate tinkerers, and familiar with both engines and electronics, there's projects like this.
I've been looking at EFI options for a 427 ci stroker Windsor build so this is very interesting to me, but I'm curious really how much effort it would be to put together a working system for this vs. just buying something like a Holley Sniper EFI.
This is really neat!
About 13 years ago (when I was a late teen) I was really keen on the whole engine management idea, and tried to wrap my head around megasquirt.
Today I'm running diesel lumps from the late 70's (Land Rovers) so can't really use this even tho it would be really cool. Makes me want to get a small petrol engine from a scrapyard to play around with this.
A note: took me a little too figure out which MCU this is build around. Surely it couldn't be the classical AVR arduino, but yes, it's a ATMega 2560.
This is neat, I've been daydreaming about this being possible to make for years now. Practical? Probably not, hard to beat a multi million dollar budget, but still, neat.
I've been looking into this for my Miata. There are a few plug and play options for hardware that you can buy from small companies. This is all platform dependent of course.
https://speedyefi.com/
This is super cool. Much like the Raspberry Pi, I could see this as a way for non-developers to start getting interested in FOSS software/hardware hacking.
Managing spark advance/retard, injector "on" duration, idle speed, etc, based on lots of sensor readings (knock sensors, o2 sensors, mass air flow readings, throttle position, rpm, engine temp, boost pressure, etc).
If you, for example, improve airflow in your car drastically, or install larger injectors, or a high flow exhaust...the stock ECU code/maps may not be flexible enough to optimize for that. Also for bolting fuel injection onto an engine that was previously had a carburetor.
They make the source available, but it's not under an open source license. You can't modify it, copy it, run it on your own hardware etc. They basically just make it available so that people can help find issues for their own products.
donquichotte|6 years ago
[1] https://github.com/noisymime/speeduino/
[2] https://github.com/onesk/ms3-source
[3] https://github.com/rusefi/rusefi
VectorLock|6 years ago
korethr|6 years ago
A question for any of you more familiar with this project: Does it support MAF sensors for measuring intake air? Or is this purely a speed-density system? Scanning the documentation, I see mention of different MAP sensors, but a search finds nothing for MAF sensors. If this is presently only a speed-density system, is support for mass airflow on the roadmap, or this intended to remain only a speed-density system?
noisymime|6 years ago
The easiest way if you really want to keep the MAF would be to use a hardware based frequency to voltage converter and such devices do exist. Otherwise, any reason not to convert to MAP?
asguy|6 years ago
There’s actually a pretty good reason. I can’t imagine starting a new engine management project in 2020 without using an FPGA to interface with engine positioning sensors and outputs. Modern engines tend to be way too complicated to coordinate without paying close attention to your modeling of where all the fast moving mechanical bits are currently.
It’s cool they released this as open-source but the tech would have been novel circa 1992.
matthewvia|6 years ago
It is certainly something that is easy to cause engine damage if you get it wrong, but the application for these is usually offroad vehicles. There is a community of people that do convert their engines to use these systems. I've eyed rusefi for a while, I've personally used freeems, and even started to write my own EMS for fun (https://github.com/via/viaems/).
I don't think engine position sensing has changed even with the most modern engines, though the direct injection engines certainly have more specific timing requirements for fuel injection.
noisymime|6 years ago
The other major reason not to use one is simply because these days I'm not sure they're really needed. The 'high speed' inputs to an ECU really aren't that fast, even at the highest end you're only looking at somewhere around 16Khz. With high speed MCUs (70+Mhz) available for a couple of dollars, the value in the FPGA is somewhat limited given the complexity of adding them.
seabird|6 years ago
jascii|6 years ago
unknown|6 years ago
[deleted]
tyingq|6 years ago
westmeal|6 years ago
temporaryvector|6 years ago
I'm not so sure about that.
My go-to mechanic is an older gentleman, late 60s, and oftentimes I'm surprised how quickly he updated his workshop to include electronics. He went from barely having a multimeter and not knowing how to use a computer in the early 2000s to having a well equipped electronics bench with oscilloscopes, scan tools, soldering equipment, etc. He told me he went to a bunch of courses to get updated on modern car technology because his clients started bringing newer cars. Keep in mind this is in a developing country (Mexico) so he has to keep repair costs down to keep clients, because the more affluent people will go to dealerships to get a proper fix. A lot of his repairs that I've seen involve what I'd charitably call "bodging" using parts that aren't original or intended, but they get the job done on a budget.
Similarly with car guys I hang around here, there has been a noticeable uptick in electronic knowledge, maybe not to the level of custom ECUs yet, but stuff like making an arduino controlled radiator fan or making a custom box to read the CAN-bus to get the steering wheel controls do stuff they weren't intended to do is pretty commonplace.
People working with cars are already used to complexity and learning new things, after all, so I don't think electronics will scare them off. We don't see as much of it yet because of all the lockdown and manufacturer's insistence at straight up replacing parts, but now that modern-style fully electronic cars (2010 or so) are becoming affordable enough to be "project cars" for average car guys, we'll see more and more stuff like this. A car guy might not want to rip into the wiring harness on his daily driver that he paid 15k for, but a 3k shitbox he bought as a second car for fun? Well, people are already doing that.
korethr|6 years ago
travbrack|6 years ago
microcolonel|6 years ago
VectorLock|6 years ago
martinmunk|6 years ago
A note: took me a little too figure out which MCU this is build around. Surely it couldn't be the classical AVR arduino, but yes, it's a ATMega 2560.
NietTim|6 years ago
tabiv|6 years ago
farisjarrah|6 years ago
tyingq|6 years ago
virgil_disgr4ce|6 years ago
tyingq|6 years ago
If you, for example, improve airflow in your car drastically, or install larger injectors, or a high flow exhaust...the stock ECU code/maps may not be flexible enough to optimize for that. Also for bolting fuel injection onto an engine that was previously had a carburetor.
Grazester|6 years ago
matthewvia|6 years ago
noisymime|6 years ago
leafmeal|6 years ago
unknown|6 years ago
[deleted]
tyingq|6 years ago
chrisMyzel|6 years ago
akeck|6 years ago
westmeal|6 years ago