| Electronics > Beginners |
| What's this protocol? |
| << < (2/2) |
| biot:
--- Quote from: viperidae on February 03, 2019, 03:58:12 am ---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. --- End quote --- So 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. |
| viperidae:
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? |
| mikerj:
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. |
| viperidae:
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? |
| mikerj:
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. |
| Navigation |
| Message Index |
| Previous page |