JasonRussell

Hello Slicky Rick. I was jumping into an old thread about collecting data from the Porsche CAN Bus network. I was interested in getting some of the accessory such as Sport Mode, RPM, and throttle position. Most of this information can be read from the OBDII diagnostic port using a connector and a compatible device that can request this information. As you can see, a couple of these guys have found a way to dig deeper and get even more information off of the computer data bus on these cars. That is what I am interested in doing as well.

JasonRussell

Hello Hatzenbach. Thank you for responding on this topic. I have requested data from the OBDII port by sending OBDII commands which request engine RPM and throttle position and as far as the general OBDII stuff goes, I get the response I am looking for from the addresses I see when I look up OBDII PID's on Wikipedia. The think I have found is that the OBDII port is silent unless a request for data is sent. You wont see any data on that diagnostic CAN Bus unless you ask for it and as you have found, The type of data available is somewhat limited.

I have also connected to the Chassis CAN Bus and it is quite a bit different. There is constantly data flowing on that network and you can "listen" to the data without requesting it. I have a feeling that this is what you are doing with the Sport Mode and Accessory data you observed. I have not taken the time to decipher any of that data yet but I thought I would confirm that this is what you are able to do to see this information. It would be nice if I could simply hop on this network and look for the information I am interested without having to send a request out each time to read it.

JasonRussell

That is very interesting. I found this series of videos on YouTube from a guy named Adam Varga who did something similar to what you describe with the ELM327 except he used an Arduino with a CAN shield. The video is at:


I have an arduino here set up with the sketch he provided along with the custom CAN Sniffer app that he wrote and I have been using this as a tool monitor CAN and send commands to see the data results. It has been working well but I have only sent and received OBDII data so far. At this point, I do not have any of the Hex commands for the Porsche specific addresses yet but I was hoping to see an example of one of those Porsche specific requests you mentioned. My car is a 2015 Porsche Boxster GTS with a Siemens ECU.

I have been considering using one of those ELM327 Bluetooth devices but I was wondering what the latency time is when observing rapidly changing data such as RPM. Are you able to see this information without much lag? Thank you for the feedback!

JasonRussell

I dont know if this helps you much but I purchased a OBDII breakout box off Amazon and plugged in my Arduino sniffer at the same time I connect a decent OBDII scan tool and went to the "Live Data" menu on the scan tool and turned on each live data point scan one at a time and watched the command the tool sent along with the response. It was an easy way to see what is available for my specific vehicle through the OBDII menu and see exactly what command is required to get that response. I just recently started poking around with Durametric to get some of the other stuff but have not got too far with that one yet.

The Hex format is a little tricky to decode but this page on Wikipedia has been a great resource for deciphering the responses from these OBDII requests:

https://en.wikipedia.org/wiki/OBD-II_PIDs

lordvonpineapple

Cool, I'll take a look. I used this video to get started:

I use a Y-splitter ODB cable to allow 2x ELM327 ODBII adapters to connect to the car. This way you can see what another tool / device is sending and receiving over ELM327.
I run an additional ELM327 ODBII adapter into the extra ODBII socket (either USB or Bluetooth) and use a Mac/PC to connect via a serial terminal and observe ELM327/CAN message flow via ATH1 and ATMA

Latency? I am still working on it. The ELM327 DataSheet (have you read it?) gives you various tips and tricks to minimise latency and maximise request/response rate. I do a lot of optimisation via smart scheduling at the application layer under various different scenarios - my app doesn't just round-robin poll all of the commands we are currently interested in, that would be waste of bandwidth. But currently individual commands take anywhere from 0.04s to 0.06s and that means at the app / UI layer I am getting 15 request/responses per second. I think I can probably get that up to 16 or 17. I'd also like to see whether any ODBII adapter hardware is faster than others. I test on commodity stuff - including free adapters and Ebay/Amazon $5 adapters.

lordvonpineapple

Looks like we are doing similar things. Yes, that page is usually open in my browser quite a lot :-) I can decode most of those messages successfully. My Porsche doesn't respond to all of them though :-(

slicky rick

heavy stuff brother !

Hatzenbach

Yes, that’s what I’m doing. I don’t know squat about how to get data from the OBDII bus by the way.
Yes, I am basically listening on the CAN bus and am waiting until a PID that interests me appears.
So I am basically “stalking” the CAN bus
i built myself an Arduino based CAN sniffer to see what’s going on on the bus.
and now comes the hard part: since Porsche doesn’t disclose what PID does what, you need to figure it out yourself
figuring out on/off PIDs is relatively easy, just keep pressing the button and see which PID changes
PIDs with multiple values (oil temp, RPM, etc) are a completely different ballgame and here I found a few on the interwebs
And it’s also important to remember that there are several CAN buses in our cars. And different CAN buses carry different information

JasonRussell

This is the OBDII command and response I get for engine RPM using Adam Varga's sniffer app. The cool thing I found about this app is that it will highlight any frame or fields within a frame that change. This comes in real handy when you are watching a flood of Can Bus traffic and trying to identify something tied to an event such as a window switch, etc on a busy network.

JasonRussell

Hey Hatzenbatch,

I think you may have managed to accomplish the more difficult task right off the bat! Catching that wild CAN Bus data and identifying what it does has been the most difficult thing for me and a lot of other people out there! If you have been able to jump around the different CAN networks on the car, the OBDII port should be pretty easy for you. In that other post I just made with the screen shot for RPM request and the response, you should be able to use that same command and format to get RPM through your OBDII port. If you have your Arduino set up to send as well as receive, you can plug that same data you see in my picture with the address of 7DF and get the same result. Once you accomplish that, you can replace the 02 you see in the D0 column in the picture with other Hex commands in this Wiki list to see other things like engine temp, speed, etc. I had to step away from the Can Bus sniffing for now but I plan to get back to it in a week or two and let you know what I found that is available through the OBDII. I dont know if you guys use Durametric interface tools but they also dig down pretty deep. I am able to go outside the standard OBDII parameters and get info such as refrigerant pressure and engine compartment temperature.

Hatzenbach

@JasonRussell I watched all of Adam Varga's videos and build an OBDII/CAN sniffer with an Arduino and also copied his amazing tool.
On my testbed everything works (I have a 2nd Arduino which generates CAN messages and sends them over a physical set of wires to my receiver Arduino): the Arduino reads data and they are displayed in the CANsniffer tool.
However when I connect it to the actual CAN ports in the OBDII in my car - nothing.
I feel that it doesn't request any data and just listens. I feel I'm missing something obvious here.
Any ideas?

lordvonpineapple

Hi Hatz,

I do all my comms over ELM327 to talk to ODB via a commodity ODB adapter. ELM327 is typically request/response. I use a software library to send the standard OBD PIDS and most of them work with my 997.2. Ive also worked out how to send some of the Porsche-proprietary messages via ELM to get things you cant get from std OBD (either Porsche doesn't respond to the standard command, or the thing you want isn't part of the ODB standard). Id love to help but it sounds like you might be doing it slightly different from a tech/hardware setup perspective?

Hatzenbach

Thank You. That actually was very helpful.
I came to two realizations
a) I now understand what I'm doing wrong - or better why my approach is wrong
b) but - even more important - I realized that what I was trying to achieve can't be done via OBDII, it can only be done by tapping into the actual CAN bus (reading Porsche specific PIDs that aren't available on OBDII)

JasonRussell

Hello Hatzenbach. Sorry for the delay in responding. Yes, I found the same issue when I first connected the Arduino CAN sniffer. What I found is that the Porsche Canbus Gateway blocks all the traffic from reaching the OBD2 port until you request it. It appears that the OBD2 port on other models of cars does allow Canbus traffic to be monitored but tapping into the dedicated Canbus networks like you and I have done is the only way to listen for data without a request on our cars. On the OBD2 port, something that you can do to easily see the commands of interest would be to connect and OBD2 Y adapter and have your Arduino listen as you use your Durametric tool or code scanner to view certain data fields. You can compile a list of Canbus commands to send to see different data using this method. This is how I was able to track down manifold temperature and pressure along with other items such as engine RPM, battery voltage, etc. I have found that is a little easier to track down data points this way but the drawback is that if you need high speed repetitive live data, you can pretty easily bog down the OBD2 port making it difficult to scan or use this port for anything else. I am using the OBD2 port to periodically request data that I do not need frequent updates then monitor Canbus networks for live data that I want to see high speed updates on. I hope this helps!

Hatzenbach

Thank You. This makes a lot of sense. And basically with your method I can use the Durametric to "hunt" for more PIDs - great idea!