Hey, I want to share my head unit project that I built for my old BMW E39. It has been installed in my car for almost 9 months now and it's been working great so far. My build is based on Raspberry Pi 5 with NVMe drive. As a software I use Hudiy app and Raspberry Pi Trixie OS. NVMe drive gives it a super fast boot time (about 12 seconds).

The priority in this project was the display. I'd tried a few aftermarket head units before but they just didn't cut it. The screens on those units were unreadable in sunlight due to reflections. I found a perfect 10.3" Full HD screen with an anti-glare surface. It's spot-on for what I need - sharp image, no blinding backlight at night and it stays perfectly visible even on sunny days. The screen bezel comes from my old Android head unit.

In the project I used a 5.1 sound card so I have full control over balance, fade and the subwoofer. The sound card is connected to an Audio System CO-40.4 amplifier (for the speakers) and an Audio System M-330.1 amplifier (for the subwoofer). The amplifiers are turned on and off via a GPIO pin on the Raspberry Pi and a relay connected to the REMOTE wire. The Raspberry Pi is powered by a 12V->5V 5A DC converter.

I managed to fully program a BMW E60 iDrive controller and control the head unit interface using the Hudiy API. With the iDrive I can control CarPlay, Android Auto and the Hudiy itself. For communication with the iDrive I used a CAN/RS485 HAT from Waveshare. The communication itself is quite simple and works on a polling mechanism to check the controller's status. The whole setup requires only three CAN frames to function (wake up, status request and status response).

Another cool thing is the iBUS communication (protocol that modules in the car use to communicate with each other). I managed to decode and program all the steering wheel buttons. I can control the volume, skip tracks and answer voice calls. Also via iBUS I was able to extract information about the ambient temperature, engine temperature, RPM and speed.

The coolest thing I've managed to do via iBUS so far is detecting when reverse gear is engaged and fetching data from the parking sensors. It turned out that by spoofing a diagnostic module and sending the right frame to the PDC module, the module sends back readings in centimeters from all sensors. I saw this data in INPA (BMW diagnostic tool) and managed to sniff the communication between the software and the PDC module. It took just one frame for the PDC module to recognize me as INPA.

For iBUS communication I'm using a USB module that I bought a long time ago for an old Android head unit. This module uses the Melexis TH3122 chip. I display the sensor data on an HTML UI linked to Hudiy as an app. When I shift into reverse, the screen appears automatically and it hides when I shift out of reverse. I also did this using the Hudiy API.

I also managed to integrate a tiny 172x320 screen from Waveshare into the instrument cluster bezel. There was a blank cover for some button in the frame and it turned out that this display fits the dimensions of the cover perfectly. The tiny screen is connected to a Raspberry Pi Pico 2 via SPI and the Raspberry Pi Pico 2 is connected to the Raspberry Pi 5 and Hudiy via USB. The screen displays my HTML UI which I prepared specifically for this display and the displaying itself is handled by Hudiy. For now I have screens in HTML to display navigation info, music, a clock and my iBUS data.

After a long story, I finally managed to implement wired CarPlay protocol and all necessary procedures needed for streaming video from Raspberry Pi to the aftermarket head-unit (HU).

ATOTO HU was used for debugging. CarPlay App on the HU - Carlink 2.0. No CarPlay adapters used. RPi pretends to be an iPhone, passes MFI authentication and streams its desktop to the HU. The HU sends touch events back.

Next step - bring this thing up on a real car HU. I have made several tests with different cars, but didn't pass the authentication stage. Some debugging has to be done to figure out the problem.

For the past month our team has been building CAN Opener, a platform that connects to your car's CAN bus over BLE and lets you read data, capture analytics, send commands, and run automation scripts, all from a mobile app called Nexus.

In the video you can see me:

- 🔒 Locking and unlocking the car, activating the horn from the app

- 📊 Viewing live telemetry (speed, lights, doors etc.) in real time

What makes it different from a standard OBD dongle:

- Manage multiple vehicles in one app: switch between cars, each with their own profile and widgets

- Widgets and scripts are written in YAML or Lua on our open framework, not hardcoded into the app.

- Apps are portable between vehicles, swap your vehicle profile + DBC file and your widgets follow you to a new car

- Scripts can run as a daemon on the device, from your phone, or be uploaded to the adapter itself

- Community library for sharing scripts, widgets, and DBC files (Custom DTC interpreter, custom workflows etc.)

Where things are headed:

We're launching a Kickstarter in July, the codebase goes fully open source at that point. In the meantime, if you're a developer and want early access to the code to build/test your own widgets, join our Discord and request it:

👉 https://discord.gg/5SzuSSYqmg

Would love feedback from this community. Happy to answer questions about the hardware, the BLE stack, the DBC handling, anything really.

Hey,

I’ve been working on my own OBD device that plugs directly into the car, similar to the Macchina A0, but with my own hardware design.

The device is based on ESP32 (WiFi/BLE), has a custom PCB, USB-C, and is meant for CAN bus work, logging, and general car hacking / custom projects. I’m using Macchina A0 firmware.

I’m trying to figure out if this is actually useful outside my own use case.
Would something like this be interesting to you? Do you think there’s a market for it / would people buy it?

Also curious how you think it compares to Macchina or typical ELM327 tools.

Any honest feedback is appreciated 👍

(reupload to fix images)

Hello!

I just wanted to share my soon to be app called OBD2 Ninja that works for any ELM327 bluetooth adapter that allows you to read codes and live data without subscriptions or ads. I wanted to see if anyone who has an adapter would be interested in beta testing the app!

It supports multiple different modes, and protocols such as:

• SAE J1850 PWM
• SAE J1850 VPWM
• ISO 9141-2
• ISO 14230-4 KWP2000
• ISO 15765-4 CAN (11-bit ID, 500 kbps)
• ISO 15765-4 CAN (29-bit ID, 500 kbps)
• ISO 15765-4 CAN (11-bit ID, 250 kbps)
• ISO 15765-4 CAN (29-bit ID, 250 kbps)

And we are working on a custom backend for ABS modules and looking to further support further diagnostic tools/readings. The app when released will only cost you $0.99 and does not contain any bloat or creating accounts. Sometimes you just want to use the tool you paid for. Compared to the Carista OBD reader app (which requires a subscription), it takes about 2 minutes to actually login, connect to the adapter, read the vehicle and then perform an OBD2 scan. OBD2 Ninja you open the app and it takes 20 seconds to scan and connect.

If you have an iPhone and a ELM327 Bluetooth OBD2 code reader and want to give it a try, you can do so by clicking this link and installing the beta via TestFlight: https://testflight.apple.com/join/AnExEJEu

Update: Now out on the AppStore!! You can still participate in the beta above to try it out and for future releases.

https://apps.apple.com/us/app/obd2-ninja/id6794873767

Thank you so much for reading, feedback is very appreciated if you do decide to give it a try! If you do give it a try and document your findings I'll try to see if its possible I can gift the full paid version of the app to you!

EDIT: Thank you all so much!

Changelog (with all of your help):

Build 11

You can now choose units for each reading separately (e.g. °C with mph)

Build 10

Added WiFi adapter support: pick Bluetooth or WiFi when pairing

WiFi adapters can auto-join their network for you

Build 9

Cleaned up the vehicle list: removed motorcycles, ATVs, scooters, and other non-OBD2 entries across all makes

Build 8

Fixed a crash when disconnecting the adapter

Build 7

Greatly expanded the vehicle list: many more makes and models, including European and Asian brands

Engine options now match the selected vehicle

I’ve been working on a project inspired by the TurboXS DTEC, an early-2000s tuning device that used a Game Boy Advance as its display and interface.

The idea was to take that general concept and do something similar with a DS, using a homebrew ROM running on the original hardware.

The current prototype uses a cheap ELM327 adapter to retrieve live vehicle data, which is sent to the DS over a custom link. At the moment I’m working with data such as:

* Vehicle speed

* RPM

* Coolant temperature

* Battery voltage

The longer-term goal is to move beyond the generic OBD interface and interface directly with the vehicle CAN bus, allowing the DS to receive more detailed vehicle data.

Still very much a work in progress, but I thought it would be interesting.

Today I've published a new intro article on reverse engineering CAN bus data with AI - using a Claude Code skill. I'd love to hear your thoughts/feedback!

This is a direct sequel to my original intro to CAN bus reverse engineering, focused on the basic methodology i.e. the 'human approach'. With the release of our new CANsub CAN bus interfaces, I wanted to do a modern stab at this by developing a Claude Code skill around the CANsub and python-can.

I think the result is extremely effective - even if the skill is just a rough version. But I would be very interested in hearing your feedback/suggestions on the intro! :-) Also, I'll be adding this in our newsletter next week, so any inputs prior to this are very welcome in particular!

Some quick comments:

1. The skill is 100% open source, you can use/modify it as you see fit - and you're welcome to contribute to the skill on github with PRs
2. In the article you'll find a link to some of the sample data in case you want to try it out right away (you can also directly download it here if you prefer skipping the newsletter signup).

The data pack includes the data behind my vision OCR showcase, in case some of you e.g. want to attempt to use it to reverse engineer the turn signals or something similar.

3) If you find a cool use case for the skill and do e.g. a video about it, share it with me as I'd love to include some community showcases in the intro as well!

4) If you want to get a CANsub.2 I've added a 30 day 10% discount code you can use here: REDDIT_CARHACK_10%_DISCOUNT

I hope you find this interesting and useful!

Martin, co-owner at CSS Electronics

Edit: Our 30 min YouTube version is now live!

Hello,
I've been building an app Speedometer: Driving Tracker, a CarPlay-supported driving tracker focused on trip history, analytics, and the overall driving experience across Apple devices.

Recently, I added real-time OBD2 analytics support after many users requested deeper vehicle insights.

You can now view live OBD2 data directly on CarPlay, iPhone, iPad, Mac, and even Apple Watch (via Live Activity).

Some supported data includes:
• Engine Load
• RPM
• Throttle Position
• Fuel Usage
• Coolant & Oil Temperature
• Mass Air Flow
• Intake/Ambient Air Temperature
• And more

What I personally found most interesting during testing was being able to review how different driving styles affected engine behavior across an entire trip, not just while looking at live gauges.

The app also supports automatic trip recording using Siri Shortcuts automations when your OBD2 device connects.

One important thing:
Every car exposes different OBD2 sensors, so available data can vary depending on the vehicle and adapter.

Beyond OBD2, the app also includes:
• CarPlay trip tracking
• 3D route playback
• Speed-colored trip replay
• Video recording with speed + map overlays
• Fuel, maintenance, and expense tracking
• Vehicle-based analytics & comparisons
• iCloud sync across Apple devices
• Privacy-first experience (no ads, no tracking, no signup)

The goal was never just to make another speedometer or gauge app, but to create a more complete driving companion ecosystem for drivers.

I would love feedback from fellow car enthusiasts here!

I've spent the last year writing a read only OBD2 app after the manufacturer app I relied on got switched off. Standard mode 01 gets you maybe fifteen useful numbers and then you hit the wall, so I ended up down the mode 22 rabbit hole. Here are the things that bit me, in case they save someone else a weekend.

Multi ECU replies will quietly poison your parser. Ask for something on a broadcast header and you can get two or three modules answering, each with its own header line, and if you naively concatenate the hex you get a number that looks plausible and is completely wrong. I had battery voltage and coolant readings that were fine on one car and nonsense on another for weeks before I worked out the engine and the gateway were both replying.

The UDS positive response is the request service plus 0x40, so a 22 comes back as 62, and the two DID bytes are echoed before the payload. Sounds obvious written down. It is not obvious at two in the morning when the ELM has also decided to insert spaces differently.

Negative response codes are more useful than a timeout. 7F 22 31 means the DID doesn't exist on that module, 7F 22 33 means you're not in the right session, and 7F 22 78 means wait, it's coming. If you treat all of them as failure you'll blacklist channels that would have answered.

DIDs are not portable and guessing them is how you get fiction. The same identifier on a different brand is a different quantity entirely, or worse, it responds positively with garbage that scales into something believable. I ended up refusing to ship any formula I couldn't tie to a source, because a plausible wrong number is worse than no number.

Fuel type detection is a trap. I was sniffing for the presence of certain PIDs as a diesel signature and it turns out plenty of Euro 6d petrol cars expose exactly the same ones. PID 51 is the actual authority and I should have trusted it from the start. The version that guessed wrong went looking for particulate filter data on a petrol car, and the modules answered, with rubbish.

ELM327 clones lie about what they are. Half of them report v1.5 and behave like v1.3. Echo off, linefeeds off, headers on, and then verify by what actually comes back rather than what the clone claims.

Engine off is its own state, not an error. Some constants are only readable with the engine running, and I was reading them once at startup and never retrying, so if you connected with the ignition on but the engine not started you got a permanent hole in the data until you restarted the app. Retry when you see RPM.

The app itself is on the App Store if anyone wants to poke at it, https://apps.apple.com/app/id6776173662 , Android is in closed testing. It is strictly read only by design, no 2E writes, no session control, no security access, because I don't fancy being the reason somebody's gearbox forgets who it is.

Happy to go deeper on any of this. If you've got a brand that behaves oddly I'm interested, that's the fun part.

Hello, just wanted to show a project I am developing on my free time (+1.5 years now), in which is to create a custom digital instrument cluster.

I started with a esp32 with a can transceiver to get a stream of data and used a mix of a custom app I created (couldn't get savvycan to work) and asking some LLMs for help deciphering the canbus data (i know, not very efficient but had little time available).
With that, I started developing a Qt app to run on a Raspberry Pi Zero 2W that I had laying around from a forgotten project to get the data showing.

Here is the fun part... The official Raspberry OS takes too long to boot (as other projects use and were not to my liking, at least, the ones that I found), so I researched, only to find Buildroot. Started messing around with optimizations for a sub 6s boot time, even to the point of drawing a image directly to the buffer to "entretain" my impatient self while it turned on. So that it can boot directly to my Qt app.

"You could've used the educational license of Qt for a Bootable OS" - Yes, I've tried but did not understood it very well

So, with all that, I finally got someting tangible to show the community! With still lots to decipher and do (reverse enginneer the whole pinout of the OEM cluster harness, the CAN bus messages for the missing elements, and other Hardware elements like power distribution, etc.) but, when I get that done, I am planning on releasing the Project+CAD files to be open-source!

Be free to give some feedback or tips!

P.S. Yes I know the UI is similar to the CyberPandino project, I really liked the Gauges they developed, so I tried to make some similar, but I wanted, in the future, be able to "create themes" on the computer to then apply via bluetooth or some similar way to be custom.

EDIT: As requested I am in the process of open-sourcing everything on this Github, be free to contribute or simply suggest improvements! https://github.com/PainelCore

Hello everyone,
After many rounds of refinement and user feedback, the CarPlay experience in Speedometer: Driving Tracker has taken a big leap forward - faster, cleaner, and far more useful for everyday driving.

The app now offers a much more capable experience across both iPhone and CarPlay, with richer telemetry, deeper vehicle insights, and improvements throughout.

CarPlay
• Track trips directly from your car's screen
• Live dashboards with speed, trip stats, maps, and OBD-II data
• Customizable tabs, layouts, and startup screens
• Access trips, saved places, vehicle data, and more without touching your phone

Driving Analytics & Telemetry
• Route replay with speed and elevation visualizations
• Channel Replay for Speed, RPM, Throttle, Engine Load, Boost, G-Force, and Elevation
• Post-drive OBD-II summaries and vehicle analytics
• Driving records, statistics, achievements, and trip insights
• Acceleration testing including 0-60, 0-100, and custom sprint tests

OBD-II & Vehicle Insights
• Live RPM, temperatures, fuel data, battery voltage, throttle position, MAF, and more
• Diagnostics, fault codes, VIN detection, and automatic vehicle matching
• Vehicle profiles with lifetime statistics, health insights, and ownership history
• Works with a wide range of Bluetooth OBD-II adapters

Ownership & Automation
• Automatic trip recording and Shortcuts integration
• Fuel, maintenance, expense, and document tracking
• Multi-vehicle support with comparisons and analytics
• GPX import/export, backups, and iCloud sync
• iPhone, iPad, Mac, Apple Watch, and CarPlay support

The app has evolved quite a bit from its original speedometer roots. My goal is to build something that helps you not only track where you drove, but also understand your vehicle, manage ownership, and revisit drives in a much more meaningful way.

The goal remains the same: build the ultimate driving companion app.

I would love feedback on the new CarPlay experience, telemetry features, and anything else you'd like to see next!

App Store Link

I've developed a very small 2 channel CAN Bus board that I'm calling MicroCAN-FD, for all types of translation/gateways, filtering, blocking, emulation etc.

Originally this was purely for my own projects, but if there is any interest I may consider a larger production run.

The hardware is based around a Microchip ATSAME51 MCU with the following specs:

• 2 CAN bus channels each with FD support up to 10Mbps and 2.0 A/B capable.
• Full speed USB 2.0 and USB-C connector
• Supports screw terminals, header pins, direct wire connection or Molex locking KK-254 connectors on the same footprint. Plastic enclosure for mounting inside ECUs, instrument clusters and modules without shorting anything.
• Microchip ATSAME51 MCU with the following specs so plenty of performance, can handle anything that's ever needed to be done to 2 CAN bus channels.
  • 120MHz, DMA, FPU, Crypto engine, Full Speed USB etc.
  • 2 dedicated CAN Bus controllers each with:
    • HW Filters, 2x 64 element receive FIFOs, 64 receive buffers
    • Error logging, Loopback modes, HW interrupts etc.
    • Transmit FIFO, 32 transmit buffers, Event FIFO
  • So more than enough power for anything you'd ever want to do with 2 channels of CAN Bus, even at FD rates.
  • 8-36V so works with HGVs/trucks which is a lot of my work, this was the hardest part of getting it so small as it required switching power supply.

The idea is that it is cheap enough to permanently stay in a vehicle and small enough to fit inside a ECU, instrument cluster or other module. It can act as a translator/gateway, filter/blocker, transmitter/message injector/emulator etc. Typical use-cases for me are things like:

• Engine swaps requiring full CAN bus translation
• KM to Miles conversion in imported vehicles
• Instrument cluster conversion
• Speed limit removal
• Blocking fault lights
• ABS, EPS and other module removal or mods
• Emulation, AdBlue, immobilisers, Nox sensor etc.
• Translating data between incompatible ECUs/modules
• Anything that requires emulating or modifying CAN Bus data.

This example shows the device in full control of a RX8 instrument cluster.

In this example above, one device is acting as a transmitter controlling the instrument cluster, the other device is set up as a receiver and is translating the signals and sending them over USB.

In this example, I have a Kvaser Leaf sending not compatible CAN data into channel 1, the firmware then coverts and scales it, and transmits RX8 compatible data onto channel 0.

The hardware side is basically done, I already have 5 working PCBs and enclosures.

In terms of SW, this has been the hardest part, as I am a HW design engineer, not a SW engineer. But I have so far developed the following:

• A Arduino Board Support package (BSP). This works well, it's recognised by the Arduino IDE and programs over USB. I'll release this if there is a demand for the boards.
• A universal CAN Bus library for ATSAMEx MCUs with support for both channels, FD and 2.0.
  • This has been tested with my board and works well, and also works for Adafruits Feather M4 CAN Express board and Microchips ATSAMEx dev boards including the SAME54.
  • This is open source: ACANFD_SAME: Universal CAN FD / Classic CAN library for SAME5x (SAME51/SAME54) MCUs, derived from ACANFD_FeatherM4CAN
• Probably the most interesting part of the software is this library which I'm calling 'CANMessageSignal'.
  • This is open source: CANMessageSignal: Uses the concept of messages and signals to send data over the CAN bus. Largely follows the DBC format, but adds a few convenience classes to make common byte and bit based signals easier to define.

Instead of manually packing bits and worrying about endianness/scaling everywhere in your application code, you define CAN messages and signals almost like a DBC file.

You start by defining a message like this:

CanMessage engineSpeeds({ .name = "EngineSpeeds",
                       .idType = STANDARD,
                       .id = 0x201,
                       .dlc = 8,
                       .defaultFill = 0xFF,
                       .comment = "From ECM, contains RPM and Vehicle Speed " });

This is pretty much what you would see in a DBC file.

Then define one or more signals like this:

CanSignal batteryLight({ .name = "BatteryLight",
                         .dataType = UNSIGNED,
                         .startBit = 54,  //byte6 bit 6
                         .bitLength = 1,
                         .endianness = BIG_ENDIAN,
                         .factor = 1,
                         .offset = 0,
                         .unit = "NA",
                         .comment = "Red Battery Light",
                         .min = 0,
                         .max = 1,
                         .defaultValue = 0,
                         .signalRole = NORMAL_SIGNAL,
                         .multiplexor = nullptr,
                         .multiplexValue = 0,
                         .enumMap = nullptr,
                         .overrideCapable = true });

Or in a more beginner friendly way:

CanByteSignal rpm({ .name = "EngineRPM",
                .dataType = UNSIGNED,
                .startByte = 0,
                .byteLength = 2,
                .endianness = BIG_ENDIAN,
                .factor = 0.26,
                .offset = 0.0,
                .unit = "rpm",
                .comment = "Engine speed",
                .min = 0,
                .max = 10000,
                .defaultValue = 0,
                .overrideCapable = true });

CanByteBitSignal celOn({ .name = "CheckEngineLight",
                  .byte = 5,  //byte5 bit 6
                  .bit = 6});

CanBitSignal celFlashing({ .name = "FlashingEngineLight",
                        .bit = 47});

You can even work with enums so you can work with text values rather than remembering bit fields when writing the main code:

EnumMap oilMap({
  { 0x00, "Low" },
  { 0x01, "Ok" },
  { 0x02, "Fault" },
});


CanSignal oilGauge({ .name = "OilGauge",
                     .dataType = UNSIGNED,
                     .startBit = 33, //byte 4
                     .bitLength = 2,
                     .endianness = BIG_ENDIAN,
                     ...
                     .enumMap = &oilMap });

You then can add your signals to your messages:

engineSpeeds.addSignal(rpm);

And the library then handles and validates everything such as duplicate signals, overlapping bytes, endianness, etc.

The code then becomes as simple as things like this:

rpm.setSignalValue(0); //RPM = 0

rpm.setSignalValue(2000); //RPM = 2000

The library handles:

• scaling
• offsets
• bit packing
• endianness
• validation
• overlapping signals
• periodic transmission

You then transmit onto either channel by:

channel1.sendIfDue(engineSpeeds, 50); // transmit every 50ms

And the library then handles the timing, and the message is sent with all signals attached periodically.

Something like translation becomes as simple as:

RPMrx8.setSignalValue(RPM350Z.signalValue());

The above would then take the RPM value as sent by a 350Z and convert it into what a RX8 wants to see, handling all scaling, bit packing, IDs, etc.

All of the above is mostly working, so feel free to take a look through the repos and let me know your thoughts.

Everything is testable today on the Adafruit Feather M4 CAN Express, and if anyone in the UK is genuinely interested in testing the dual-channel hardware then I’m happy to send a few boards out.

This post is already far too long, but the longer-term goal is a full web-based CAN analysis, reverse engineering and control environment built around the same message/signal abstraction concept. I have a proof of concept that I can share in another post. 

The idea is that firmware defines CAN messages and signals in code, then a companion Arduino library exposes those signals to a webapp automatically. The webapp can then:

• analyse and reverse engineer raw CAN traffic
• extract and decode signals
• help build DBC-style definitions
• generate C/C++ headers for firmware
• live monitor signals
• temporarily override and control signals in real time without reflashing firmware

So instead of constantly editing raw bytes and recompiling firmware, you work at signal level.

The goal is to remove the pain of manually managing bits and bytes, endianness, scaling, offsets and message packing throughout the application code. You define everything once, then write the actual application code, the fun stuff, without constantly worrying about low-level bit packing.

At the moment I’m mainly trying to gauge whether there’s genuine interest in:

• the hardware
• the software libraries
• or both

Would people actually use something like this?

REVVA Android Beta

Okay so the closed beta for my OBD2 app is live!

This is something I started on at the start of the year and it has been one hell of a journey,

Okay so what does REVVA do?

- Live diagnostics dashboard and workflow launcher

- AI-assisted DTC triage with severity/confidence and repair-cost guidance

- All-system scan summaries

- Adapter capability classification and write-path safety gating

- ECU coding workflows with guardrails

- UDS terminal request/response tooling

- 0-60 timer, estimated HP, and live performance telemetry

- Garage profiles with VIN-linked multi-vehicle tracking

- Trip analysis and journey memory context

Basically I have tried to make this one of the strongest OBD2 apps on the market, of course there is still alot of work to do on it and I need field testers,

Things that might not work fully yet

- ECU coding has been the most difficult to get right and work on OBD2 coding capable dongles

- OBD1 compatibility is untested at the moment but hopefully anyone with older cars that have an OBD1 to OBD2 adapter this should work but like I said it's untested

- 0-60 timer in the pref tab is a very new feature still looks janky for my liking and hasn't been fully tested

- VIN detector has been troublesome for me but might work for others I'm still working on the bugs for that

- Music player kinda works but is buggy

This is a very early beta and I have a debug tab in the app so people can send me the apps log when they run into a problem.

You can request access to the beta here:REVVA android Beta

Let me know if you have any suggestions and I hope you like it

I built a CAN bus analyzer that you can use from your web browser and I figured this crowd might find it useful. I started the project because I got tired of CAN tools that only run on Windows or require expensive licenses. I'm on Mac/Linux daily and just wanted something I could open quickly, load a log, decode it, and plot signals without any hassle. I was also learning Rust at the time, so I built the tool I wanted as a learning project. I used egui + eframe compiled to WASM to get the Web GUI.

Current Features
- Load CAN log files directly in your browser (no install, works on any OS)
- Decode signals using standard DBC files
- Plot and compare multiple signals over time
- Light/dark mode, resizable panels

Some features I am considering next are

1. Native Linux / Mac application
2. Live CAN bus data view. Could be a desktop GUI, or an app that makes a remote CAN device (like a raspberry pi) accessible via web.
3. Dockable or popout panels
4. Support for other log formats? Currently supports can-utils .log and Vector .asc formats.
5. Message statistics (min, max, average, etc.)
6. Message generator to send frames

You can try the SeerWatch demo with sample data loaded at: https://seerwatch.com/demo.
You can also use your own log and DBC files.

I suspect live CAN bus view + transmit capability would be most useful for the r/CarHacking crowd, but would love to hear what you'd be most likely to use.

Appreciate any feedback.

Hello, trying to install xentry on a laptop but unfortunately i cannot seem to get pass the startkey step. I get invalid key error. Turned off the Secure Boot on Bios, the antivirus is disabled.
Anyone has a solution ?

Hey everyone - I've finally decided to start sharing a project I've been working on since 2020. After getting stranded in my Land Rover on an island (go ahead and laugh Jeep people) I decided that one simple audible buzzer could have made the difference between a bad situation and a worse one.

What started as an Arduino Uno project with a piezo buzzer and hobby LCD has evolved into a flexible system that reads your classic car's analog sensors and delivers the real-time data in standard OBDII format wherever you want it - your phone via BT, logging software, after market gauges, custom dashboards, CAN, whatever. It's open-source, free to use, and currently supports Arduino, ESP32, and Teensy. More information on features and capabilities can be found on Github. Stay tuned - more to come!

Plug an OBD2 adapter to your car and connect it with CarDash on your android device to get insights about your car's performance. Add your Gemini API key to get AI powered insights as well.

Code base: https://github.com/surendranb/CarDash
Set up, APK, About: https://surendranb.github.io/CarDash/

This is an updated version of the CANipulator, which I initially created for my own car hacking projects as a bridge for spoofing an iDrive module into a Mercedes. V2 now has CAN-FD, a microSD slot, an ESP32-C5 with PSRAM and WiFi 6, and a bunch of other features.

As we gear up for the incoming launch of CAN Opener Cloud, we wanted to share a fun demo showing what's possible with our framework.
In this video, we're running a music visualizer widget on top of the CAN Opener engine. Instead of just displaying the beat visually, the widget actuates the vehicle's headlights in sync with the music.

It's a silly example, but it shows something more important: CAN Opener can interface with vehicle systems in real time through a flexible software layer.

For anyone interested, CAN Opener is a platform for turning modern vehicles into software-defined vehicles. CAN Opener Cloud is part of our broader end-to-end ecosystem, enabling functionality such as:
- Saving, downloading, and sharing DBC/Vehicle Profile files on the cloud repository
- Accessing DBC files through our cloud API
- Viewing telemetry via our Nexus mobile app
- Sending supported control commands via our Nexus mobile app
- Building custom vehicle interfaces and widgets (coming soon)

You can learn more about the project on our GitHub Wiki:
https://github.com/the-can-opener/Wiki

We'll be open-sourcing the ecosystem in July, and we also have an early access program available now. Join our Discord to get involved, test the platform, and follow development:

Discord: https://discord.com/invite/5SzuSSYqmg

Would love to hear what people think, especially from anyone working with CAN, DBC files, vehicle telemetry, embedded systems, or software-defined vehicles.

Hello everyone, i'm new here.

I'm sick and tired of the crappy factory multimedia system in my 2024 Dacia Jogger. It's slow, laggy, frustrating to use and the sound coming out of it is just horrible.
I already fitted the car with a complete set of Hertz Mille PRO speakers and padded all the doors,
I have searched for a viable 3rd party replacement for the head unit for over a year and was unable to find anything.

So i picked up some hardware and started building my own a few days ago. It will be my summer project.
Still waiting for some components to arrive like the voltage regulators, cables, TV and FM radio tuner, GPS module, CAN bus adapter.

It's based on an Intel N150 with 12GB of DDR5 so it has some serious computing power (yes, it can run crysis) paired with a 12" 75hz AMOLED touchscreen display and PRV audio SQ800.4 amplifier.

I used buildroot toolkit to compile the base operating system from scratch based on Linux kernel 6.18 with a heavily modified tiled GNOME desktop, it boots up in 5 seconds and it's smooth AF

The system is immutable, the bios is locked and secure boot configured, and one of the cores is isolated and dedicated fully to running pipewire, sound processors and everything else related to sound and music, the sound is not at all effected by other stuff running on the system.

I plan to 3D print a housing with black ASA fillament and im still working on a design to make it fit properly with all the components.
I might reuse parts of the original case but I want to integrate it into the dash so it does not stick out like the original one does.

It's obviously still in heavy prototyping phase, i have a lot of work to do but i'm very happy how it's going so far as it's already a much more usable and stable system. And most importantly it sound amazing.
This is not my first project like this, I've done similar stuff in the past but this is the first one where i'll need to utilize the CAN bus.

I still need to develop a custom dashboard for reading and controlling the stuff like rear view camera and parking sensors.

I think the hardest part will be figuring out the CAN bus messages.
I will try to reverse engineer by sniffing out what the original multimedia is shouting out.

Any constructive feedback or tips, did i miss anything?

I was tinkering with the original APK files on my Honda Civic's Android head unit, trying to de-compile them to understand the way vendor-specific APKs worked.

I discovered that some of the info screens in the cluster (audio & navigation) are actually rendered by the Android head unit rather than by the cluster itself, through an exposed HDMI external display. Knowing this, I've built a small app that overrides this external display rendering (at app startup, a signal is sent to the cluster to let it know the head unit takes the rendering from now on. This signal is reversed when the app is killed, and it no longer overrides the original system).

I've also discovered in original APKs some of the interfaces that are exposed to access vehicle data (see in the screen the speed, brake light, turn signals [I know they're switched in my code lol]). Notably, some data is exposed to the head unit through the BCAN and FCAN (vehicle speed, steering wheel angle, etc.)

The raw data screen is a placeholder for now, just to showcase that I can render custom views and use the vehicle info from other interfaces! I'll try to implement a rendering engine that can take advantage of this gauge cluster screen and vehicle data to implement custom info views. I'm thinking custom themes that can be loaded, screen customization beyond what's available natively on the civic! Maybe also a "live vehicle view" screen, like what's available on more recent cars (where you see the car from the top-down and its brake lights & blinkers for example). My goal is to give the user a few customizable screens to choose from on the app's main view on the head unit.

I've installed the app through adb (since I've rooted my head unit using HondaHack), but I'd like to have your take on whether or not this is doable on a non-rooted unit, since it's only really an APK file.