[moshjosh]

I have two help requests related to Nissan's CAN Bus protocol:

1) Can anyone point me in the direction of where I would find a list of CAN Bus codes sent by the various ECUs for a 2014 Nissan JUKE TEKNA CVT, Petrol 5 DOOR HATCHBACK?

I would like to plug in a self-built Rasberry Pi or Arduino unit with a CAN BUS hat and store the data on an SD card. Then analyze the data in Excel. I can't use a pre-built solution as it is for a project. I have watched a few videos explaining CAN Bus and several people mention needing the codes which relate to the specific make and model of my car.

I can't find a list of Juke CAN Bus codes anywhere.

2) I DON'T want to send any data packets or messages to the CAN Bus. I don't want to affect the car's operation in any way, I only want to read the data, safely. How can I ensure my solution only reads data and doesn't send data to the CAN Bus?

Thanks in advance.

 

[squirtbrnr]

To answer your question, I’m not sure where to find Nissan specific commands. In theory what you want to do is 100% doable. I’ve never done it on CANBUS, but I have done it with basic serial communications for other electronics. Start with an oscilloscope that has multiple channels and hook one lead to CANBUS high, and another to CANBUS low. You will see the CANBUS is very chatty with nearly continuous signals between modules. Then you can get a device called a “bus pirate” which can be setup in listen mode and will record data. CANBUS is a vehicle module communication standard not specific to any manufacturer. However, there may be a security header to the data stream which every module recognizes and then allows communication. This part is what may be manufacturer or vehicle specific. What you’re looking for is not necessarily the codes, rather you need to know the data structure of a single CANBUS command. It would be something like <null><header><from_address><to_address><command><data><checksum>. What you may need to do is once you get the listening device connected and seeing the CANBUS (remember the CANBUS has a high and a low signal which are mirror images of each other with reference to 0 volts) trigger a known action like a door look request and then decipher the command. Record a few of them and a few other commands and you’ll start to see a pattern emerge where some parts of the signal are the same for all commands which would be a header and maybe a module address, other parts the same for the same kind of request which would be the command, etc.