Pages: [1]
Author Topic: Reverse Engineering UART? LIN? AirLift Controller/Manifold  (Read 2854 times)
adam-
Hero Member
*****

Karma: +122/-33
Offline Offline

Posts: 2177


« on: April 14, 2020, 01:07:27 PM »

Hello,

As the topic suggests, I'm wanting to reverse engineer my AirLift controller/manifold to understand the communication between them and ultimately be able to inject my own commands.  Ideally, all I want this to do is air out when I remove the key.  I understand I could just tap into the button and 'mimick' a button press, but being able to understand pressures would be cool too.

I've attached a .png of the captured data.  The first part up to F3 is the controller (as this same chunk is repeatable with the controller disconnected as it tries to find the manifold).  Connect the manifold and the next chunk of data is transmitted.  I don't know if goes controller > manifold > controller or just controller > manifold.

All I've managed to learn so far is that it's 9600 baud (due to the timings between the shortest high/low).

Has anyone done anything similar and do they have any idea where to begin?  The chip on the controller is a LIN (and this is confirmed with the AirLift docu.) but that's as far as I know.  I can't even see standard LIN comms (of 0x55).  Does anyone know how to set up PulseView to show actual meaningful data or how to begin understanding what's being transmitted?

Appreciate that this is probably the most nooby question ever, but I need arm bands for this shit.
Logged
H2Deetoo
Sr. Member
****

Karma: +26/-1
Offline Offline

Posts: 255


« Reply #1 on: April 14, 2020, 02:25:01 PM »

I once did an analyze of the LINbus communication between Passat CCM and ELV unit.

Standard LIN uses a 6 bit message ID and 2 parity bits.
The ELV LIN bus uses a 5 bit message ID and 3 parity bits.

//ELV LIN - 9600bits/s custom parity
//bit_7 = not ( bit_0 ^ bit_1 ^ bit_3 )
//bit_6 = bit_0 ^ bit_2
//bit_5 = bit_0 ^ bit_3 ^ bit_4


 Frame ID is first byte including 3 bit parity
* Frame ID & 0x1F results in 32 possible Frames (commands)
* Frame ID contains also the len (FrameID - 2 is len)
* LIN ELV bus is 9600b/s
* seems they do NOT use BRK and SYNC bytes (as is what is usual for linbus), just plain data

Maybe this helps understanding it better.


Rgs H2Deetoo
Logged
aef
Hero Member
*****

Karma: +69/-46
Offline Offline

Posts: 1566


« Reply #2 on: April 15, 2020, 12:23:38 AM »

http://canhacker.com/projects/lin-bus-analyzing-tool/

https://github.com/macchina/LIN/blob/master/examples/Sniffer/Sniffer.ino

https://www.lipowsky.com/assets/files/downloads/english/LIN_Basics_for_beginners.pdf

this should work better than you logic analyzer
« Last Edit: April 15, 2020, 12:35:37 AM by aef » Logged
adam-
Hero Member
*****

Karma: +122/-33
Offline Offline

Posts: 2177


« Reply #3 on: April 15, 2020, 12:46:30 AM »

Maybe this helps understanding it better.

I think so.  I'll write down what one byte is first and try and attack it that way.  How did you end up figuring it out?  Is there a 'nack' to it?
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.014 seconds with 16 queries. (Pretty URLs adds 0s, 0q)