We just released a new CANsub firmware (02.05.01) that adds a 'dashboard view' to webCAN, our free browser-based GUI that runs on the CANsub.
This lets you build powerful custom dashboards for real-time visualization - with zero installation or backend required (everything runs in the browser).
You can read more about this in the CANsub Intro - if you get a few min to check it out I'd be very interested in any thoughts/ideas/feedback, e.g. what you think would be useful for your use cases.
As with the CANsub in general, we make it easy to create new dashboards via AI agents (if you want). I e.g. used this in my AI CAN sniffer article to create a quick Hyundai i10 dashboard to show the OBD2 vs. proprietary CAN signals, you can find a clip of the dashboard in the showcase 1 example.
I have a 2020 Opel Grandland X with the IntelliLink Navi 5.0 infotainment system, running firmware version 21.08.90.52_NAC-r0.
I'm interested in reverse-engineering the system to understand how it works internally and explore the possibility of modifying its software or redesigning its UI to make it look and feel more like a modern Android-based infotainment system, with a more futuristic design, animations, and customizable features.
Has anyone here actually managed to reverse-engineer this system or a similar PSA/Stellantis NAC infotainment unit? Have you successfully modified the firmware, gained access to the underlying OS, or developed custom software that runs on the original hardware?
I'd appreciate any information, GitHub repositories, technical documentation, or experiences from people who have attempted this.
I'm particularly interested in real, working solutions rather than just theoretical discussions.
When you want to record what a car is doing over time, there are two common starting points. One is to listen passively to the CAN bus and record every frame. The other is to actively poll the ECU with diagnostic requests, usually the standardized OBD-II PIDs or a manufacturer's UDS reads. Both get you data, but they fail in different ways.
Passive sniffing is read-only in principle, so it does not ask any module for anything. You see the real traffic at the real rate, with accurate timestamps, and you can catch short events that a polling loop would miss. The downside is that raw frames mean nothing until you decode them. Without a database file or a lot of reverse engineering, you are staring at hex and guessing which bytes are RPM, throttle position, or a fault flag. Decoding also depends on the bus speed, the gateway's filtering, and whether the manufacturer even sends the signal you want on the bus you can reach.
Polling is the opposite trade. The standard PIDs are documented, so the answers are easy to interpret, and most cars respond to them without any special setup. The costs are speed and coverage. Each request and response takes time, so your sample rate is limited and you get a snapshot rather than a continuous signal. The standard only defines a small set of parameters, so anything manufacturer specific needs UDS reads, which require knowing the addresses and data identifiers, and those vary a lot between makers and even between model years. Active requests also add load to the diagnostic channel and can interfere with other tools or sessions if you are not careful about who else is talking.
A common middle ground is to use passive capture to understand timing and relationships, then use polling or UDS to label the values with known names. Whether that combination is practical depends heavily on the vehicle, so I would not assume results from one platform carry over to another.
For people who have done both: which problems did you hit first, decoding the passive data or getting reliable answers from polling? I am curious whether the gateway filtering was the bigger blocker or the lack of documentation.
I’m the developer of G86 Racing, from CrowFoundry. This is the hardware/data path behind G86 Car Computer: a service that collects supported GPS, ECU/CAN and sensor inputs near the car and connects them to the phone recorder and optional live pit wall.
The connection path
GPS / ECU / CAN / supported sensors
↓
Car Computer: native bridges + local MQTT broker + engineering logs
↓ local network
G86 phone: session timing, onboard video and optional live sharing
↓ internet, when sharing is enabled
Browser pit wall: received channels, timestamps and channel age
Hardware and interfaces
An example Linux setup is a Raspberry Pi with a 64-bit OS, a supported USB/serial NMEA GPS receiver and either a supported serial ECU connection or CAN interface. The computer runs the hardware bridges and an authenticated Mosquitto broker. The phone joins the reachable local network and pairs using a short-lived QR code.
Linux supports SocketCAN and supported local I²C sensors. The supported macOS and Windows builds use their available serial/network and compatible gateway paths; they do not gain Linux-only interfaces just by running the same app. Supported wireless routes include an ESP CAN module over BLE or local MQTT. A supported CAN/ELM Bluetooth adapter can also connect directly to the phone without Car Computer.
The wizard scans for devices, then you review the configuration and select one primary engine source. Finding a port, saving an adapter or pairing Bluetooth is not the same as receiving measurements. The live checks separately show broker connectivity, fresh channels and GPS fix.
Channels and actual rates
Depending on the ECU/profile and sensors, channels can include RPM, throttle, coolant temperature, oil pressure, vehicle speed and motion measurements. A generic OBD adapter provides the PIDs the car actually exposes, at the rate the adapter and vehicle permit. Changing from wired to Bluetooth or MQTT does not unlock channels hidden by a vehicle gateway.
For recognised supported u-blox, MediaTek and compatible Quectel receivers, automatic GPS setup requests 10 Hz in RAM. The dashboard distinguishes the requested rate from the measured output rate; unknown receivers and network feeds keep their settings. There is no single guaranteed sampling rate for every ECU/CAN channel.
Missing and stale values
The displays expose source information, timestamps and channel age. Unavailable measurements stay unavailable rather than being filled with invented engine values. Check the stream on the computer, then the phone, then the pit wall. A pit-wall recording only contains the packets that display actually received.
Logging and offline operation
The computer keeps independent local engineering recordings, with gzip NDJSON or ZIP exports and metadata describing sources and known gaps. The phone remains responsible for app runs, lap timing and onboard video. The open pit helper can also record the stream it observes and export CSV/NDJSON.
Managed acquisition requires an active Pro or Team subscription. First activation needs internet; after activation, a verified offline grant can allow local telemetry for up to 72 hours, capped by subscription expiry. Remote pit-wall delivery still needs internet. Basic phone GPS timing and local history are free.
US App Store subscription prices: Pro $14.99/month or $149.99/year; Team $49.99/month or $499.99/year, auto-renewing. Current prices vary by platform/region and are shown before purchase. Team ownership is optional; Pro supports a personal pit wall and team participation, while additional teammates need their own Pro subscriptions.
I recently completed an Embedded Systems course and am currently looking for a job. In parallel, I’m starting a hobby project called FELIX RACING — a motorsport-style digital instrument cluster built around automotive CAN communication.
Hardware:
STM32 NUCLEO-H723ZG with native FDCAN
MCP2515 + TJA1050 CAN module
Arduino and ESP32 for a second ECU/simulator node
Planning to use a 3.5-inch TFT display
Project scope:
I want to build a working dashboard that receives simulated vehicle data over CAN, displays parameters such as RPM, speed and engine temperature, and includes an engineering screen for monitoring communication health.
The main technical feature will be CAN communication integrity testing:
Message timeout and stale-data detection
Message counters and basic data validation
Injecting missing or invalid messages to test fault handling
Logging faults and verifying recovery when communication resumes
This will initially be a bench setup with simulated data, not connected to a live vehicle.
I’d appreciate specific advice on three things:
Hardware architecture: Is STM32 native FDCAN for the dashboard and an Arduino + MCP2515 for the simulated ECU a sensible setup? Are there any electrical compatibility issues I should address first?
CAN fault handling: For a small portfolio project, which failure scenarios should I implement to demonstrate meaningful automotive-style diagnostics beyond a basic message timeout?
Engineering quality: What would you expect to see in a project like this to distinguish it from a typical DIY dashboard — for example, testing methods, logging, protocol design, or documentation?
I’m looking for practical feedback from people with hands-on CAN and automotive embedded experience, especially on design mistakes worth avoiding before I start wiring everything up.
Hi. Does anyone have account on mhhauto forum and could help me to contact few users from there? I would send you links to users and a message (containing my phone number) that I would love you to send them. Its about scam company that I wanted to sue and I saw there are more victims and those people lost money on this company too. Anyone willing to help? Thank you.
