7 ms·

> 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 sta

by asguy 7y ago

> 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.

jascii 7y ago
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.
matthewvia 7y ago
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/ 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.
- leon_sbt 7y ago
  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.
  - matthewvia 7y ago
    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.
- asguy 7y ago
  > 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.
  - outworlder 7y ago
    > 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?
    - asguy 7y ago
      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.
- Unklejoe 7y ago
  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?
  - matthewvia 7y ago
    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.
noisymime 7y ago
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.
tyingq 7y ago
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.
deleted 7y ago
[deleted]
seabird 7y ago
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.

by asguy 7y ago

jascii 7y ago

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.

matthewvia 7y ago

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/ 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.

leon_sbt 7y ago
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.
- matthewvia 7y ago
  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.
asguy 7y ago
> 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.
- outworlder 7y ago
  > 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?
  - asguy 7y ago
    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.
Unklejoe 7y ago
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?
- matthewvia 7y ago
  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.

noisymime 7y ago

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.

tyingq 7y ago

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.

deleted 7y ago

[deleted]

seabird 7y ago

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.