0

I have Mazda 5, 2014

recently I've got OBD2 logger which allows to retrieve large amount (several hundred) of PIDs, including standard ones (SAE) and specific PIDs provided by Mazda Enhanced Add-on; all this data goes over bluetooth to my phone and gets stored into csv file.

I want to troubleshoot some intermittent electrical issues and (being unsure what else could be affected) trying to log as many PIDs as my car would safely support; however so far I was unable to find any recommendations, how many PIDs should I try to retrieve at once. Would it overload my car's can-bus or obd2 controller if I try to get too many PIDs or retrieve those too often?

Would it make any difference if those PIDs are coming from different subsystems? ("Mazda/Body control module", "Mazda/Powertrain Control Module" etc)

Here is the screenshot with all available PIDs enter image description here

[update] Just in case anyone wants to know - here is the problem I was trying to solve by colelcting those PIDs:

Pretty much every time after heavy rain and wind the car might not start or engine would just lose power or stop completely while I am driving; later after day or two the car would just "get dry" and everything gets back to normal until the next rain.

Here are the error codes retrieved after the last such case:

 IC (Instrument Cluster)        U0401:68-08     Invalid Data Received From ECM/PCMA

PCM (Powertrain Control Module)  P0340:00-AC    Camshaft Position Sensor A Circuit (Bank 1 Or Single Sensor)

PCM (Powertrain Control Module) P061D:00-AC Internal Control Module Engine Air Mass Performance

TCM (Transmission Control Module) U0401:00-2C Invalid Data Received From ECM/PCMA

ABS (Anti-Lock Brake System) U0401:00-68  Invalid Data Received From ECM/PCMA

EPS (Electronic Power Steering) U2023-FF  Fault Received From External Node

Since engine was losing power or just dying after rain, I hoped to get some PIDs indicating, what exactly went wrong right before the engine would die. (there were some frozen frames, but I couldn't see anything wrong there and my mechanic either, so I am trying to collect more data for "normal" driving and "problematic" cases.

7
  • I think the answer is "one". Why, because you send out a request and you get a response. If you stack requests, it's still only responding one at a time, regardless of how many you've stacked. I'm not an expert, though. Dec 3, 2023 at 15:42
  • I guess technically you are correct; in my case "at the same time" meant "pile all those PID requests and keep asking for those PIDs over and over"
    – Steve V
    Dec 3, 2023 at 15:45
  • Just like any computer or computer network, you can over do it, that's for sure. Sort of like a DDOS, even though it's not "distributed". My suggestion is, pile it on until something fails. Dec 3, 2023 at 15:52
  • 2
    If your vehicle doesn't generate error codes to have some idea of whether electrical problems are associated with error codes, PIDs may not help if you aren't familiar with interpreting PIDs that may or may not point to electrical issues. Perhaps describing it here may generate replies related to your descriptions of electrical problems.
    – F Dryer
    Dec 3, 2023 at 15:57
  • @FDryer There were some DTCs, I have updated the text of the question. Since engine was losing power or just dying after rain, I hoped to get some PIDs indicating, what exactly went wrong right before the engine would die. (there were some frozen frames, but I couldn't see anything wrong there and my mechanic either, so I am trying to collect more data for "normal" driving and "problematic" cases.
    – Steve V
    Dec 3, 2023 at 16:14

1 Answer 1

2

I wouldn't worry. In most cases, your adapter is usually way slower than the CAN connection, so unless your OBD2-adapter has its own logic (which only a handful do), it's not possible to saturate the CAN bus with a serial ELM327(-based) adapter. But let's do some computations.

We'll start with the bus ­– lets assume it's 500Kbps (ELM327 protocol 6), with 250Kbps it's going to take double.

A single OBD2 PID as a CAN frame (with 8 data bytes and standard addressing) has a size of up to 125 bits. At 500kbps, one single bit needs about 2µs, so it will take 250µs for the request to be communicated on the bus ­– and another 250µs for the answer.

Now we have no idea how long an ECU takes to answer the request. They're not the fastest devices out there. For the sake of a simple computation, lets assume that it's a very quick one that takes only another 500µs to fulfill that request.

So we have 1ms per request/response, which ­– at this point of time ­– translates to a theoretical maximum of 1000 PIDs per second.

Assuming this is a Bluetooth 3.x adapter (BLE ones are usually even slower, due to the GATT overhead), it depends on the RFCOMM protocol, typically you will only get 450-500 Kbps. Unfortunately though, it pretty much depends on the internal UART bitrate of the ELM327, which often is more like 115200 bps.

Knowing that ELM327 communicates by sending ASCII characters, a request/response sequence for a typical PID like 010C (Current RPM) looks like that:

010C1\r7E804410C5700\r\r>

That's 22 characters, so 220 bits for the UART. 220 bits on an UART @ 115200bps take 1909µs, so almost 2 milliseconds. (Yes, there is a special ELM327 syntax for combining multiple PID requests, but let's ignore that now)

With 3 milliseconds for a request/response interaction in total, the theoretical maximum would be 333 PIDs per second.

The device that the adapter is connected to though (a computer, a smartphone, a microcontroller) also needs a bit of time to read the next PID from its list. We don't know how long this takes, but it's probably neglegible.

While 333 PIDs per second is sounding pretty good, it also depends on whether you are using broadcast addressing. If you do not know how many ECUs will answer to your request, the adapter has no chance but to wait. This wait typically introduces an additional 100-250ms per request, so we quickly come down to 5-10 PIDs per second.

That said, real-life values I've seen vary from 50 to 100 PIDs per second, the latter only with combinations of good software and high quality hardware adapters.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .