Does anyone know or have access to any of the CAN bus data from the 2IS?

 

Everyone does... https://www.clublexus.com/forums/is-...-pid-pack.html

 

Thank you, but these are PID's that you are referring to. I was after any CAN frame identifiers (CAN ID) that anyone may have which is different from a parameter identifier (PID). The PID (Parameter Identifiers) are common. It is a legal requirement to ensure all ECU's can be asked to respond to common requests so that you can run diagnostics without using manufacturers proprietary hardware and software.

I've since sniffed out quite a lot of the CAN ID's that I need but still sniffing using my CAN BUS sniffing tool. It's a rather slow and time-consuming process reverse engineering these codes, but almost there.

 

What are you trying to unlock? I may have an interest in this as I would like the ID of a module that controls specific element for the Fog lights. In the US they appear to use the BCM take the lighting switch and do some AND/OR logic which then enables a branch of the MPX lighting relay to turn on the fog light but only if the headlights are on. If one could find what they used as identifiers, maybe they could isolate specific elements.

Look at post #4 here: MPX, LAN, BEAN, AVL
https://www.clublexus.com/forums/is-...e-on-help.html

 

Sorry about the late reply. I am reverse engineering the CAN BUS codes related to information that is displayed on the instrument cluster (e.g. engine temp, speed, rpm, range, gears etc). I am in the process of fitting the 3IS F Sport LFA Style cluster in my 2IS. The 3IS cluster gets data directly from the CAN BUS, whereas the 2IS cluster gets data from the BEAN. The only CAN data that matches both cars is the speed parameter and even that is missing the sequential counter to tick the mileage over. I've got most of the required CAN ID and message parameters reverse engineered from the 2IS including the lights, fogs etc.

Regarding what you are trying to do with your fog: the lighting messages on the CAN BUS for the 2IS seem to be purely information purposes. I tried to see if transmitting the lighting message will turn on the lights but it doesn't and it seems that the actual lights are controlled by the BEAN and then a CAN message is sent relating to it's status. Other messages like engine temperature, cruising range etc I was able to transmit to the CAN BUS and get it to display on the cluster.

So the way to control the lighting via the BUS would be to interface and talk to the BEAN network itself. I haven't looked into the BEAN network as for my project the CAN BUS has all the data I need. I am only going to need it to Listen Only and then translate the filtered messages to a new message for the new cluster which will be on it's own virtual CAN BUS.

Even if you got interfaced with the BEAN and got the lights controlled by the messages, my assumption would be that the fog still may not turn on without the status of the light parameter being on. Because on the CAN BUS the fog status is one value which is automatically linked to lights being on.

 

Good job! What hardware are you using to scan the bus and how are you getting the checksums out of the decoded messages while sampling? At my old job I had access to a very high end oscilloscope which code decode hundreds of protocols. I wish I had it now.

So, even if you are read only, there are some interactions for changing what is displayed. Are you applying this 3IS data independent of the 2IS architecture? This sounds like serious RE going on here!

So in the finished state, it sounds like you may be adding a processing computer. Perhaps an Arduino unit or two?

Good luck!

 

As previous poster mentioned I would like to know what you are using too.

 

I'm using a standalone CAN Bus logger which is on a prototyping board with a LCD and buttons that logs data to micro-SD card. It's a small little credit card size board that gives me the flexibilty of just going in to a car, setting to listen mode and pressing record and then it records the entire CAN Bus traffic which I can then play back using the same tool. I used this to log the data from a 4GS and a CT200h then used excel and filtered all the unique CAN ID's and played them back to the cluster on the bench to find the relevant messages that I need for the 3IS cluster. Then played around with all the hex values to decipher the values needed. The 3IS cluster has a built-in 120ohm resistor so all i'm doing is putting another 120ohm resistor before the CAN transceiver to create a adhoc CAN Bus which just has the 3IS cluster on it.

Toyota checksum calculation is straight forward. It's basically the CAN ID for example 0x1C4 (01C4 - this is the CAN ID for rpm) split the CAN ID into two parts ID1 ID2, then data length value, so for example 08, and because the data length is 8, it means there will be 7 values before the 8th byte. The 8th byte is the checksum. So you would basically SUM up ID1 + ID2 + Data Length + Byte1++to+++Byte7 = Checksum (But only take the last two characters of the answer as a checksum).

The checksum is needed for ECUs to accept messages. Messages that don't have a correct checksum will be completely ignored by the ECU on the bus for which the message is intended. However, from the testing I have done it seems the cluster does not care about the checksum as the cluster is only displaying the information. If that same message was sent on the bus without the correct checksum then the relevant ECU will not process the message. Since I am only using the messages to transmit to the 3IS cluster for display purposes I don't think I will bother adding extra lines of code to calculate the checksum because it works without it. i've tested this with the most of the packets including speed. I am able to manipulate speed and get the mileage to tick over and trip counters to all work with a incorrect checksum.

That's what I thought at first. At first I thought when you press the display button on the steering wheel and it cycles through Range, Outside Temp etc, this is request message being sent to give back that information. However, it's not the case. All the messages needed for the cluster are on the bus that I have been able to decipher to relay back as a new message on the 3IS cluster.

Right now it's all bench testing. Reverse engineering is very time consuming as you can imagine. I have the 3IS cluster working almost 100%. Just got the final few codes to get working. I also have a live recording of the CAN traffic from my 2IS which I then playback on the bench emulating the 2IS (this way I dont need to keep going to the car to see if something translates correctly to the 3IS cluster). The final state will be an Arduino Due which has a dual can bus CAN0 and CAN1. CAN0 will be connected directly to the 2IS with transient protection and will be set to ListenOnly mode. This listen only mode will prevent any errors being transmitted back to the 2IS live bus. I don't really want to risk any rogue data being sent to the live bus. I will then filter and listen for only the message ID's that I am looking for and then translate it and transmit that to CAN1 which is a independent CAN Bus just containing the 3IS cluster.

Just incase of any errors, I do not want to risk transmitting data back to the live bus which can be catastrophic, this way I have my 3IS cluster on a virtual CAN bus. The only thing I can think of that may be a problem is that the cluster ticks and logs the mileage which works perfectly fine in my setup and when i am ready to install it, I will virtually tick the mileage to the correct mileage of my car. However, the cluster does send out a packet back to the bus telling the car what the mileage is at. Other ECU's then also have access to what mileage the cluster is at. From what i've seen this isn't really used anywhere else except for example in the navigation unit you can log maintanance value to say remind me of oil change in certain miles, so i'm not sure if the mileage will increase in that navigation unit. If this is the case and I really need to send the mileage, then what I might do is on start-up not set to read-only transmit the mileage packet and then set to listen only.

Hope all that makes sense. It's a lot of work and i've been busy with it in my spare time Soon I will be posting some videos. I will have a full bench simulation video and walkthrough and a final video once it is in the car installed.

 

Brilliant!
So the data is always being output on the bus repeatedly and you are just listening and plucking what you need!
Never hacked the CAN but nice to know it can be done this way and the arduino has a dual available.

PS- I've used Arduino Uno's as hardware to read serial data(sync or async) or states of multiple inputs and then output data serially to custom
programs I wrote in Visual Studio to interpret the data and it works well too but the serial on Visual Studio is slow. But an arduino with CAN can also
be used with Visual Studio too maybe for debugging if it has a serial output.

Thank You for sharing.

 

Yes there are a lot of packets floating around on the bus. The relevant ECU's take the information that is targetted to them. Just to give you an idea of how much data travels on the bus. I if I turn on my logger to record mode as soon as I start the car and put car in drive and stop recording, within that 1minute there are 15,042 packets logged on the log file. Ofcourse these are not 15,000 unique messages as the same message ID will have thousands of repeats etc but you get the idea

 

The uno/mega with the MCP2515 requires about 1.6 milliseconds to read each message. The problem is that with a 500 kbps bus the messages can arrive at intervals of less than a millisecond. This means the Uno/Mega may end up being too slow for my application. The Due however is perfect as it's kind of overpowered for my project and has a modern 32bit ARM processor.

PS: Messing with the CAN Bus can be extremely dangerous and if one wishes to try, please read and do a lot of homework before hand.

 

Yes, this very comprehensible. A very good narrative!
I don't have time for a proper response but amazing work! I am shocked that it finds checksum irrelevant. I hope that holds true for the duration!

Unfortunately I really can't add much value here as I've, only read stuff and tinkered with I2C protocols on proprietary hardware, well and some motorcycle ECUs.

I don't need a long explanation but do you see a method to their means regarding addressing? Does it correlate directly to the PID's or must it be be further decoded?

Share as you wish but your day job is ????

 

Yes I found that surprising too. I read up on it and it seems that not all packets contain checksums (majority do) So the checksum is in place for security reasons and it seems it doesn't effect the cluster because all the cluster is doing is displaying the information sent to it. For example, if I send a gear change packet with the incorrect checksum, the cluster shows the gear selection but the actual ECU doesnt process the gear change.

haven't analysed it enough to figure out their method. i'll post if I discover anything interesting. That being said, just comparing the CAN frame ID's between the 2IS and the 3IS, they seem to be completely different. The 3IS seems to share the same addressing as the CT200h, 4GS and the cars that launched around the CT200 era and onwards (not 100% but lots of codes are common). This is how I was able to find the ID's I needed because I have access to a CT200 and a 4GS which I was able to record data from. The 2IS seems to share codes more common with the older Toyota's and Lexus cars like the 2nd Gen Toyota Yaris, 2nd Gen Prius, 1IS

Computer programmer

 

I typed other stuff and deleted it regarding critical inputs, closed loop control, and ya, for information only. So it makes sense, why burden the decoder / processing engine for *display purposes* only.

And ya, playing on the bus can instantly throw the whole car into limp mode, and/or shut down the whole system so readers be warned....

This is good stuff. Is the the cluster a physical bolt in? This is going to be a game changer from the drivers perspective looking forward!

O/T
I don't even know how to classify my job. It has a bit of everything in it. Programming, mechanical design, electrical design, lasers and medical products that go in our bodies when our systems fail. We micromachine with lasers... both polymers and precious metals.

Keep us posted! I'm wanting to see the finished result!

 

I've just had a a brief look and it seems like it would fit, but not sure if i'm going to need to fabricate a custom bezel to cover it or maybe use the 3IS bezel on it. Will be testing that out soon. The cluster has just been on the bench for a while with all wires hooked up and i've been lazy to disconnect it all to do a test fit

That sounds very interesting

Will do