Vanny wrote:

There isn't a standard transceiver chip, and most modules have the transceiver in the MCU.

Super interesting thread, I have done a fair bit of this on my XF, and not so much on my partners fl2.

I have a complete mess of a fork of the repo for the fl2, however only pulling reverse and lights

Lights is ID 384(dec) byte 1, bit 4

https://github.com/rhysmorgan134/JaguarXf_...eed/384.js

reverse is ID 126(dec) byte 1, bit 2

https://github.com/rhysmorgan134/JaguarXf_...eed/126.js

feel free to have a poke around the new jaguar repo, may be some similarities there

https://github.com/rhysmorgan134/jaguar-xf-canbus-app

I finally have power supply I can hook up to the cars, so once carplay project is finished I will be looking to get back into the xf/fl2, but thanks for your information so far, will save a few hours of looking at cansniffer!


Also have a slack channel going, mainly around the jag, but also some SDD bits and general can bus stuff if anyone wants to join!

https://join.slack.com/t/canbusjagdeve-hl0...cL2p7I77RA

Some great posts above, lots of new information and I am learning all the time. Thank you for everyone’s input.

I have finally managed to add a display in a way that does not cause CAN Frames to be dropped to my benchy test circuit. Full transparency, I occasionally detect a buffered frame which is annoying as the CAN Driver / Transceiver I am using has a LIFO (Last In First Out) buffer flow which means when this happens the data is not presented in the correct order which would be a nightmare for frames like Media info which is a Serial Bus over a CAN Frame concept. That stated, the buffered frame is normally read within 4 - 5 frames, media frames are significantly more spaced than that.

The idea here is that it should allow me to display data in real time from the Car.

In the attached picture the CAN Transmitters powered by the Yellow Batteries are simply sending a fixed ID with data that is counting. The receiver is checking to ensure there are no missing numbers. The Leonardo device on the left is sending data on the HS CAN as fast as it can, which is slightly faster than data is generally presented on the FL2 HS CAN. The one on the right is being driven by a NANO which is very slow providing data a fair bit slower than presented on the FL2 MS CAN (I need to upgrade this to be 100% sure there will be no dropped frames on this bus in live applications).

rhys_m wrote:

Lights is ID 384(dec) byte 1, bit 4

reverse is ID 126(dec) byte 1, bit 2

+1 for that GitHub idea.

I have a few MY2013 that I am working on.

It would be great to capture all in one place and my Spreadsheet has become messy with lots of links and too many out of date notes so a proper export would be better as a template

I have a GitHub account so it could be private with contributors if that what people wanted, or just leave it public.

Yeah this is a 57 fl2 so you are most likely correct. It's interesting that in the jag it is 0x28, and the freelander 2 is 0x7e, which are both high priority, but the newer model seems to have it at a much higher ID. Do the newer models come with a Gear selector model?

Also think the github repo is a great idea, I am more than happy to dump the jag stuff in there too, I have got really far with that, and I guess will have some relatables.

While I wait for my larger screens to arrive for testing I was thinking about the overall design for an LCD instrument cluster and that all the IDs from different cars are different, i.e. even for something simple like MPH.

I was thinking it may be better to have two processing boards, (1) to accept the CAN ID's and convert them to a standard and (2) to accept the standard IDs and drive the displays. Thus (1) would pass MPH to (2) simply as ID 1 = 50. Or potentially even expand to ID 1 = Draw Gauage Type 1, on screen z at x,y with size a,b, using data c as MPH and d as RPM. It would open up lots of possibilities doing it this way and would only add about £10 to the design.

Theoretically then, (1) could just use a different config.h file for a different car. This also solves an issue where to drive larger screens fast enough I needed to swap from an SPI connection to a parallel connection for communication speed and this method uses lots more pins. I am currently looking at one 7" screen in landscape and two 3" screens in portrait at either side with a 3D printed mounting bezel so it could be adjusted for different cars.

However, and I am sure the experts reading this are already thinking it . I have thought about one thing that could stop me in my tracks. I suspect removing the original instrument cluster to connect a new one will make the car complain significantly. For that I may need help from the experts. I am also not sure about the legality of replacing the instrument cluster, maybe it needs some official calibration or something, maybe someone has some input...

Once I have overcome the above and have a working example I'll make the github project public, for now it would create more questions / noise while I figure out the best way to do what I am attempting.
Keep an eye on https://github.com/bionicbone

Even if this is totally not possible to replace the instrument cluster I think I will still continue. Maybe is makes a good "additional" screen project for people to build that would be relatively cheap.

A few of the regulations that you can Google.

https://www.legislation.gov.uk/uksi/2001/25/schedule/3/made

At a quick glance, it seems that if you limit your vehicle to below 25mph, you can do anything.

Seriously though - I would expect that you would come under the same tests that are needed to put any modified car back on the road. FL2 XS SD4 Auto 2010 2012-2017 (21k - 91k miles) (MY2011)
FL2 Metropolis SD4 Auto 2014 2017- (16k - 85k+ miles) (MY2015)
Metro in its 12th Year of (Extended) LR Warranty / Full LR Service History
(Expensive, but Trouble/Worry free - hopefully?)

bionicbone wrote:

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

Sorry for the late response, I've just come back to this as I am currently doing a re-write of my CAN BUS data collection interface (adding a screen and SD Card so I dont have to keep taking my Laptop to the car).

What I have learned is that from VIN: >382339 everything changed (FL2 / LR2) is more like the Evoque then previous models when it comes to the modules attached, and thus CAN ID / messages.

My latest video may be of help to people lerking here...

FL2 Specific Parts:
01:00 - 03:00 - Oscilloscope on FL2 CAN Bus Review
13:08 - 15:20 - High Speed CAN Bus Technical Frame Frequency and Bus Capacity Data
15:20 - 15:35 - Medium Speed CAN Bus Technical Frame Frequency and Bus Capacity Data
17:35 - End - Connection test on FL2, SD Card and SavvyCAN example

?si=mZtT8k9S8mmSkIJl

Does anyone have a dbc file for the 3.2l auto?

Thanks.

bionicbone wrote:

Click image to enlarge

Hi Alex,

Maybe you dont look here anymore?

Its a nice job you did here.

I was wondering if you have ever seen any info on the later MY2014 models ?

LR must have changed most of the IDs on the later models, the only one from your list in this thread is the VIN which is still on 0x405.

I really want to validate fuel temperature, I found so many IDs that contain data looking like temperatures, but with so many temperature sensors attached to the HS bus its like a needle in a haystack.

Most of all I want DPF data, but so far not even a sniff on that.

I built and programmed my own CAN scanner based on an ESP32 as I found the slower processors missed so much data. It also allows me to live scan using CanDrive or Log both HS and MS at the same time for either analyis in my own program above or in Excel or SavvyCAN, lots of spare capacity to read more than teh FL2 throws at it. It also allows me to drop a dummy 999 ID into the data one pressing a button before I do something so I know where to look.

Any help or point in the right direction would be appreciated.

This is what I've found so far, I'll make a list once I have found all I can. Many like KMH, RPM and Mileage are presented on several IDs either the same way or using a different formula.

Click image to enlarge

Hi bionicbone,
Its a nice job you did.

I played with CAN ID 0x797, which is known as Steering Angle Sensor
I got some data like this:

0x076 03 15 05 B8 06 F9 99 A2
0x076 04 5A 05 58 06 94 99 B2
0x076 05 AB 04 80 06 28 99 BD
0x076 06 12 03 A8 05 A7 99 C8
0x076 07 84 03 00 05 1E 99 CF
0x076 08 05 02 10 04 87 99 D6
0x076 09 81 01 B0 03 F7 99 DB
0x076 0A 07 01 08 03 5F 99 DD
0x076 0B 88 01 08 02 CF 99 DD
0x076 0C 0D 00 C0 02 38 99 DF
0x076 0D 7F 00 C0 01 B7 99 DF
0x076 0E E3 00 C0 01 43 99 DF

Do you know what it means?