FAQ ‐ Frequently Asked Questions
Main Page >> Frequently Asked Questions
Last update 16-12-2023
Which cars do you plan to develop code for first? by David Cherry
I'm starting with a Volvo MKII . However, this is an open solution, meaning the pcb layout can be redesigned to fit any other car.
Where do you find the protocols to send messages to other modules (like the ignition control module)? by David Cherry
If you Google "EOBD protocols" you will find them all... or , alternatively, write ✍️ your own ... The requirements are ability to exchange messages and more importantly do it safely ... for the latter I have to recommend reading all EOBD protocols from any car brand and also google any other clue on how to increase the safety in communications among devices in a vehicle. On my repository you will find one or two ....
How will you go about insuring the vehicle, surly any insurer will view this like the worst kind of modification. Should you have an accident couldn’t a third party insurer blame the none stock electronics, being most of these updates cut right across the safety aspects of the vehicle design? Without the manufacturers ultra expensive safety checks done on the standard modules and vehicle. by Paul de Luca
You are all correct 💯 except in one key assumption. That this open ECU is intended for modifying a car. It can be , however , the main motivation for this project is to prototype open hardware electronics capable of replacing proprietary , original electronics from a manufacturer with the exact same functionality. Insurance will love it. So will the vehicle owners! With cheaper , repairable hardware electronics.
even with the same functionality programmed in, would that still need to be proven to be the case in order for insurers to accept that position? Also how could you prove it is the same, just playing devils advocate on how the insurers will view this. In a world run on rules and regulations. You would likely have more of a chance of them accepting it if the hardware was fixed rather than open to modification once installed, and you had the hardware and code proven to offer a verbatim level of performance v the original part, also let’s not forget reliability playing a part. by Paul de Luca
That's the main advantage of an open solutions over closed 🔒 , with IP protection devices, on this case the device is an open ECU. And since the hardware electronics and also the firmware source code is openly availability on GitHub, it can be used and viewed not only by insurers but also it can be viewed , and used, by the authorities on they daily work patrolling the roads ... In the end, safer driving conditions and safer policing.
Have a question to ask and in need of an answer?
You can do it here on GitHub, on the discussions page , on Twitter and on LinkedIn on any of my publications about this open project.
🟢 Fully tested and working
A green circle means the hardware electronics or the programming code was fully tested, each of its functionalities and capabilities. And it can be installed in a vehicle. Keep in mind this does not mean errors won't happen. As in everything related to electronics and software, there are revisions and updates. This open hardware is no different.
💯 Fully tested & working, no improvements necessary - already being sold online
🆓 Fully Open hardware \ source code
🤪 There's better than this. don't use it
🔐 Fully closed hardware \ source code
⚡️ fully tested and working, however, it is a dangerous solution to deploy
🟡 Not tested. Working capability is unknown, it may work or not.
A yellow circle means the hardware electronics or the programming code was not fully tested, each of its functionalities and capabilities. This does not mean it not working, it simply means testing is needed before giving a green circle of approval.
🔴 Fully tested but not working.
A red circle means the hardware electronics or the programming code was fully tested, and found some kind of critical error or fault. This means the electronics or firmware code cannot be used in a vehicle.
⌛ Not started.
The hourglass means the hardware electronics or the programming hasn't started. Most likely because is waiting for the necessary test components needed for reverse engineering and also engineering of the new open solution.
🆕 New updated contents
The new icon means the link next to it was recently updated with new contents
💬 Comments on the Discussion page
The comments icon means there are useful and even new comments on the discussions page of the repository important for what you are seeing or reading.
Join the beta program to test and debug to provide feedback, ideas, modifications, suggestions, and improvements. And in return, write your own article blog, or post on social media about it. See participation conditions on the Wiki.
The Beta Participant Agreement is a legal document being executed between you and AeonLabs that outlines the conditions when participating in the Beta Program.
Bug reports and pull requests are welcome on any of AeonLabs repositories. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the code of conduct.
- Contributing
Please make sure tests pass before committing, and add new tests for new additions.
You can get in touch with me on my LinkedIn Profile:
You can also follow my GitHub Profile to stay updated about my latest projects:
The PCB design Files I provide here for anyone to use are free. If you like this Smart Device or use it, please consider buying me a cup of coffee, a slice of pizza or a book to help me study, eat and think new PCB design files.
Make a donation on PayPal and get a TAX refund*.
Did you like any of my PCB KiCad Designs? Help and Support my open work to all by becoming a GitHub sponsor.
Before proceeding to download any of AeonLabs software solutions for open-source development and/or PCB hardware electronics development make sure you are choosing the right license for your project. See AeonLabs Solutions for Open Hardware & Source Development for more information.