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

41–50 of 58 posts

Re: Speeduino: Open-Source Engine Management

#41

Post by noisymime »

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

Re: Speeduino: Open-Source Engine Management

#42

Post by noisymime »

Grazester wrote: post #7

I believe the Mega Squirt is also Open source and has been around since the early 2000's

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.

Re: Speeduino: Open-Source Engine Management

#43

Post by tyingq »

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

Re: Speeduino: Open-Source Engine Management

#44

Post by travbrack »

westmeal wrote: post #2

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.

People do this all the time, go search any car forum for 'megasquirt'.

Re: Speeduino: Open-Source Engine Management

#45

Post by paulgerhardt »

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…

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

Re: Speeduino: Open-Source Engine Management

#47

Post by Unklejoe »

noisymime wrote: post #40
VectorLock wrote: post #20

Earlier quoted context omitted.

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

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.

Re: Speeduino: Open-Source Engine Management

#48

Post by [deleted] »

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…

[deleted]

Re: Speeduino: Open-Source Engine Management

#49

Post by noisymime »

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?

Re: Speeduino: Open-Source Engine Management

#50

Post by Unklejoe »

matthewvia wrote: post #6
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'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 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?

Post reply on HN