Join the WhatsApp group here.

The problem

Nowadays, repairing hardware electronics is impossible or almost impossible. Current practice forces a car owner to replace instead of repair. This has a really high cost and pushes owners to seek other less trustworthy solutions using used components from other vehicles. Since this type of components is nowadays heavily protected, maintenance and repair outside the official car manufacturer authorized dealer poses additional risks every time a piece of hardware electronics or firmware requires reverse engineering and modification just to enable it and make it work in another vehicle.

The Ideia

Design and prototype OEM hardware electronics capable to the same operation and functionality, however instead of using closed and protected logic, it uses open hardware and open firmware hardware electronics as a direct replacement into existing* wiring in a vehicle, in particular older cars. This will facilitate repeatability and maintenance on any "repair shop" outside authorized dealers. And requires no reverse engineering and no modification to make it work in a vehicle.

Since this is an open hardware project, the main selection of choice for the operating system will be Android Auto for the main LCD screen, in the center console. Nowadays there are a plenitude of "open auto" solutions using a raspberry pi. I'll be designing the hardware electronics made to fit an SoC module, and I'll be starting with NVidia's Jetson Nano. In the following YouTube video there's a good example of a traditional media unit

Open Hardware Design Considerations

Since these "open automotive" solutions are based on "open hardware" electronics there are some design considerations to make the electronics safer when driving and also make it simple & easy to troubleshoot, debug and repair. When deploying open solutions, one of the major requirements to have, is redundancy. This means in case of failure of a particular electronic component there's a 2nd one (or more) ready to take over the one malfunctioning. Depending on safety requirements, this type of redundancy can be implemented in the same hardware electronics installed in a particular location in a vehicle (see hardware electronics of a Tesla car), or can be in a separate hardware electronics installed on a different location in a vehicle. Another hardware design consideration is on having a separate microcontroller dedicated exclusively to CAN communication among devices installed in a vehicle and able to communicate directly to the control module's main microcontroller. By having a separate microcontroller one is minimizing the possibility of malfunction of the controller in the event of unauthorized intrusion "hacking" of the CAN bus network. To add to safety and security of all open hardware electronics proposed and available on this repository, it will use many of the functionalities, specifications and characteristics described on this ongoing scientific research paper titled "Validation of Experimental Data Origins: A Swarm of DAQ devices able to Deliver Unique Experimental Data using Blockchain‐like Fingerprint ID to a Data Repository".

The Open ECU

To design the open hardware electronics ECU I'll be using what is already available on the open communities in particular the Speeduino project (see its GitHub repository here). Their open hardware ECU solution is a flexible, fully featured Engine Management Systems (EMS aka ECU) based on the low cost and open source Arduino platform. It provides the hardware, firmware and software components that make up an engine management system, all provided under open licenses. With over 1000 installations, Speeduino has matured into a product that meets the needs of the hobbyist and enthusiast community without driving prices to the levels of traditional aftermarket ECUs.


To run the main electronics and engine management I'll be using EspressIF Systems ESP32...

Read more »