Talking to Alex, our own "hacking" guru here on the forum, Im trying to do some fun with this:

Click image to enlarge

Click image to enlarge

Click image to enlarge

Wel.. my Interface is allmost complete, I just need to find a switch that will work. The wires are for MsCan and HsCan.

Mr.P

I just got to get me one of them.
Eh, what for I have absolutely no idea.........ignorance is bliss.

when does the "fun" part come in ?

Iain

Sorry to sound a bit of a tech biff, but what's this for?

Merry Christmas by the way 😀

parrafin23 wants to collect information from the car's CAN buses and show them on a big screen device.
Eventually, if possible, to use the device - maybe a big tablet - to send commands to some of the modules.

Something like this:

Click image to enlarge

Its allmost done, I just need the switch now.

Got all the electronics packed in nicely :

Click image to enlarge

Click image to enlarge

Click image to enlarge

Yes, I've logged the traffic on CAN buses, but I've used an USB based logging device.
This one: http://www.microchip.com/Developmenttools/...P2515DM-BM
So the software I've used is freely available from Microchip. You may take a look but it's quite different.
We can exchange impressions about IDs, values and their meaning after you make it work.

Im scratching this Idea.. goin for the Arduino UNO Rev3 with CAN Bus Shield v1.2

I know Rubot from disco3 forum is eager to join in on ths "project" and he has allready started it..

Anyone else has experience with whis, feel free to come forward and let us hear your thought and Ideas..

This is goin to be for the D3 and as Alex wrote on losts of posts about this stuff, it's easy to adapt to the Fl2.

Mr.P

anyone else whilst respecting the tech , thinks that the huge screen in teslas and some Volvos looks absolutely ridiculous?

it is the future without doubt, but why so ugly?

maybe have a screen saver of a normal dashboard picture, perhaps of a tapedeck with a wire hanging out of the slot as in early ipod days.
or a vibrating dash screen saver to remind me of mk1 diesel golf days. At work
At home

"I can't always believe facts I read on the web" - Charles Dickens

winner by default of the tractor vs caravan race

parrafin23 wrote:

I know Rubot from disco3 forum is eager to join in on ths "project" and he has allready started it..

I think we are after the same result here. I have started. I'm using an Arduino based hardware solution for the can-bus sniffing. Actually, its a Sparkfun Redboard which is an Arduino Uno clone. I buy a lot of components from www.sparkfun.com so I wanted to try their redboard. Anyway, in addition to using the redboard I am using their Can-Bus Shield https://www.sparkfun.com/products/13262.

To set everything up I followed sparkfun's tutorial here: https://learn.sparkfun.com/tutorials/can-bus-shield-hookup-guide with the exception of using the GPS, LCD, and code. There is a parts list in the tutorial. I wrote code using a different canbus library because I think there might be an issue with 29-bit IDs in sparkfun's code library. Although, i'm not 100% sure just yet since I am still struggling with understanding the IDs. I could use guidance here.

Everything considered the setup has been very easy. I've had what I think is some success capturing can-bus messages. Right now my arduino writes them to SD card on the shield instead of sending them over USB or wireless to my PC. I think both connections are much slower than the canbus and there is a potential for missing messages or receiving improperly formatted messages. When I've run the capture for a few minutes I remove the SD card and plug it in to my PC. Then open the file in excel for analysis:





I saw Alex's list of ECU IDs over here: http://disco3.co.uk/forum/topic102801.html. I expected I would find these in my log file. At least from the ECUs on the high speed bus (more on that later). However, what I found was that there are many many more IDs in the log file. Of the thousands of messages I recorded only three or four ECU IDs from the list were represented (note the ABS and FRONT LIGHTS in the SRC ECU column of my screenshot). I'm not too sure what to make of this. I don't think there are more ECUs than what Alex listed. There might be something wrong with my code (very likely) or some kind of encryption at work... Also, it might be that the message IDs don't necessarily correspond to ECUs but more likely each function of an ECU (ECUs might have several...?) has it's own ID.

So back to the hardware for a second. One of the most notable limitations of my hardware setup is that the canbus shield can only interface with one canbus at a time. Right now, based on the components I purchased using the list in Sparkfun's tutorial I can only connect to the high speed canbus. I have not attempted yet but I think it would not be too difficult to rewire a plug to interface with the medium speed canbus. So the future solution would need either multiple Arduino/canbus shield devices attached or a custom shield that can connect to more than one canbus at a time.

Currently, I am reviewing my code, which is very short, for errors and exploring other code libraries that might work better. I think Alex has had success looking at traffic from other applications for clues. I only have one other piece of diagnostic software and it doesn't interface with all ECUs. If I can spy on the traffic I might get a better understanding of what a proper message looks like.

Going forward, I think the key here is understanding the IDs as a whole. From my limited understanding I believe that the message "ID" contains both the source and destination IDs but also a Parameter Group Number. I think the Paramter Group Number is specific to the information we are looking for. I mean to say that PGN #### corresponds to pressure in the air reservoir or something like that. The information here http://tucrrc.utulsa.edu/DecodingDataDumpIDs.html is what is leading me down this path although it does not pertain specifically to Land Rover. Decoding the actual data should be fairly simple from there...

Comments, suggestions? Am I headed the wrong way? What can I share with everyone to help?

Congrats for what you've achieved!!
Don't worry about the IDs. The code can be pretty sure alright.
The IDs I've mentioned on the disco3 forum are the IDs that the corresponding ECUs are using for diagnostic purposes.
There is no limitation on which IDs a CAN node is using. For both writing and reading. With the condition that the ID to be unique on that CAN bus.
Imagine the car like a hotel. Each flat (level) is an ECU. And on each level (ECU) there are many rooms, each with its unique ID.
You can talk to and get a response back from any room (ID). The person on each room (ID) is handling a specific set of information.
Of course, some persons (IDs) are talking only when asked (diagnostic IDs) and some are more prone to gossip and are talking without being asked - what you've saw on the bus.
These information that are broadcasted continuously are the status information of the corresponding ECUs.
For example, the ABS module is continuously broadcasting the vehicle speed on a specific ID, for any ECU to use that speed information at its discretion. But will respond for diagnostic purposes, only when asked, at another ID.
And so on and so forth, ad nauseam....

LE:
The IDs were picked by the designers, in that manner, for convenience.
On 11 bit systems the response will be obtained by listening on an ID calculated by adding 8 to the asking ID.
On 29 bit systems the response will be obtained by listening on an ID calculated by swapping the bytes on the low word of the asking ID.
These for those that are responding only when asked.
As for the broadcast information, the IDs can be any. For sure the designers have had something in mind when they picked them, but this has little importance.
The IDs are IDs and as well as CAN specifications are concerned, you can use whatever ID see fit in your application (as the car manufacturer have done). Just remember that the lower the ID, the greater the priority and the chance for that message to be transmitted first.

So you do liggin to a SD car and view it on the computer when done.. how about adding a LCD so you can minitor whats goin on? I didnt order one, but after reading the SparkFun forums a bit I see now that its vise to get one.
Im far from a programer, I used Qbasic 25 years or so ago, but havent done any programing since.
Looking at any code wihtout adding //Enter your commends here // is not helping newbians to learn what that line does, So thats the only thing I remember form programing in Qbasic.. Allways use this to make it easy to navigate your coding, no matter if its long or short..

I bought the UNO R3 localy, but I had to order the CanShield on Ebay cause the seller doesnt stock it.

This is kida strange writing stuff about coding and programing that are goin to end up in a D3 in the Fl2 forums. I guess we all "coders" are "drawen" to where Alex "Roams"..

Mr.P

Yes, I'm sending it to SD card. When we sort out what messages contain the information we need then that would be the time to look at using something like an LCD. Right now, for sniffing, there are just too many messages occurring too quickly for the LCD to be useful.

parrafin23 wrote:

This is kida strange writing stuff about coding and programing that are goin to end up in a D3 in the Fl2 forums.