Reverse Engineering Proprietary 1-Wire Automotive Protocol (BLDC Fan)

[themaxmad]

Hi everyone,

I am currently reverse-engineering a set of automotive BLDC fans (integrated controller) from a modern vehicle to run them on a test bench without the main ECU.

I have successfully characterized the Physical Layer (PHY) and Protocol for one variant of the fan, but a second variant (presumably on the same bus) is unresponsive. I’m looking for insights on whether this protocol resembles a known standard or suggestions on how to "fuzz" the wake-up sequence.

Below is everything I found about the Physical Layer:

• Interface: 2-Pin (12V/Data, GND).
• Signal: Single-wire, Active High.
• Encoding: Variable Pulse Width (similar to NEC IR, but over wire).
• Logic 0: ~900µs High
• Logic 1: ~1800µs High
• Delimiter: ~500µs Low between bits.

I successfully mapped the driver for the first variant. It uses a 13-bit frame structure as follow: [Header: 3 bits] + [Payload: 4 bits] + [Check/Echo: 4 bits] + [Stop: 2 bits]. Sending 110 or 111 as the header works perfectly to control speed.

However, the second variant that uses the exact same connector and form factor but ignores the 13-bit frame entirely.

I have tried:

• sweeping the Header (0-7),
• standard LIN-style breaks (low for 13+ bits),
• holding the line High for long durations (Sync)

but nothing yielded any results.

Does this 900µs/1800µs active-high encoding resemble any known obscure automotive standard (K-Line variant? ISO 9141 custom?)? In these types of 1-wire bus topologies, is it common for different slaves to require a drastically different initialization sequence (e.g., a specific voltage level or current pulse) to wake up? Any tips for "blind fuzzing" the wake-up signal without risking damage to the MCU input?

Thanks!

[voltsandjolts]

BMW or Merc?
There may be some info in here but I ain't watched it.

[negativ3]

Is the 1-wire comms all one way i.e. master to slave?

[Manul]

It would be much easier to capture communications in the vehicle instead of trying to brute force it in the lab. Why is it not an option?

[themaxmad]

BMW or Merc?
There may be some info in here but I ain't watched it.

Merc, W222, in case you need the VIN here it is: WDDUG8CB4EA048908.
That's an interesting video, I'll take a look at it, seems that it talks about LIN, even if I already tried that option I'll still check if I missed something.

[themaxmad]

Is the 1-wire comms all one way i.e. master to slave?

Yes, looking at the schematic of the car electrics in a tool call WIS and using their terminology, the master seat control module (N32/1) "request" seat ventilation, and the fans (M18/9, M18/10) "actuate".

[themaxmad]

It would be much easier to capture communications in the vehicle instead of trying to brute force it in the lab. Why is it not an option?

I wish this was an option, sadly an S-class is not the cheapest car to have around...

I could buy the module separately, problem is there's quite a lot of them just to actuate some BLDC fans... Buckle up! 

According to the wiring of the car, to "actuate" the fan (M18/9, M18/10, they were 150$ genuine from Mercedes to give you an idea of the pricing), you need to press a button on the door card, the door card communicate through LIN B5 to the door control unit (N69/1), communication is both ways. Then the door control unit communicates on CAN B to the SAM control unit (N10/8), communication is both ways. HOWEVER to use the SAM control unit, you need to have the instrument cluster (A1) that give order through CAN HMI (one way) to the Electronic Ignition Switch Control Unit (N73) that give order through CAN B (one way) to the SAM control unit (N10/8). Then the SAM control unit (N10/8) communicates with the seat control unit (N32/1) through CAN B, communication is both ways. And FINALLY after being well deep in debt of all those modules, you have the seat control unit (N32/1) that "request" the fan (M18/9, M18/10), communication is one way, and the fan (M18/9, M18/10) "actuate". Congratulations! 

[PCB.Wiz]

Does this 900µs/1800µs active-high encoding resemble any known obscure automotive standard (K-Line variant? ISO 9141 custom?)? In these types of 1-wire bus topologies, is it common for different slaves to require a drastically different initialization sequence (e.g., a specific voltage level or current pulse) to wake up? Any tips for "blind fuzzing" the wake-up signal without risking damage to the MCU input?

Did you check it against the SENT (Single Edge Nibble Transmission)  bus ?

Google says this

Key Timing Components
Tick (UT - Unit Time): The fundamental time unit, configurable by the sensor, generally 3-90 µs, with 3 µs being a common nominal value.
Calibration Pulse: A 56-tick period (e.g., 840 µs at 15 µs/tick) that calibrates the tick period for the receiver.
Nibble Encoding:
Starts with a fixed low period (e.g., 5 ticks).
Followed by a variable high period (e.g., 12 ticks for '0000', 27 ticks for '1111').
Total nibble time (low + high) varies from 17 to 32 ticks.

Do the fans reply with any information?

An alternative would be to build something like a learning remote, that sniffs on a working install, and you then playback on the test bench.
That's easier for simple send only checks, it's not so easy top check correct error codes.

[themaxmad]

Does this 900µs/1800µs active-high encoding resemble any known obscure automotive standard (K-Line variant? ISO 9141 custom?)? In these types of 1-wire bus topologies, is it common for different slaves to require a drastically different initialization sequence (e.g., a specific voltage level or current pulse) to wake up? Any tips for "blind fuzzing" the wake-up signal without risking damage to the MCU input?

Did you check it against the SENT (Single Edge Nibble Transmission)  bus ?

Google says this

Key Timing Components
Tick (UT - Unit Time): The fundamental time unit, configurable by the sensor, generally 3-90 µs, with 3 µs being a common nominal value.
Calibration Pulse: A 56-tick period (e.g., 840 µs at 15 µs/tick) that calibrates the tick period for the receiver.
Nibble Encoding:
Starts with a fixed low period (e.g., 5 ticks).
Followed by a variable high period (e.g., 12 ticks for '0000', 27 ticks for '1111').
Total nibble time (low + high) varies from 17 to 32 ticks.

Do the fans reply with any information?

An alternative would be to build something like a learning remote, that sniffs on a working install, and you then playback on the test bench.
That's easier for simple send only checks, it's not so easy top check correct error codes.

Yep, I tried this also, but got no "response" from the fans, which is not surprising, the electrical diagram said the signal is a one-way communication from the seat control module to the fans. I did not push it too far then since SENT according to Wikipedia is "a point-to-point scheme for transmitting signal values from a sensor to a vehicle controller". The situation we are in is the inverse: the vehicle controller (the seat module) transmits signal values to the actuator (the fans), so I think it's a dead-end.

Again, I would love to sniff the frame, just reproduce it, reverse-engineer it by tweaking the timings or switching the bits and call it a day. That's what I did for the first variant, I found someone who posted a scope capture three years ago of his signal he was getting, I reproduced it, tweaked it a little, it worked fine. But when I reached out to him, he said that he doesn't want to dismantle the seat inside his new car (which most certainly have the fans I also have on hands) to sniff the new signals, which I respect and understand. The new reframed problem would be that I need to find someone who has an S-class (which is already not trivial), specifically a W222 (and it must be compatible with the genuine most up-to-date pieces part from Mercedes because not all of the W222 are), and has an oscilloscope to sniff the frame, so someone who is first ready to help, knowledgeable enough to understand electronic and how an oscilloscope work, and finally who is not fearful to temporarily tear apart the seat inside his (very expensive) car...

[negativ3]

Do you have a photo of the fans (M18/9, M18/10)?
I assume you are doing this interfacing without access to the seat control unit (N10/8)?
The ability to see/check if M18/9 and M18/10 are on a common bus would help.

Have you tried inverting the protocol which works with M18/9? Real guesswork!

[themaxmad]

Do you have a photo of the fans (M18/9, M18/10)?
I assume you are doing this interfacing without access to the seat control unit (N10/8)?
The ability to see/check if M18/9 and M18/10 are on a common bus would help.

Have you tried inverting the protocol which works with M18/9? Real guesswork!

Sure thing!

First image attached is M18/9 (seat cushion seat ventilation motor, the first set which I managed to make them work perfectly). 2-Pin, Mercedes P/N and ebm-papst P/N on the wire harness, made by ebm-papst, one yellow wire with red trace and one brown wire, PHY layer known, working fine.

Second image attached is M18/10 (backrest seat ventilation motors, the second set that don't respond). Same 2-Pin, Mercedes P/N and Elektrosil P/N on the wire harness, made by Y.S. Tech, one yellow wire (no red trace) and one brown wire, PHY layer different?, nothing.

Third image attached is the electrical diagram where you can see both M18/9 and M18/10 are "actuated" by the same N32/1 seat control module.

Forth image attached is the electronic diagram for the N32/1 module, and I marked in red where the M18/9 and M18/10 components are, as you can see they are both inside a group, they are both driven by M+ and go back to Circuit 31, which is GND in Mercedes terminology from what I read online. That's why I'm thinking they share a common bus.

Fifth image attached is my Arduino circuit to drive those fans just in case.

Yes I'm doing the interfacing without any access to the seat control module (N32/1), the SAM control unit (N10/8), the door control module (N69/1) or the door card.

Hope those pictures help! If you need more details let me know I'll do my best to provide them as fast as possible.

And I tried inverting the protocol but sadly no it didn't work...