What's this protocol? - Page 1
Forum section: electronics / beginners

author: viperidae
author_rank: Frequent Contributor
timestamp: February 03, 2019, 03:58:12 am
content: I'm playing around with the radio/navigation/hvac in my car and probed the communication bus between the radio unit and the HVAC, which is the only interface for some of the controls.The two wires are labelled I-B-F and I-B-DATA on the radio PCB.I've attached a capture from sigrok PulseView, with a UART decoder set to 19200baud, even parity and 1 stop bit. It's the only combination that didn't result in parity or framing errors.There are at least 3 devices on this data bus, all of them connect via 4 pins of various microcontrollers. Each wire is connected via a 10k resistor to one pin and a diode and 100R resistor to another pin.Both lines are usually at ~5V and get pulled low by I assume the diode/resistor pins.It looks like when a device wants to communicate, it pulls I-B-F down low, then sends UART data on I-B-DATA, followed by letting I-B-F float high again.Has anyone seen this before? Does it have a name? Is it as simple as UART via open-collector and pull ups?For reference this is the navigation/cd changer system in a 2005 Japanese import Honda Accord.I think the HVAC module is the same in all the dual-zone A/C Hondas of the era. It has setting resistors on the PCB for various options.

author: MavMitchell
author_rank: Contributor
timestamp: February 03, 2019, 10:25:21 am
content: I would say this is a manufacturer proprietary protocol.Generally the only commonly used automotive bus is based on (bosch I think)CAN at much higher speeds than you are seeing..

author: Doctorandus_P
author_rank: Super Contributor
timestamp: February 03, 2019, 01:30:04 pm
content: Looks like some proprietary protocol over defacto UsARTs, with 10 or so stop bits.These could be intentional or quasi random with a slow uC.LIN is also used in car's (and works with (almost) standard Uarts, but it has a specific header and a "break" which is about 11 bit's long.the 10k resistor goes to the RxD input.The low value transistor and diode are are for output protection and diode or-ing / anding (depending on the direction).You can have a bit more certainty by zooming in more and looking if the flanks of the individual bits lign up properly with the decoded data.The next step is to figure out what those bits actually mean.I'm curious:What kind of hardware are you using with Pulseview/Sigrok, and how well does it work?I only have some Cypress CY7C68013 boxes and these only do digital, your first yellow trace has noise and looks very analog

author: viperidae
author_rank: Frequent Contributor
timestamp: February 04, 2019, 12:29:51 am
content: I did zoom in and the bits almost perfectly align with 19200 baudThe processors aren't slow, at least one is a 16bit fujitsu one, where the lines do go to UART pins.The diode is arranged so the Tx pins can only pull the line low.The limitation of my test gear right now is cheap multimeters, a cheap logic analyzer and a Hantek 6022, which is what I used with sigrok.I used the hantek software to figure out it looked like serial data, so downloaded sigrok for its protocol decoding.My car seems to be full of different protocols...CAN for the main ECU busGM-LAN "single wire can" for the body networkI think the OBDII connector has K-lineIEBus for the audio/navigation systemWith the same module used in quite a few models I was hoping someone recognised it.This proprietary one for the HVAC.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: February 04, 2019, 02:41:03 pm
content: OBD II connector seems to be able to have both CAN, K-line and more:https://en.wikipedia.org/wiki/On-board_diagnosticsIn Pulseview you can stack decoders on top of each other.If Pulseview knows your protocol you might get lucky, if not, it might be somewhere on the 'net

author: biot
author_rank: Regular Contributor
timestamp: March 11, 2019, 03:13:39 pm
content: Quote from: viperidae on February 03, 2019, 03:58:12 amSo if there's 3 or more devices on this, it's an actual bus -- not UART. You might have better luck with the SPI or I2C decoders. But you left the best part out of your screenshot: the timing markers! It's generally better to post either a complete screenshot of the whole capture if it's short, or just a sigrok, vcd or whatever file. SPI is easy to spot: one pin will obviously be a clock, and you'll likely find a chip select pin going high or low right before transmission.First off, find the shortest high or low pulse in your capture. that's a single bit, and the timing markers (use cursors) will tell you how long that bit took to transmit. 1 / (this time in seconds) = your signal's bitrate in Hz.Next, figure out how many bits are transmitted per byte. If not all transmissions are the same length (in bit-length increments), perhaps their common divisor is the per-byte length. Sometimes you can just spot it.Only then can you start taking a look at what's being sent. In the payload, look for some sort of addressing scheme; it's quite possible the different devices on the bus will send their ID along.

author: viperidae
author_rank: Frequent Contributor
timestamp: March 12, 2019, 10:10:56 pm
content: I've been successful in reading the data with an Arduino, then transmitting the packets to a PC.The data makes relative sense, I can see changes in the bytes when things in the system happen - buttons being pushed, etc. Each packet appears to have a source ID, packet type, destination ID and some data.The destination always responds to the source with an acknowledge packet.The timing is 19200 baud uart. The screen shot I posted has both signal lines and above it is a sigrok protocol decode of 19200 baud 8E1 uart.What i'm now trying to figure out is how to manage the sync of the I-B-F line (which I assume the F stands for Frame) and the I-B-DATA line with hardware UART signals.It may not be possible but I'd prefer some hardware help instead of managing it all with software.Currently my target device is an STM32F, which has RTS and CTS flow control. I'm not sure if these signals can be configured in a way to make it work though.I think the arbitration is "Don't send data if the F line is low. Pull F line low when sending data". Does anyone know if the STM32 flow control can be configured like this?

author: mikerj
author_rank: Super Contributor
timestamp: March 13, 2019, 07:11:56 pm
content: RTS/CTS is not appropriate in this case. In the USART the RX asserts/deasserts the RTS pin and the TX listens to the CTS pin i.e. neither line is useful to tell the RX to start listening.I should be simple enough hook the I-B-F line to pin configured as an external interrupt (some filtering would be wise to reject glitches) and enable/disable the USART RX in the interrupt handler and clear or process any buffers as needed.

author: viperidae
author_rank: Frequent Contributor
timestamp: March 13, 2019, 10:14:02 pm
content: I was thinking about using CTS to synchronise the TX.If I tied the CTS pin to the one reading the I-B-F line, when I pull it low to start the transmission, it will start transmitting. I can then disable TX when the transfer is complete so another device on the bus doesn't cause mine to transmit anything.Does that make sense?

author: mikerj
author_rank: Super Contributor
timestamp: March 14, 2019, 05:22:41 pm
content: I didn't realise you wanted to transmit as well, I read it like you just wanted to monitor the bus. What you suggest seems like an indirect way around around the problem i.e. controlling the TX output on a micro by toggling the CTS line with another pin! This could all be handled in software with negligible overhead.