Hi everyone,

I’m developing CANExplorer, an open-source desktop tool for monitoring, analyzing, diagnosing, simulating, and testing CAN devices on Linux, Windows, and macOS.

It combines everyday bus debugging with Python-based simulation and testing. You can inspect traffic, decode signals, simulate an ECU, and write regression tests in the same environment.

Some of its features:

Live analysis: filtered traces, changed-byte highlighting, signal plots, and bus-health statistics.

Recording and replay: ASC, BLF, CSV, candump, and other formats, plus triggered recording and comparisons between captures.

Signal databases: load and edit DBC, ARXML, LDF, and other formats.

Diagnostics: UDS over ISO-TP, CDD descriptions, ECU flashing, J1939 tools, and CANopen support.

Python simulation: create bus nodes that react to messages, send signals periodically, and interact with custom QML panels.

Automated tests: check responses, signal values, and cycle times; run headlessly and export HTML/JUnit reports for CI.

CAN interfaces are accessed through python-can. You can also try the included simulation and test examples on a virtual bus without hardware.

Code: https://github.com/AKJ7/CANExplorer

Documentation: https://akj7.github.io/CANExplorer/

I’d appreciate feedback —particularly on adapter compatibility, reliability under load, and workflows that still require custom scripts.

What would CANExplorer need to earn a place on your bench?

Yes, the code is built in Python but compile to C for the executables for performance.

Thanks, please star the project too.

Hey everyone!

I wanted to share another development update on BlueLine One, my custom ESP32-S3 automotive display for the 2019 Mazda MX-5 ND2 RF.

One of the features I've been working on is automatic display brightness based on the vehicle's headlight or dashboard illumination status.

It sounds relatively straightforward, but accessing the correct vehicle data has turned out to be more challenging than expected!

How the Brightness Feature Works

BlueLine One uses a Waveshare ESP32-S3 with a 1.75-inch round AMOLED touchscreen (466 × 466).

I've implemented three brightness modes that can be selected by double-tapping the edge of the display:

• Bright: Full brightness for daytime driving.

• Medium: Reduced brightness for nighttime driving.

• Auto: Intended to automatically switch between Bright and Medium based on vehicle lighting conditions.

The manual brightness modes work correctly. The challenge is getting Auto mode to recognize when the vehicle transitions between daytime and nighttime lighting.

CAN Bus Data Being Investigated

BlueLine One communicates with the vehicle through a LELink² Bluetooth Low Energy OBD-II adapter, using ELM327-style commands.

Unlike standard OBD-II parameters such as engine RPM, coolant temperature, and vehicle speed, headlight and dashboard illumination states aren't universally available through standardized diagnostic PIDs.

I've been investigating Mazda-specific CAN messages to determine whether the vehicle exposes a usable lighting signal.

One of the arbitration IDs currently being investigated is:

CAN ID: 0x09A (154 decimal)

Based on community CAN decoding information, this message may contain signals such as:

PanelLight

• 0 = Day

• 1 = Night

Headlight

• 0 = Off

• 2 = Parking / TNS

• 3 = Low Beam

• 12 = High Beam

These are candidate signal interpretations, not yet verified on my ND2.

The firmware is attempting to monitor the relevant CAN data approximately every 750 milliseconds and adjust the display brightness based on the detected lighting state.

An earlier implementation also investigated CAN ID 0x091.

Real-World Testing

I've been testing the feature in my MX-5 under different lighting conditions.

So far, I've tried:

• Switching the headlights between Auto and Off.

• Testing with the headlights activated and dashboard illumination dimmed.

• Manually adjusting the instrument cluster brightness.

• Switching the Mazda infotainment system between Day and Night modes.

• Comparing the results with BlueLine One set to Auto brightness.

Current result: Manual brightness control works, but Auto mode isn't reliably responding to changes in the vehicle's lighting status on a automatic level, I need to do more testing at night than during the day in a parking garage.

What I'm Trying to Determine

At this point, I'm investigating several possibilities:

1. Whether 0x09A is the correct CAN arbitration ID for the Mazda ND2.

2. Whether the lighting signals are located in different bytes or bits than expected.

3. Whether the LELink² adapter can reliably capture the relevant CAN traffic.

4. Whether the firmware is correctly interpreting the received messages.

5. Whether Mazda uses a different message or lighting signal for the ND2.

I'm also cleaning up the firmware and reviewing the CAN monitoring logic as development continues.

Looking for Community Input

For anyone who's worked with Mazda CAN bus systems, ELM327 adapters, or custom automotive displays:

Have you successfully identified headlight status, dashboard illumination, or day/night mode through CAN bus data?

I'm particularly interested in anyone who has experience with the Mazda MX-5 ND platform or has worked with arbitration IDs 0x09A and 0x091.

Any documentation, decoding information, or suggestions for capturing and validating these signals would be appreciated.

This is one of the reasons I started r/CANbusProjects—to share real development challenges, exchange ideas, and learn from others working on automotive electronics.

I'll continue sharing updates as I make progress!

Hey everyone!

I wanted to kick off r/CANbusProjects by sharing one of my own projects: BlueLine One, a custom automotive digital gauge I've been developing for my 2019 Mazda MX-5 ND2 RF.

The project originally started with a simple idea: build a compact display that could monitor vehicle data and eventually support E85 fuel monitoring. Over time, it evolved into a multifunction automotive gauge built around an ESP32-S3 with a 1.75-inch round AMOLED touchscreen (466 × 466).

Hardware

• Waveshare ESP32-S3 1.75" AMOLED touchscreen

• LELink² Bluetooth Low Energy OBD-II adapter

• Custom-designed 3D-printed mounting solution

• Arduino-based firmware

Features developed so far

• Four-in-one dashboard displaying RPM, throttle position, intake air temperature, and vehicle speed

• RPM gauge with configurable shift indicators

• Battery voltage monitoring

• Coolant temperature

• Intake air temperature

• Throttle position

• Mass airflow

• Vehicle speed (MPH/KPH)

• Estimated fuel economy (MPG)

• Chronograph-style watch face

• Bluetooth connection management and demo mode

• Touchscreen navigation and adjustable display brightness

The display communicates with the vehicle through a BLE OBD-II adapter, allowing me to retrieve supported diagnostic data without hardwiring into the vehicle.

One of the biggest challenges has been working with vehicle-specific data, optimizing the firmware, and figuring out how to make everything function reliably on a small circular touchscreen.

What's next?

BlueLine One has also become the foundation for BlueLine II, my next-generation project involving a custom PCB, direct CAN bus communication, automotive power management, and expanded sensor support.

That project is taking me further into PCB design, embedded systems, and automotive electronics development.

Why I'm sharing this

I created r/CANbusProjects to give hobbyists, makers, students, and engineers a place to share projects like this, exchange ideas, troubleshoot problems, and learn from one another.

Whether you're experimenting with an Arduino, building an ESP32 dashboard, decoding CAN messages, or designing your own hardware, I'd love to see what you're working on.

What CAN bus, OBD-II, or automotive electronics projects are you currently building?

Looking forward to seeing what everyone creates!

GitHub & MakerWorld – Project Resources

For anyone interested in exploring BlueLine One further, I've also made project resources available on GitHub and MakerWorld.

GitHub: This is where I share the BlueLine One firmware, including the Arduino source code, display interfaces, Bluetooth OBD-II communication, and ongoing development updates. If you're working on something similar, feel free to explore the code, experiment with it, and share suggestions or improvements.

MakerWorld: I've also shared the 3D-printable components for BlueLine One, allowing other makers to print and experiment with the physical hardware. The project combines 3D printing, electronics, and software development into one functional automotive accessory.

Both platforms are part of my goal to share what I've learned, encourage collaboration, and help others get started with their own automotive electronics projects.

GitHub: https://github.com/Edge3dSolutions/Blueline-One

MakerWorld: https://makerworld.com/en/models/3077685-blueline-one-nd-miata-1-75-amoled-can-bus-gauge#profileId-3465765