[danwie]

Thank you for your details reply, cgrey8.

So basically, it just hasn't been done, that's it, yes?

I became interested in the topic because I was thinking it would be nice to be able to replace the aging units one day as they will eventually deteriorate electromechanically.
My interest wasn't neccessarily in making a commercial product or selling it either, but approaching this as an engineering challenge. I don't have the interest in making money off of this.
To be honest, I do not have much hands-on experience with tuning engines or fuel injection at all - my background is in software engineering, embedded design and some electrical engineering, as well as an interest in older vehicles, but 1st gen Town Cars and Continentals specifically.

The topic came to me just a few days ago, but in abstract terms the EEC takes a variety of engine measurements, filters them ("ROLAVS"), applies scalars, functions, and tables to generate binary and PWM signals at the output drivers.

It would be interesting to get hold of some actual EEC-VI schematics in legible resolution, but from pictures it looks like mainly the CPU with its accessories, output drivers on heatsinks and protection circuitry / buffers for the inputs.

The real crux would be the software end; I think that while an embedded Linux/Java gives you a lot of leeway, is way too much overhead and overly complex - after all we'd like to avoid reliability issues with the EEC.

Right now I am just tinkering; but I have an EEC-IV available for tampering around. Without an actual engine, the first step will be to simulate all or enough correct inputs to fool it into believing it's seeing an actual motor.

I know it's a bit of a tall order, but I might tinker away on it for a while.

[motorhead1991]

Someone in the Telegram chatroom was talking about this very thing...

[cgrey8]

...So basically, it just hasn't been done, that's it, yes?...

Note entirely true. MegaSquirt is an open source solution that is basically what you are talking about. It's just dated. But it is maintained and is still out there.

...The real crux would be the software end; I think that while an embedded Linux/Java gives you a lot of leeway, is way too much overhead and overly complex - after all we'd like to avoid reliability issues with the EEC...

It depends on your view. The traditional way of doing embedded design is for you to have the real time controller just do what it does with some relatively light-weight way of being communicated to and being updated. But this means you need software installed on a PC that knows how to interface with the hardware.

In the modern era of such powerful microcontrollers, there's a desire to eliminate the installed software and embed the editor and editor's GUI into the embedded device so any computer with a browser can manage and configure the device. With Browsers and websites getting more and more sophisticated, you can do a LOT in a browser. Add to this, the tools to do webpage development are getting better. For example, the Linux installed could run a WebService package, and then updating the GUI portion of the device is nothing more than the deployment of a Docker file...same as if you are deploying a site via Amazon Web Services (AWS)...just your little device is not AWS. There's a lot of developers out there that know Docker and know how to program quite webservice GUIs.

Then like I said, there's the realtime work that has to be done. That's where the work of running the engine comes in...stuff like managing injector/spark events. Point is, with the right number of developers with the right skill sets, there are clear lines of separation. GUI developers, engine management developers, protocol developers, hardware design & sensor/actuator programmers, etc etc.

...I know it's a bit of a tall order, but I might tinker away on it for a while.

Projects like this start with someone just wanting to tinker, then realize they've tinkered so long they've got a critical mass of a project that actually does something. And before they know it, they are project managers of a project they thought was just going to be an academic exercise.

[Chucko]

Funny, last fall I picked up an Adafruit M4 Grand Central dev board, for the purpose of writing engine control code for S&Gs. It has a SAM D51 microcontroller on it, which strikes me as perfect for the job - ARM Cortex-M4 at up to 120 MHz, enough RAM, half a meg of flash, lots of timers, 12 bit A/D, Micro SD and USB interfaces. And it's available in industrial temperature ranges. A lot of stuff Ford did in custom hybrids is now available as off-the-shelf ICs - e.g. HEGO and speed sensor input conditioning.

I could see myself doing an EEC-IV plug-compatible ECU, but probably won't have the time to do it until I retire. Custom PC boards are not a big deal these days. I'd pick up a dead EEC-IV from eBay or a boneyard, salvage the case and connector, design the PCB, have it fabbed (and maybe assembled), and write the control code. But someone else needs to write the GUI - I suck at user interfaces.

[Chucko]

Do it as a product? NO WAY. Open source design? Sure, just be sure to click on the liability waiver before you download.

[cgrey8]

I agree the project software and design needs to be an open source thing, right down to the schematics of the board layout. I genuinely believe open source solutions are safer because they are quite often peer-reviewed. And when there's a problem, you can just tweak the code to fix whatever the issue is. Now depending on the license, you may be obligated to submit or at the very least, make available any tweaks you've made to the code. Unfortunately that's only as enforceable as the person who wants to enforce it can afford.

But for people to get hardware to use it, it either needs to be existing hardware pieces you can cobble together to make a functional EEC or someone, like Moates, needs to make it. And if someone is going to make, sell, and distribute, it becomes a product for sale.

Although you could do what the TwEECer guy did...get your support on the forums. Accept that as part of the sale, take it or leave it.

[danwie]

The MegaSquirt project is very interesting, I didn't know about it. However, the major problem with it would be that you cannot legally run it on a custom hardware.
I'm thinking along the lines of Chucko - something that is plug-compatible with the EEC-IV.
Also, on the software side, the performance tables should be easily extracted and converted. Extraction appears to be a well-understood process.
I will keep monitoring on here and might ask a few more things. It will be a while before anything intelligent could probably be reported.

[wwhite]

So basically, it just hasn't been done, that's it, yes?

Sure it's been done:
rusEFI: A GPL open source Engine Management System
FreeEMS: Free and Open Source Engine Management System

There are more, google DIY EFI, or similar.

[ironmanisanemic]

Someone in the Telegram chatroom was talking about this very thing...

That would have been me. I havent had a ton of time to work on the reverse engineering of the hardware i have on hand as of late. But, i have made a bit of progress with reverse engineering the silicon. An individual that runs the site https://siliconpr0n.org/ did an AMA on hackster.io chat, and offered up his services to decap and delayer the microprocessors used in our ecus. Im hoping with this information, we may be able to construct something similar to visual6502.org, and maybe even implement something into an FPGA to be used as a base for an OSH implementation.

With that being said, ive started the hardware schematic reverse engineering effort on a largely useless unit (at least to me). It was the og processor from my bronco before i converted it to maf and electronic trans control. What i would like is to get ahold of a damaged A9 series computer to reverse the schematic of that. The cost of one of those units is largely out of my budget, as well as i would have no use for it after my work is done with it. I have spare CBAZA ecus to use for the cause, as well as some later EEC-V units as well.

What im hoping to do is accumulate a variety of different implimentations of the same control circuitry and choose the most robust and universal of them all to implement into a replacement board that could accept either generation intel processor. That then opens the door to the second part of my project and to do something similar with the software. Gather many different versions of the same code blobs, and have a Configure wizard that could take your vehicle configuration and link the code blocks that are necessary for your configuration into a useable binary that could then be flashed. That way the code would be leaner and easier to tune, and by stripping out unused code segments, you could then have the ability to include custom written code, like native wideband, nitrous, boost by gear, native canbus, etc... The thing with this, it could be expanded further if the silicon is reverse engineered, the chip itself could be expanded with more ram and the ability to address larger amounts of rom etc... that would be the benefit of implementing it in an FPGA as it could be updated and add functionality without getting custom silicon made or spin new boards. Hell you could even make a quarterhorse integrated right into the core and have direct access to all memory without needing datalogging code.

This is my vision at least. Having an open source project that could be a gold standard that could be used for decades to keep our aging vehicles going, as well as aid in restorations into the future as the vehicles become more valuble, but oe parts become harder to source. If anyone would like to help me out, you can get ahold of me on the telegram chat, or PM me here.

[motorhead1991]

So thanks to ollapa and some things I had to do with git, the manuals he provided are now backed up to GitHub! Should be easier to find later.