Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeduino: Open-Source Engine Management

speeduino.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Speeduino: Open-Source Engine Management

#51

Post by seabird »

asguy wrote: post #3

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

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.

Re: Speeduino: Open-Source Engine Management

#52

Post by l8rlump »

noisymime wrote: post #49
korethr wrote: post #14

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 sen…

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?

Any links/info on these devices?

Re: Speeduino: Open-Source Engine Management

#53

Post by core-questions »

asguy wrote: post #31
outworlder wrote: post #28

Earlier quoted context omitted.

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

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 A…

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

Re: Speeduino: Open-Source Engine Management

#54

Post by core-questions »

wolrah wrote: post #36
paulgerhardt wrote: post #32

Earlier quoted context omitted.

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…

> 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 li…

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

Re: Speeduino: Open-Source Engine Management

#55

Post by asguy »

core-questions wrote: post #53
asguy wrote: post #31

Earlier quoted context omitted.

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 A…

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

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/

Re: Speeduino: Open-Source Engine Management

#56

Post by matthewvia »

Unklejoe wrote: post #50
matthewvia wrote: post #6

Earlier quoted context omitted.

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 fr…

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…

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.

Re: Speeduino: Open-Source Engine Management

#57

Post by tyingq »

noisymime wrote: post #49
korethr wrote: post #14

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 sen…

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?

Some cars, like the Mitsubishi EVO, have both.

Re: Speeduino: Open-Source Engine Management

#58

Post by martinmunk »

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.

Post reply on HN