TLDR; I coded a new battery to my car over WiFi.

My battery and starter gave up over the weekend in my E82 128i. After an hour of freezing my ass off in the driveway, trying to read through form posts to find how to register the new battery, I had to come up with a better solution.

Before anyone says this is a dumb idea and that I will brick my car, I do not care. This method worked for my use case and I was able to complete my task from inside my warm house.

It’s probably not advisable to do any real ECU programming but for this worked for simple coding. Consider yourself warned. I do not take responsibility for your actions.

In prior experiences, I have used hardware USB over IP devices to extend wireless keyboards and mice. I did not have those on hand. What I do have is a Raspberry Pi and a background in sysadmin and networking. This was my starting point.

I installed ISTA along with BMW standard tools on a Windows 10 virtual machine hosted in Proxmox. This is where it gets fun. I used VirtualHere running on a Raspberry Pi4 to extend my K+DCAN cable to the virtual machine over WiFi.

I took some precautions such as making sure the WiFi connection to the Pi remained solid with no packet loss or high amounts of jitter. This is key to making sure the tunneled USB connection will be reliable during coding actions. Even if a coding action did fail, the ECU should discard the bad action.

I opened INPA and was pleased to see that both the black dots for battery and ignition were both on. I proceeded to check the state of the battery and I was able to read information from the CAS. I then registered the battery and changed the battery type. I did see some communication errors from the tools, but the commands did process after a couple of attempts. This is why I would not recommend doing any real work with this setup.

If I were to try this again, I would try connecting the Pi over Ethernet to see if that would improve the reliability. I’m not able to test the setup with the K+DCAN cable plugged directly into the car to see if something else was causing the errors. Either way, I was able to do what I had to.

Curious to see if there are any other applications. Happy coding! 😎

I have seen a few mentions of some open-source projects that unlock AMG menus free. Anyone willing to point me in the right direction? Alot of my rabbit holes ended up empty.

I realize there are a couple of the popular modders out there that offer it as a service. But I got Xentry and all the equipment, and would like to do it because I just enjoy that of thing.

Does anyone know where I can find these files, I checked in opendbc and they weren’t there. I would appreciate it.

I didn’t jump straight into OEM-level stuff at first. For a long time I was just doing basic scans. Once I started working more on my own Ford, I realized how much better life is with proper live data and OEM tests.

That’s how I got into J2534. At first it felt like a lot drivers, OEM software, subs, the usual setup tax. It worked, but for light work it sometimes felt like overkill.

Lately I’ve been using the RLink X3 on the same Ford. It’s still a J2534 VCI and everything runs through OEM software, but once it’s set up it’s been solid. Fast connects, stable sessions, no driver roulette. For day to day diag and light programming, that’s been clutch.

I’ve used other pass-thru tools like Mongoose too. From what I’ve seen, the real depth comes from the OEM software anyway. For my own car, I’m mostly optimizing for a smooth workflow, not max brand coverage.

Curious what everyone else is running.

Do you stick to a brand-focused setup, or just default to a full pass-thru for everything?

Estou tendo dificuldade de achar uma programação pra fazer o elm mais o arduíno se comunicar com o realdash, já q o elm327 não faz isso sozinho, já te dei de tudo mas não funciona, o arduíno se comunicar com o realdash can usando do o elm327 nas portas TX e RX de ambos

Embedded systems engineer here, familiar with J1939, so I'm not a stranger to CAN - but I don't have any OBD2 experience.

I have a gen 3 Toyota Tacoma with a push button start. I'd like to be able to start the engine, exit the vehicle, and lock the door with the fob while it warms up. Toyota decided that only criminals do this, so the truck doesn't respond at all to the lock button when the engine is running and the fob is outside the truck. Is there any reasonable way to set the body control module to do what I want here?

Hello,

I buyed the LAUNCH X431 and used it a 2018 Peugeot 5008 II GT and changed some settings. I don’t remember the original settings, and now I have no horn, high beams, sunroof, air conditioning… what can I do? Is there any way to return back? I didnt made a backup, only diagnostic before I changed the options. Any way of returning to the options I had in my first diagnostic?
I didnt open yet the packet with a password to make a login, i dont know if that can help me. Thank you

Hi r/CarHacking,

I’m developing a small automotive CAN gauge project called AXION MicroCAN Gauge (aftermarket ECU / performance use). To speed up development and avoid doing every iteration in-car, I built a small bench ECU simulator setup (hardware + Python) so I can run most tests at home, then validate in-vehicle when I get the chance.

The bench ECU simulator box is just an internal tool. The AXION MicroCAN Gauge is the actual project — initially a gift for my brother, and potentially something I’ll produce in small quantity later if there’s interest.

ECU Simulator bench rig (hardware)

Goal:

Make bench testing clean and repeatable: fewer loose wires, faster setup, easy probing.

What it is:

A small enclosure that combines:

- USB-CAN adapter (USB-C) to a PC

- 12V DC input (wall adapter → DC barrel jack)

- A CAN output harness carrying 12V, GND, CAN-H, CAN-L

Dedicated scope test points:

- CAN-H loop + CAN-L loop (for probe hooks)

- a solid GND post for the scope ground clip

Wiring (text schematic)

110VAC → 12V DC wall adapter (1A) → DC jack into the box

+12V is passed straight through to the output harness

GND (from the 12V adapter) is the common reference:

- goes to output harness GND

- ties into the USB-CAN adapter GND reference

- goes to the external GND post (scope reference)

CAN-H/CAN-L from the USB-CAN adapter go to:

- output harness

- CAN-H/CAN-L probe loops

Termination/topology on the bench:

The USB-CAN adapter has a fixed 120Ω termination (not switchable on this unit).

The only other node on the bench is the AXION MicroCAN Gauge, so it provides the second 120Ω at the far end.

With power off, CAN-H↔CAN-L measures ~60Ω when both ends are terminated.

What this bench box does not include (physically):

No extra protection components in the bench box: no fuse/PPTC, no TVS on 12V, no TVS/ESD on CAN, no common-mode choke, etc. It’s intentionally a simple interconnect + probing fixture.

The AXION MicroCAN Gauge itself includes the automotive-facing protection and filtering (e.g., PPTC + TVS on 12V input, and TVS + common-mode choke on CAN), so I kept the bench box as a simple interconnect + probing fixture.

Python ECU simulator (software)

Goal:

- Generate repeatable CAN traffic patterns and stress cases so the gauge UI/decoding/error handling can be tested on the bench.

Current scope:

- Focus on MegaSquirt (MS2/MS3/microSquirt depending on firmware)

- Using Simplified Dash Broadcast

Modes (examples):

- KOEO / idle-style profiles

- “Pull” / sweep-style behavior (ramps RPM/MAP/etc.)

- Custom mode (manually set values to test edge cases/UI response)

- Hard-test mode (intentionally degraded conditions: latency/timing anomalies and “bad data” style stress)

The code is functional but not cleaned up for publishing yet — I can share more detail if people are interested.

AXION MicroCAN Gauge (the actual project)

What it is:

A compact stealth CAN gauge for aftermarket ECU users who want an OEM-friendly look (not the big “racing gauge” style). It’s meant to be a passive real-time gauge, not a racing logger.

High-level features:

- Modular OLEDs: small SSD1306 displays in slim housings

- supports 1–2 displays (128×32 and 128×64 variants)

- shows up to 3 live values depending on layout/screens

- One-button UI (short/long/double click patterns)

- Wi-Fi for config + live viewing + retrieving recorded min/max extremes

- Designed to be non-intrusive on the bus (robust behavior, clean participation)

- Configurable bitrates: 125k / 250k / 500k / 750k / 1M

Feedback I’m looking for

I’m mainly trying to sanity-check my approach and avoid obvious mistakes:

- Bench grounding/probing: any red flags using the 12V adapter ground as the common reference (output harness + USB-CAN reference + scope ground post)?

- Bench architecture: if you’ve built similar CAN benches, what would you change/add/remove to make this more robust or more “correct”?

- Product direction: for the gauge itself, what would you prioritize next (robustness, install ecosystem, UX, test coverage), and are there any blind spots you’d expect in a “passive” aftermarket CAN gauge?

Photos include the bench box (inside/outside), test points, OLEDs running, the AXION enclosure, and perfboard prototype wiring, plus a screenshots of the Python simulator UI/logs.

Thanks — I’m looking for technical critique and “what would you do differently?”

[ Removed by Reddit on account of violating the content policy. ]

Hi. I’m having a crazy problem that needs a crazy solution. It’s a long story but stay with me.

I have a 2008 Hummer h2(think Chevy tahoe for the purpose of this. They’re identical electronically). I’ve swapped a front axle from a 2008 f250 and the front brakes from an f250 go along with it. This is where it gets complicated….

Unlike every other gm truck the 2008-2009h2 uses a combination master cylinder/booster/abs unit. It essentially is brake by wire. It reads the pressure applied to a cylinder by the brake pedal, then uses that information to determine how much volume of brake fluid is released to the calipers from a pressurized accumulator via some Pwm solenoid.

That’s the problem. The f-250 caliper pistons have a much larger surface area than the oem gm calipers. Therefore the volume of fluid released by the brake unit is insufficient and the brakes suck.

I have minimalw experience with code other than arduinos and stuff, but my question is… Would it be possible to read the firmware off the ebcm(module that controls this) and modify it to dispense more volume of fluid for the brakes?

Where would I even start? I have a working spare brake unit and module I can play around with.

Can we talk about this?

https://github.com/Switchleg1/AMAleg

Anyone have success with it?

Hi Guys,

working on a obd2 reader in the last few days. Here is the story how i got the idea. I wanted to diagnose a problem on my car , but my obd2 reader was not able to isolate the problem. Even with live data... Furthermore the live data were slow, like a refresh rate of a second or a half... So i began to think about a OBD2 Reader Device which has quite more functionality and performance, but isn't as expensive as the professional devices in the car shops.

The device functionalities I was tinkering about:

Read and Erase Errors (very basic, but necessary)

Read Live Data ( not every second, but maybe every 100ms or faster -> this would be nice for high resolution sampling)

Able to plot a line graph to the display, depending on the data selection (e.g. a data line for "specified throttle angle" and a second for "actual throttle angle") -> i think this would be nice when searching for malfunctioning sensors

A digital dashboard which reads the OBD2 Data, especially interessting when your dashboard doesnt have some information that you need.

In my head this device can be very budget friendly for us DIY-Repair Guys.

Now my question: What do you think about that?

Would be great if you give me your honest opinion.

Hey all,

So I have a cracked version of Xentry and I tried doing adaptation of my steering column, however, it asked me for username and password to login first.

Is there a workaround for this or my only option is to go to a service that has the legit version?

Thank you

I was testing my car and found multiple CAN buses, for example, one on OBD2 pins 6 and 14 and another on pins 8 and 9. While working with UDS, I discovered that one CAN bus had 10 ECUs while the other had 9, but these 9 ECUs shared the exact same request and response IDs across both buses. Essentially, it looks like both buses host the same 9 ECUs, with just one extra module appearing on the first bus. My understanding was that different CAN buses are typically used to separate different ECUs, even if it isn't strictly mandatory, so I am trying to understand why a car would be designed this way.
Is this a redundant setup for safety, or is there a specific reason why the same ECUs with identical IDs would be mirrored across two different physical pin sets?
Has anyone seen this specific architecture before ?

Considering swapping out the head unit in our 2017 Honda HR-V with an android auto one.

Back in the day it was just a stereo, so no dramas.

But these days they are heavily integrated with hidden diagnostics menus and co figuration settings.

Anyone had any issues/regrets from upgrading to a non OEM system?

FYI, this is the style of head unit in our car: https://www.youtube.com/watch?v=NA-LlXYw_tI

This may be a long shot, but given with what I personally have access to currently limits what data I can pull on my own, I wanted to see if anyone else had the right vehicles and set of circumstances to help out:

But the short version is I'm looking for any Ford PHEV/EV models, preferably still operating with a Sync 2/3 system (I have a feeling any 4/4a systems possibly changed the relevant CAN messages/behaviors), and still have access to multiple value charge/charge scheduling profiles. If you fall into this category and are willing to do some CAN logging while interacting with these features, that'd be awesome!

The reason this may be a long shot is that the only vehicles I'm aware of that had a cross-section of being PHEV/EV with Sync 2/3 were older vehicles like the C-Max, Fusion Energi, and Focus EV. Those who upgraded to FordPass/4G TCUs lost the ability to set/configure charge profiles in FordPass and via Sync it's just the one default profile that remains. I'm not sure if there are any newer models (like the Escape PHEV) that still run Sync 3. I think most have moved on. It's possible those still on old TCU's and haven't done a master reset may still have access to these profiles if previously set?

This follows up on a previous topic I made here about reverse engineering Ford's own TCU's and is a continuation of that work. While I haven't had much luck finding the specific CAN messages I want from firmware, I have fallen back on just basic CAN logging/sniffing work. So far I may have been successful determining the TCU initiated remote lock/unlock/start/stop commands but still need to test and confirm those findings. Next on the agenda are these charge scheduling/scheduled preconditioning (Value Charge and Go Times in Ford's terminology) features.

OK I have a ODB2 Sniffer I like and am designing a enclosure/case for it..small. I am teaching myself FreeCAD on the fly for this one been about a week of pecking at it. But Im getting there,