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 - 76k+ miles) (MY2015)

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