Help needed in reverse engineering a LIN protocol

Projects Networking, Protocols, and Devices
1

im trying to reverse engineer an ECU / GSU protocol from a model airplane jet turbine, in order to make a telemetry adapter.
i have decoded several other protocols in the past with good success but this one is extra stubborn and so i thought i would ask for assistance.

I have an Arduino Nano as the GSU emulator, with a LIN transceiver and verifying communication on a Saleae logic analyser.

the ECU uses a LIN interface but on a proprietary protocol unknown to me. in order to read it i am using an Arduino with a level shifter, and i verified the incoming data is correct.

When ECU is stand alone, it send several strings which appear to be interogations for bus nodes, but nobody is replying obviously.

0x0A 0x00 0x00 0x00 0x00 0x0A
0x14 0x00 0x00 0x00 0x00 0x14
0x1E 0x00 0x00 0x00 0x00 0x1E
0x28 0x00 0x00 0x00 0x00 0x28

When the GSU is connected to the ECU, it responds immidiately (0.2ms) after the first string (0x0A 0x00 0x00 0x00 0x00 0x0A), with a 6 byte reply. each time its a slightly different reply.

this reply is followed by the ECU sending a stream of data, which is the data i need to read.

i tried emulating some of these GSU replies with Arduino, but the ECU never sends the stream of data back on the bus if the arduino is interogating it, it just ignores it and continues interrogating as if nothing happend. with the GSU interogating, the ECU replies.

i have attached an excel table that shows some of the replies and a bit of data processing i played with. it appears that the reply is a 6 byte stream, where the MSB (most significant BIT) of each byte is either 0 or 1, not sure about the rules here and why its changing.

does this make sense to anyone?
any reverse engineering experts can share some ideas?
so far havent been able to get the ECU to answer to Arduino.

thanks for your help.

JC init.PNG
JC init.PNG1814×556 36.7 KB

2

there you go again.... :slight_smile:

is this the SAME problem as this post or yours?

https://forum.arduino.cc/index.php?topic=618105.0

just for clarity, is

'ECU' is the jet turbine and 'GSU' the main controller??

3

im still working in the same problem. but now different HW already implemented and have made significant progress in the decoding of the data stream from both sides, that is now clear.

ECU is the Engine Control Unit, connected to the jet turbine sensors.
GSU is the Ground Support Unit which is a hand data terminal displaying all the turbine data on a display.

i would like to emulate the GSU and read the incoming data streams feom the ECU.

thanks for your help. it is very appreciated.

4

OK.... Donno what you decoded so far so will need some more info....

From your post #1, it appears that ECU is the Master device here.

So next and first question is:
when ECU and GSU are connected, have you been able to identify the GSU reply '0x0A 0x00 0x00 0x00 0x00 0x0A' ? (how else will the ECU know that GSU is there otherwise?)

If yes, what was it?

If you did identify the GSU reply, would I be correct to guess that you tried something like that with your arduino?

[in pseudo code]
'while' receiving request for ECU, store byte;

if ECU request == 0x0A 0x00 0x00 0x00 0x00 0x0A

Send GSU reply;

Expected to then recieve subsequent reply from ECU...

are those the steps you did?

5

I hope the following picture demonstrates where i am right now, these are the 2 setups.
top setup - ECU with GSU.
bottom setup- ECU with Arduino / LIN transceiver.

the GSU 6 byte response changes every time, and is recorder in the table in my first post, i tried emulating several of these with no success in getting the ECU to respond.

JC init2.PNG
JC init2.PNG1521×162 6.84 KB

6

i3dm:
I hope the following picture demonstrates where i am right now, these are the 2 setups.
top setup - ECU with GSU.
bottom setup- ECU with Arduino / LIN transceiver.

the GSU 6 byte response changes every time, and is recorder in the table in my first post, i tried emulating several of these with no success in getting the ECU to respond.

Ok, thankyou, it's more clear now.

Sounds like there might be more going on here... maybe some kind of handshake...

is there anything else connected between the GSU and ECU?

would you also be able to share a scope trace of the communication specifically when the initial communication starts between the ECU and GSU?

7

there is nothing else connected.

i will look into getting a scope trace. might be a few days before i can do that.

any thoughts on what else could be going on and not picked up by the logic analyser?

8

i3dm:
there is nothing else connected.

i will look into getting a scope trace. might be a few days before i can do that.

any thoughts on what else could be going on and not picked up by the logic analyser?

timing... maybe there is a window where ECU expect a reply.

9

GSU responds after 0.2ms, which is where i timed my ardu to reply as well

10

may or may not matter but what about the timing between the data bytes transmitted?

11

i tried to emulate that as close as i could with some small delays - still no joy.
what i dont understand is the different GSU replies.

it may or may not he related to the fact that the ECU is not responding, i tried to emulatesome of those too. no joy.

12

problem solved.
my Saleae logic wasnt reading the bytes correctly because of first bit timing. thats why i always had the first bit toggling.
fixed that and all is well.

thanks for the help :slight_smile:

13

i3dm:
problem solved.
my Saleae logic wasnt reading the bytes correctly because of first bit timing. thats why i always had the first bit toggling.
fixed that and all is well.

thanks for the help :slight_smile:

just out of interest (if every you gonna reply on this thread again!) what was there any issue with the arduino code to emulate the GSU?

14

i was emulating the wrong bytes since the logic decoded them wrong.