[HN Gopher] Speeduino: Open-Source Engine Management
___________________________________________________________________
Speeduino: Open-Source Engine Management
Author : johnnycarcin
Score : 102 points
Date : 2020-03-02 16:23 UTC (6 hours ago)
(HTM) web link (speeduino.com)
(TXT) w3m dump (speeduino.com)
| westmeal wrote:
| 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.
| temporaryvector wrote:
| >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.
| korethr wrote:
| 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.
| microcolonel wrote:
| I mean, I don't think you have to "rip apart the wiring
| harnesses".
| korethr wrote:
| 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.
| westmeal wrote:
| 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.
| asguy wrote:
| > 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.
| matthewvia wrote:
| 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.
| asguy wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| matthewvia wrote:
| 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.
| asguy wrote:
| 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".
| paulgerhardt wrote:
| 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
| wolrah wrote:
| > 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
| leon_sbt wrote:
| 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 wrote:
| 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.
| jascii wrote:
| 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.
| noisymime wrote:
| 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.
| donquichotte wrote:
| If anyone is interested, here is the source code for speeduino
| [1], megaSquirt [2] and rusEFI [3], two comparable open source
| ECUs.
|
| [1] https://github.com/noisymime/speeduino/
|
| [2] https://github.com/onesk/ms3-source
|
| [3] https://github.com/rusefi/rusefi
| VectorLock wrote:
| I'm curious what the big differences between these 3 are?
| noisymime wrote:
| 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.
| korethr wrote:
| 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?
| virgil_disgr4ce wrote:
| 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 ...?
| tyingq wrote:
| 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.
| farisjarrah wrote:
| 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.
| tyingq wrote:
| Some caution required, you can damage your engine by running
| too lean, for example. Might be good to just start with
| displaying metrics...
| wolrah wrote:
| 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.
| akeck wrote:
| Is my car still insurable if I run this?
| westmeal wrote:
| Who says they need to know?
| ihattendorf wrote:
| The problem is if it's found after an accident and leads to a
| denied claim. Not likely, but possible.
| nitrogen wrote:
| Does anything similar to Magnuson-Moss apply to insurance
| companies?
|
| https://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warrant
| y...
| VectorLock wrote:
| 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.
| NietTim wrote:
| 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.
| leafmeal wrote:
| What is engine management? This is not a very "searchable" term.
| tyingq wrote:
| I answered this on a different comment:
| https://news.ycombinator.com/item?id=22467998
| [deleted]
| Grazester wrote:
| I believe the Mega Squirt is also Open source and has been around
| since the early 2000's
| matthewvia wrote:
| It may still be open source, but it is not free software
| anymore, at least for MS3 software and hardware.
| noisymime wrote:
| 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.
| tabiv wrote:
| 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/
___________________________________________________________________
(page generated 2020-03-02 23:00 UTC)