Speeduino: Open-Source Engine Management(speeduino.com)
speeduino.com
Speeduino: Open-Source Engine Management
https://speeduino.com/home/
57 comments
I'm curious what the big differences between these 3 are?
There's a few. A big reason why Speeduino and RusEFI exist as open source projects is that Megasquirt, whilst they make the source available for viewing, is very much NOT under an open license. You can't use it on anything but their hardware, can't modify it, can't copy it etc. It's also quite hardware specific with big chunks of assembler in it.
Speeduino started as a way of getting a DIY ECU that was far cheaper than what Megasquirt offerred and it's currently about 1/3 the price. It's not on the same level for features at the moment, but I do new firmware releases every 2 months or so with more functionality etc.
Speeduino started as a way of getting a DIY ECU that was far cheaper than what Megasquirt offerred and it's currently about 1/3 the price. It's not on the same level for features at the moment, but I do new firmware releases every 2 months or so with more functionality etc.
I’ve been watching Speeduino for a while now and the amount of progress you guys are making is insane.
Keep up the good work. I currently run/tune Megasquirt in several cars, but I’ve been waiting to give Speeduino a shot.
Keep up the good work. I currently run/tune Megasquirt in several cars, but I’ve been waiting to give Speeduino a shot.
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?
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?
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.
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 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.
[deleted]
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 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.
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'm not aware of any aftermarket EMS's using FPGAs, and there are quite a lot of them.
Engine management has been using PLDs/FPGAs for years.. look at Autronic, Syvecs, Pectel, and a bunch of research engine management systems that are too expensive for mortals to buy. If you're building something in 2020, you'd be shortsighted to not put an FPGA between the engine position inputs, and your time-sensitive outputs.
> The engine position sensing isn't something that requires a lot of specialized hardware ... Determining engine position is pretty easy with most microcontroller's built-in timers.
Modern engines are not mechanically monolithic. Cams and cranks are coupled, but they're subject to tolerances and are affected by things like acceleration, belt stretch, and harmonics at different RPM ranges. Determining what's /actually/ going in inside an engine with any accuracy is not easy at all; thinking otherwise is naive.
> 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.
I don't see a connection in the two points of this statement. The 'offroad vehicles' I work with, have engines that are 10x the cost of the 'onroad' equivalent.
Engine management has been using PLDs/FPGAs for years.. look at Autronic, Syvecs, Pectel, and a bunch of research engine management systems that are too expensive for mortals to buy. If you're building something in 2020, you'd be shortsighted to not put an FPGA between the engine position inputs, and your time-sensitive outputs.
> The engine position sensing isn't something that requires a lot of specialized hardware ... Determining engine position is pretty easy with most microcontroller's built-in timers.
Modern engines are not mechanically monolithic. Cams and cranks are coupled, but they're subject to tolerances and are affected by things like acceleration, belt stretch, and harmonics at different RPM ranges. Determining what's /actually/ going in inside an engine with any accuracy is not easy at all; thinking otherwise is naive.
> 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.
I don't see a connection in the two points of this statement. The 'offroad vehicles' I work with, have engines that are 10x the cost of the 'onroad' equivalent.
> If you're building something in 2020, you'd be shortsighted to not put an FPGA between the engine position inputs, and your time-sensitive outputs.
Why? Without supporting information this sounds like cargo-culting. What are the timing requirements and why can't they be achieved with current microcontrollers?
Why? Without supporting information this sounds like cargo-culting. What are the timing requirements and why can't they be achieved with current microcontrollers?
Because the FPGA makes your life easier,.. reasons off the top of my head:
- Trivial reconfigurable pinout for different input sensor and output driver use cases (e.g. DOHC direct-injected V6 vs. 4 rotor rotary engine with split ignition and staged injectors). The physical output drivers can be made universal, but making the software dynamic and correct is challenging. No, being able to reconfigure GPIO muxes on an AVR isn't the same.
- Truly parallel calculations (e.g. engine rotation modeling, engine aspiration modeling) and parallel driver outputs. Possible in a multi-core "microcontroller", but now you're synchronizing things.
- Ability to easily create complex chained high resolution timers for input capture, and outputs. Certain microcontrollers have hardware to do this (e.g. STM32F334) but you're limited by what the designers had in mind (e.g. the F334 was designed for digital power conversion).
- Ability to do PID and other complicated math with sensor feedback in specialized hardware (see: parallel calculations above). Try implementing flexible knock sensing for a complex engine without a dedicated DSP. It sucks.
It's one thing if you're building a product for production, with one specific application and pricing constraints, but these aftermarket ECUs tend to have many applications as almost every use-case is in some form a 'one off'.
FPGAs are cheap now. It makes sense to use them. They help prevent you from having to write a ton of interrupt handling code that looks like node.js call-back coleslaw.
- Trivial reconfigurable pinout for different input sensor and output driver use cases (e.g. DOHC direct-injected V6 vs. 4 rotor rotary engine with split ignition and staged injectors). The physical output drivers can be made universal, but making the software dynamic and correct is challenging. No, being able to reconfigure GPIO muxes on an AVR isn't the same.
- Truly parallel calculations (e.g. engine rotation modeling, engine aspiration modeling) and parallel driver outputs. Possible in a multi-core "microcontroller", but now you're synchronizing things.
- Ability to easily create complex chained high resolution timers for input capture, and outputs. Certain microcontrollers have hardware to do this (e.g. STM32F334) but you're limited by what the designers had in mind (e.g. the F334 was designed for digital power conversion).
- Ability to do PID and other complicated math with sensor feedback in specialized hardware (see: parallel calculations above). Try implementing flexible knock sensing for a complex engine without a dedicated DSP. It sucks.
It's one thing if you're building a product for production, with one specific application and pricing constraints, but these aftermarket ECUs tend to have many applications as almost every use-case is in some form a 'one off'.
FPGAs are cheap now. It makes sense to use them. They help prevent you from having to write a ton of interrupt handling code that looks like node.js call-back coleslaw.
> 4 rotor rotary engine with split ignition and staged injectors
Please tell me you've got a link to some place I can read more about this, I'm a huge Mazda fan.
Please tell me you've got a link to some place I can read more about this, I'm a huge Mazda fan.
These guys[0] are building them in the US. There's also Pac Performance[1] down in Australia.
[0] http://www.definedautoworks.com/mazda-rx7-engines-4-rotor.ht...
[1] https://www.pacperformance.com.au/
[0] http://www.definedautoworks.com/mazda-rx7-engines-4-rotor.ht...
[1] https://www.pacperformance.com.au/
I appreciate that FPGAs are certainly one way of doing this, and your point are valid, but I respectfully disagree that it is an overall better approach. FPGAs are more expensive than these microcontrollers, are a separate device to program, and now mean you have to maintain both software and RTL together. I also don't believe that any of the issues you describe are very difficult to do in pure software:
- reconfigurable pinouts, why is gpio muxes not the same? I understand that if you want to be extremely flexible with pwm'ing peak and hold injectors, that is probably easier with an intermediate hardware interface, but all the other output settings seem trivial to change in software
- I would argue parallel computation isn't really even necessary. These chips are fast, and the computations aren't that intense. That aside, I personally manage that parallelism by using the dma controller to bitbang outputs
- Chained high resolution timers -- I'm not really sure where you're going with this. I personally dma input capture timestamps, and can't imagine needing more precision.
- PID and other software. If you're talking about an AVR, I completely agree that these chips are largely too anmemic by themselves, and extra hardware would help. A modern cortex m4 or m7, however, has plenty of oomf, and it all goes back to maintainence cost of software vs RTL+software.
Either way, FPGA's are certainly a valid way to solve these problems, but personally I like not being locked into specific hardware arrangements. My design is just a hobby design that nobody should use, but it can easily manage 1/4 uS output precision with plenty of spare cpu capacity.
edit: as an additional aside, its pretty hard to have a free and open source project if you depend on an fpga. The toolchains are all proprietary, which would limit the goals of a project to something like the lattice with the icestorm toolchain.
- reconfigurable pinouts, why is gpio muxes not the same? I understand that if you want to be extremely flexible with pwm'ing peak and hold injectors, that is probably easier with an intermediate hardware interface, but all the other output settings seem trivial to change in software
- I would argue parallel computation isn't really even necessary. These chips are fast, and the computations aren't that intense. That aside, I personally manage that parallelism by using the dma controller to bitbang outputs
- Chained high resolution timers -- I'm not really sure where you're going with this. I personally dma input capture timestamps, and can't imagine needing more precision.
- PID and other software. If you're talking about an AVR, I completely agree that these chips are largely too anmemic by themselves, and extra hardware would help. A modern cortex m4 or m7, however, has plenty of oomf, and it all goes back to maintainence cost of software vs RTL+software.
Either way, FPGA's are certainly a valid way to solve these problems, but personally I like not being locked into specific hardware arrangements. My design is just a hobby design that nobody should use, but it can easily manage 1/4 uS output precision with plenty of spare cpu capacity.
edit: as an additional aside, its pretty hard to have a free and open source project if you depend on an fpga. The toolchains are all proprietary, which would limit the goals of a project to something like the lattice with the icestorm toolchain.
We can agree to disagree on engineering choices. I've been working on/with aftermarket ECUs for just under 20 years, and I'm sharing with you what I've seen from being "in the trenches".
The category of person that is going swap out their ECU cares about sub-milisecond timing. FPGA's are good at concurrency and operating in this domain. 8-bit 16Mhz Arduino's are not.
Check out this HCCI engine tuning algorithm which runs 240,000 samples per second to provide realtime feedback to an fpga/raspberry pi hybrid board. An Arduino just ain't going to cut it: https://www.raspberrypi.org/blog/machine-learning-engine-con... - at $40 for an TinyFPGA BX it's probably worth it vs the Arduino pro-mini at $10 if you're going to tune something worth more than $1000
Check out this HCCI engine tuning algorithm which runs 240,000 samples per second to provide realtime feedback to an fpga/raspberry pi hybrid board. An Arduino just ain't going to cut it: https://www.raspberrypi.org/blog/machine-learning-engine-con... - at $40 for an TinyFPGA BX it's probably worth it vs the Arduino pro-mini at $10 if you're going to tune something worth more than $1000
> The category of person that is going swap out their ECU cares about sub-milisecond timing. FPGA's are good at concurrency and operating in this domain. 8-bit 16Mhz Arduino's are not.
Depends on their goals. I'd oersonally assume that most people who are considering a DIY-friendly ECU are either looking to replace a carburetor or gain better tunability on a vehicle that has an '80s or '90s era EFI setup.
It's not like anyone's suggesting this be used on a brand new car. It's a relatively inexpensive option for a tinkerer to play around with. I'd be willing to bet that a lot of the cars this will go in to shipped with 8 bit ECUs from the factory. Ford used 'em as late as the early 2000s.
Also for the most part the people who are doing this sort of thing don't need to care all that much about emissions or any of the other things that make production ECUs so much more complicated. All it needs to do is deliver the right amount of fuel and trigger spark at the right times. A carefully programmed microcontroller can do this.
> Check out this HCCI engine tuning algorithm which runs 240,000 samples per second to provide realtime feedback to an fpga/raspberry pi hybrid board. An Arduino just ain't going to cut it
Considering there are absolutely zero HCCI engines in mass production I don't think that's really a concern for anyone other than those developing the technology.
edit: to be clear, of course I am definitely not saying I'm in any way against a DIY ECU project supporting FPGAs, obviously they enable even more potential capability, but I think you're making it out to be way more important than it is for the market that's likely to use these things. This is basically an open alternative to MegaSquirt 2
Depends on their goals. I'd oersonally assume that most people who are considering a DIY-friendly ECU are either looking to replace a carburetor or gain better tunability on a vehicle that has an '80s or '90s era EFI setup.
It's not like anyone's suggesting this be used on a brand new car. It's a relatively inexpensive option for a tinkerer to play around with. I'd be willing to bet that a lot of the cars this will go in to shipped with 8 bit ECUs from the factory. Ford used 'em as late as the early 2000s.
Also for the most part the people who are doing this sort of thing don't need to care all that much about emissions or any of the other things that make production ECUs so much more complicated. All it needs to do is deliver the right amount of fuel and trigger spark at the right times. A carefully programmed microcontroller can do this.
> Check out this HCCI engine tuning algorithm which runs 240,000 samples per second to provide realtime feedback to an fpga/raspberry pi hybrid board. An Arduino just ain't going to cut it
Considering there are absolutely zero HCCI engines in mass production I don't think that's really a concern for anyone other than those developing the technology.
edit: to be clear, of course I am definitely not saying I'm in any way against a DIY ECU project supporting FPGAs, obviously they enable even more potential capability, but I think you're making it out to be way more important than it is for the market that's likely to use these things. This is basically an open alternative to MegaSquirt 2
>Depends on their goals.
I'm in this demographic and am confused why are you selling me on something less capable.
>Considering there are absolutely zero HCCI engines in mass production
This is false and trivially googled.
>You're making it out to be way more important than it is
The parent was requesting a concrete example which quite clearly can not be done on an Arduino but is trivial with an FPGA.
I'm in this demographic and am confused why are you selling me on something less capable.
>Considering there are absolutely zero HCCI engines in mass production
This is false and trivially googled.
>You're making it out to be way more important than it is
The parent was requesting a concrete example which quite clearly can not be done on an Arduino but is trivial with an FPGA.
> Considering there are absolutely zero HCCI engines in mass production
Mazda's really close, no? Skyactiv-X is supposed to be HCCI, I think.
https://ca.finance.yahoo.com/news/mazda-touts-gasoline-engin...
Mazda's really close, no? Skyactiv-X is supposed to be HCCI, I think.
https://ca.finance.yahoo.com/news/mazda-touts-gasoline-engin...
I took a look at your project and I have a question.
I see that you have support for driving 16 outputs with 250 ns accuracy.
Are you using a single timer+compare unit to do this?
I struggled with this a little when I tried to do a similar project myself, but I think I came up with an algorithm that allows me to do it with one timer and one compare match register. The reason it was a little difficult was because the timers usually only have one or two compare match registers, so you can only ever have one event pending at a time. This problem would be trivial if the timer had 16/32 compare match registers.
So, you have to maintain a list of upcoming events and always be sure that the next one to occur has its value loaded in the register. There are a lot of races to watch out for (like if the time for the next event already passed before being able to load its value into the register). This requires a bunch of write-read check cycles and makes me feel uneasy.
How did you handle this?
I see that you have support for driving 16 outputs with 250 ns accuracy.
Are you using a single timer+compare unit to do this?
I struggled with this a little when I tried to do a similar project myself, but I think I came up with an algorithm that allows me to do it with one timer and one compare match register. The reason it was a little difficult was because the timers usually only have one or two compare match registers, so you can only ever have one event pending at a time. This problem would be trivial if the timer had 16/32 compare match registers.
So, you have to maintain a list of upcoming events and always be sure that the next one to occur has its value loaded in the register. There are a lot of races to watch out for (like if the time for the next event already passed before being able to load its value into the register). This requires a bunch of write-read check cycles and makes me feel uneasy.
How did you handle this?
Thanks for your interest!
I didn't want to be dependent on the number of hardware timer captures, so I did actually start with a system like you describe, with a single timer/compare and managing a linked list of upcoming events. On compare interrupt, it would iterate through any events that had passed in time, carefully setting the compare register each time to avoid potentially missing any changes. I actually thought it was pretty straightforward, but it had the effect of skewing similtaneous outputs: Each iteration cost almost a microsecond, so having 4 similtaneous changes would actually be splayed over 3.5ish uS.
Instead I am now effectively bitbanging the outputs with the dma controller. I manage a circular buffer of gpio pin changes (16 bits for "turn on", 16 bits for "turn of") for about a 128 uS window, and the DMA reads on a .25 uS interval from that buffer. There is a lot of complexity in ensuring the buffer's contents is accurate with event changes in a race-free manner, and testing that sufficiently has been where I've had to put most of my effort.
Instead I am now effectively bitbanging the outputs with the dma controller. I manage a circular buffer of gpio pin changes (16 bits for "turn on", 16 bits for "turn of") for about a 128 uS window, and the DMA reads on a .25 uS interval from that buffer. There is a lot of complexity in ensuring the buffer's contents is accurate with event changes in a race-free manner, and testing that sufficiently has been where I've had to put most of my effort.
I'm fairly confident that Motecs line of ECU products all have FPGA's internally. I vaguely remember taking apart an old M400 and it having an FPGA. Thankfully their ECU manager software abstracts that all away from you.
Fair enough. Having an FPGA can certainly make various aspects easier (especially for supporting higher precision outputs), but shouldn't be necessary for basic engine running.
As I understand it, most of the difficulty in modern engines is the tuning anyway. No longer is it just a VE and lambda table, there are so many dimensions that need to be taken into account for a stock car (variable valve timing or lift, electronic throttle control, etc), to get excellent emissions.
As I understand it, most of the difficulty in modern engines is the tuning anyway. No longer is it just a VE and lambda table, there are so many dimensions that need to be taken into account for a stock car (variable valve timing or lift, electronic throttle control, etc), to get excellent emissions.
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.
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'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.
I mean, I don't think you have to "rip apart the wiring harnesses".
Agreed. In fact, the engine bay wiring harness can probably be kept mostly or completely intact. If the stock sensors are being reused, there's no need to mess with the wiring harness at the sensor end. If the position of components in the engine bay is not significantly changing, then the routing of the wiring harness doesn't need to change either. At most, you're going to have to figure out how to connect the harness to this new computer, which can possibly be done without having to modify the stock ECU connector. I have seen adapter harnesses before.
Oh OK. You are correct it seems to support most CKP and CMP designs. So most of the work is actually just getting the pin out and putting those in the speeduino board... I may have to give this a shot then. Not sure about ignition wiring but when I get some time after work I'll read up on how thats handled.
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.
>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.
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.
People do this all the time, go search any car forum for 'megasquirt'.
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.
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.
Some caution required, you can damage your engine by running too lean, for example. Might be good to just start with displaying metrics...
I'd say it's generally a good idea to stick to "bolt on" style modifications at most for any vehicle you need to count on. Save any real deep tinkering like this for something you can afford to have out of commission.
Personally I'm now contemplating fuel injecting my gokart as a way to learn.
Personally I'm now contemplating fuel injecting my gokart as a way to learn.
Am I supposed to already know what "engine management" means by the time I click on this? I get that it has something to do with car engines, but ...?
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.
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.
I believe the Mega Squirt is also Open source and has been around since the early 2000's
It may still be open source, but it is not free software anymore, at least for MS3 software and hardware.
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.
What is engine management? This is not a very "searchable" term.
I answered this on a different comment: https://news.ycombinator.com/item?id=22467998
[deleted]
Is this about internal combustion engine management?
Is my car still insurable if I run this?
Who says they need to know?
The problem is if it's found after an accident and leads to a denied claim. Not likely, but possible.
Does anything similar to Magnuson-Moss apply to insurance companies?
https://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty...
https://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty...
[1] https://github.com/noisymime/speeduino/
[2] https://github.com/onesk/ms3-source
[3] https://github.com/rusefi/rusefi