Subbed for interest!

Freelander 2, MY2014, TD4, Manual, SALFA2CC8FH432XXX

In case it is helpful to others...

My car has two main CAN Bus, commonly known as High Speed (HS) and Medium Speed (MS), I believe this is the same on all FL2 models. The MS is running at 125kb/s while the HS is running at 500kb/s.

A main difference between older FL2's (probably <2013) and newer FL2's which is relevant for what I am trying to achieve is that on older models only the MS bus data is presented to the instrument cluster whereas on newer model both MS and HS are presenting information according to the wiring diagrams available.

I have not found information detailed enough for older models relating to the number of ID's transmitted so I have no comparison at this stage in terms of data quantity. I can say, the data I have found on the net (mainly in this thread) leads me to believe the data is totally different and not cross compatible.

For newer models I have found 110 different ID's, however it should be noted that some ID's are spilt into many sub ID's which are controlled by one data position being a particular value. This makes these ID's look very busy and constantly changing when in fact most of the data is constant within its sub ID set and I suspect this is the cars configuration file constantly transmitting in case of an unexpected module reset. These ID's are MS 0x400, 0x401, 0x405 all with Sub ID controlled by D0, and 0x4EC with sub ID controlled by D1. Then on HS 0x400, 0x405, 0x407 all with Sub ID controlled by D0. Including Sub ID's this gives a total data ID count of 267 frames. Each Frame ID has its own frequency for transmission, however due to standard CAN Bus arbitration (ID Priority) this frequency is slightly variable when presenting on the CAN Bus.

Each data frame consists of 8 data bytes with the exception of ID 0x0E0 (indicators) which only has one byte. Generally, the data is simplistic in the sense that either each byte is a value on its own or is paired in these very common groups D0D1, D2D3, D4D5, D6D7, with the common expression D0*256+D1 giving the result in some cases. Obviously larger numbers may require the use of more bytes, for example, D0 * 256 ^ 3 + D1 * 256 ^2 + D2 * 256 + D3. There are some exceptions like mileage which LR have tried to hide at least a little. Since in my opinion even though LR has tried to capture foul play by generating PIDs such as C2002-62, Odometer tampered, Algorithm based failure - signal compare failure it would still be possible to use loop back data manipulation techniques to display incorrect mileages which could fool an unsuspecting sole and for that reason I will not detail anything about mileage data.

MS CAN Bus ID 0x4D4 contains the car set Date and Time.
This can be useful for synchronising video, photo and note times to the log.
Byte0: 0x00, Byte1: 0x00, Byte2: Year, Byte3: Month, Byte4: Day, Byte5: Hour, Byte6: Minute, Byte7: Second

MS CAN Bus ID 0x490 contains KMH
This can be useful to determine if signals only change when the car in not moving, or if speed is effecting the values.
NOTE: car speed is presented on several IDs using various calculations, for Example, HS_0x150, HS_0x155, HS_0x2B5.
For ID 0x490 use the value of D5D6 /100 and * 0.621371 for MPH

MS CAN Bus ID 0x0B8 contains RPM & Hand Brake Status
This can be useful to determine if RPM influences other signals.
NOTE: engine RPM is presented on several ID's using various calculations, for Example, HS_0x150, HS_0x155, HS_0x2B5.
For RPM on ID 0x0B8 use D4D5 as an exact value.
For Hand Brake on ID 0x0B8 use D6 as value 0x08 = Off and value 0x09 = On

More to come later as data is validated.

MS CAN Bus ID 0x4B5 contains the Visual Multimedia Data
This is running a little like a serial bus in the sense that each time a frame is transmitted it contains the next 8 bytes of data.

Visual data is easy to understand, each character is represented by its ASCII value, to make up the entire string of data it may, and often is, be transmitted over several frames.
The attached shows only 0x4B5 frames for simplicity, however in reality there will be many other Frame ID's transmitted between each 0x4B5 frame. Careful review should allow you to see the flow as I swap from USB1 to FM to DAB and back to USB.

It is worth noting that frames are only transmitted when "changes" occur. Therefore any design using such data must capture the very first frames transmitted, i.e. when the ignition is switched on.

The use of value 0x00 is key, this forms both start and termination of data as well as an indicator that a special status has occurred.
For it to be the start of the next data then the 0x00 value will be followed by an "a", "b", or "c" where these represent Media Input (i.e. USB, FM, DAB), Track Title / Station Name, and Track Number or Station Frequency respectively.
For it to be a status indicator then it will be followed by "," or "+" for "No Reception" or "Searching..." respectively.
0x00 not followed by any of the above appears to be the end of data for the field currently being transmitted.

Click image to enlarge

Click image to enlarge

Below is my best attempt at describing the different architectures.

https://bxproject.co.uk/blog/lr-electrical-architecture/

The newer FL2 architecture is loosely based on T5, which is loosely related to EUCD so there should be some similarity, but really you need to be looking at Discovery3/4 and Evoque for insights.

There are a few pages on CANBus mining, specifically based on the FL2 here;

https://bxproject.co.uk/blog/category/electronics/canbus/

This may not be too helpful to you as I think you already know more than is described here.


One thing you might want to consider is Quality Bits and Update Bits. These can and do change as you create an input to the system. So, if you press a button, you'll see the value of the button change, but you'll also see the update bit change. This is something often not realised when CAN sniffing and people come to the wrong conclusions.

The Car Configuration File is broadcast of 0x400 for Block one (EUCD) and 0x401 for Block two (T5).

The first byte is the line number in the CCF, so 0x401 01, 02 and 03 contain the VIN (01 starts with the vehicle type, L359, the brand (Land Rover) and the model year (14?). Playing with these as they go into the FCDIM (MMI/Display screen) gets it to load different software ie change to Range Rover or Jaguar.

I haven't played with Land Rover data for a while, but contact me through the website if you want to chat CANBus.

Last edited by Vanny on 14th Apr 2022 8:23 am. Edited 1 time in total

Hi Vanny, thanks for the reply.
I am busy working through your very good articals.
In the meatime, thanks for your input, I'm sure we'll be talking CANbus very soon.

I noticed something new which has changed my thoughts that all the data I am trying to capture is always on one of the two buses.

I have been using the Autel AP200 live data and I had previously check to see if the device was requesting data via the standard OBD2 documented request and response ID's (0x7DF & 0x7E8 respectively) which it was not.

However, as part of my analysis tools I had written a piece of code that compares one Can Bus data log against another to highlight chages that should potentially be investigated. Its not the place to detail everything here about how the compare works, but understand if a number changes by + 1 then both numbers will be shown, for more active values we see a "*", a whole red line is a New ID and thus nothing to compare against.

This has highligthed that when the Autel AP200 is plugged in and (I assume at this stage) I am viewing live data (which maybe why I have not spotted it before) I have two new ID's presented on the HS bus, these are 0x726 and 0x72E. I am wondering if one of these is a request and the other is a response, but if they are they are not documented anywhere on the net. However, if they are a request and response there is not a lot of data for the infomation I was reading on the screen. More analysis is required here.

Click image to enlarge

Click image to enlarge

First off, apologies, the VIN is in Blk2 and has the address 0x401 (not 400)

What you are seeing with the AUTEL is DIAG messages. As a general rule, all diagnostic send and response messages are on an address starting 0x700. So the HVAC is on diagnostic address 0x733 on a Range Rover.

DIAGnostic message is a tester sending a command to an ECU requesting additional data which is not normally broad cast. This is how DTC codes are usually read.

Thank you @Vanny

So in this case it was the BCM module, thus 0x7DF & 0x7E8 are for BCM diagnostics.
The bit I do not understand, the BCM Live Data in Autel AP200 shows no less than 323 bits of data, thats not indicated in the above in terms of the amount of different data being presented. Maybe this is because the Autel can only display so much at a time and only requests the data on the screen. I'll check that.

This adds a new bit of excitement (I know very sad), it means that using this method I may get to all sorts of data like the requested torque for the front & rear wheels in different driving conditions for the dash display.

I make it 224 bits of data. 28 bytes. The first byte in each response is the packet number so '21' is 'Response''Line1', then '22' is 'Response''Line2' and so on. This is not a lot of data, and it really depends on what the Autel is asking.

And yes, you're right, for DIAG data, there is a tester address (726) and a response address (72E) which can make reverse engineering the discussion that much harder.

In the first 726 line, you can see '22 41 4C'. There is a generic protocol for this diagnostic message type. 22 is a request for information. The request is for the information in block 41 4C in the BCM(?) diagnostic memory. If this 414C started Fx xx, then it would be a part identifier. F1 88 is the Assembly identifier. There are also some routine commands that are generic so 11 01 is a hard reset, 10 82 is a session change to programming and so on. I don't know them all, there doesn't seem to be a list, but many if not all manufacturers use them. I think they are related to UDS commands if you want to look that up.

Oh, 0x7E8 is the ECM (Engine Control Module) not BCM, assuming you are looking at the HS CAN?

The AUTEL is a touch dumb, and only as good as whatever reverse engineering has been done. It might ask for a large block only to get a small bit of information.

Vanny wrote:

I make it 224 bits of data. 28 bytes. The first byte in each response is the packet number so '21' is 'Response''Line1', then '22' is 'Response''Line2' and so on. This is not a lot of data, and it really depends on what the Autel is asking.

Vanny wrote:

In the first 726 line, you can see '22 41 4C'. There is a generic protocol for this diagnostic message type. 22 is a request for information. The request is for the information in block 41 4C in the BCM(?) diagnostic memory. If this 414C started Fx xx, then it would be a part identifier. F1 88 is the Assembly identifier. There are also some routine commands that are generic so 11 01 is a hard reset, 10 82 is a session change to programming and so on. I don't know them all, there doesn't seem to be a list, but many if not all manufacturers use them. I think they are related to UDS commands if you want to look that up.

@Vanny,
Just wondering if you ever pulled any of your car modules apart to see what CAN Tranceiver chip JLR are using ?
I assume they are an optically decoupled type ?

Some time ago, I've tried to explain, in an episodic manner, some things on the thread below...
Read all my posts in that thread to see how to read and erase errors or how to get freeze frame data for errors.
https://www.disco3.co.uk/forum/build-fault...02801.html

0x7DF is a "broadcast" CAN ID address.
Meaning something sent on that ID will reach ALL modules on that CAN network.
Useful for "resetting the car" or clearing on one go all errors on all modules on that bus.
Also used for "tester present" (TP) keepalive messages and switching between diagnostic session types.

bionicbone wrote:

@Vanny,
Just wondering if you ever pulled any of your car modules apart to see what CAN Tranceiver chip JLR are using ?
I assume they are an optically decoupled type ?

There isn't a standard transceiver chip, and most modules have the transceiver in the MCU. They are not always decoupled. Like everything in automotive, you have to think cost. I can't think of any modules that are optically decoupled, some are galvanically decoupled.

BCM

Click image to enlarge

FCDIM (0x745)

Click image to enlarge

IPC (0x720)

Click image to enlarge

TVM

Click image to enlarge

Yeah, I like to pull things apart

A few more photos inside the passenger fuse box. There are 3 layers of circuit boards. https://www.freel2.com/forum/topic34833.html Procrastination, mankind's greatest labour saving device!

Acoustic insulation ARB TPMS 3xARB air compressors After cooler Air tank On-board OCD pressure air/water cleaning Additional 50L fuel Carpet in doors ABE 2x1kg Waeco 28L modified fridge Battery 4x26ah Solar 120w Victron MPPT 100/20 DC-DC 18amps 175amp jumper plug Awning 6x255/60R18