Automatic shutdown

Johnny — Wed, 15 Aug 2018 06:33:19 -0000

Hi David,

Here is a quick and dirty patch to the pobd_logger script to address your specific problem. I have included the context diff inline below, and also as an attachment should the inline version get mangled. The changes are simple enough that you could just make the changes manually using your favorite editor, or you could also use the patch utility if you are familiar with that.

(Anyone else following this thread should ignore this patch!)

If you are lazy, the only important change is to the "if" statement on line #3850 (the changes to lines #1282 and #3854 just modify the information printed to the screen to be consistent with what the modified program will do).

Be sure to enable the TERMINATE feature in your config. The 0x10 PID should work based on your previous message.

--- pobd_logger.orig    2016-03-04 10:53:18.403425400 -0800
+++ pobd_logger 2018-08-14 23:15:35.854085581 -0700
@@ -1279,7 +1279,7 @@
         }
         # in verbose mode, announce that the termination condition is enabled
         if ($verbose) {
-          printf STDOUT "Auto termination enabled (NO DATA from PID 0x%02x %d consecutive times)\n", $opt_no_data_pid, $opt_no_data_count;
+          printf STDOUT "Auto termination enabled (CAN ERROR from PID 0x%02x %d consecutive times)\n", $opt_no_data_pid, $opt_no_data_count;
         }
         # toggle the termination command enabled flag
         $opt_no_data = 1;
@@ -3847,11 +3847,11 @@
       # check if the last PID is the one we are instructed to "watch"
       if (($last_pid == $opt_no_data_pid) || ($opt_no_data_pid eq 'any')) {
         # check if the last response for the PID was the "NO DATA" error msg
-        if ((!$last_pid_valid) && ($last_hex_chars eq "NO DATA")) {
+        if ((!$last_pid_valid) && ($last_hex_chars eq "CAN ERROR")) {
           # terminate if we have exceeded the user's specified count
           if (++$no_data_count >= $opt_no_data_count) {
             if ($verbose) {
-              printf STDOUT "Automatic exit: $opt_no_data_count consecutive NO DATA messages were received for PID 0x%02x\n", $opt_no_data_pid;
+              printf STDOUT "Automatic exit: $opt_no_data_count consecutive CAN ERROR messages were received for PID 0x%02x\n", $opt_no_data_pid;
             }
             # that's all folks!
             cleanup_exit($EXIT_NORMAL);

Automatic shutdown

Johnny — Tue, 14 Aug 2018 06:43:38 -0000

Hi David,

You probably know that you can terminate pobd_logger by pressing CTRL+C. This is not a problem when running on a laptop, but on a headless system like the Raspberry Pi, this obviously isn't an option. (I'm am just guessing that you are referring to running on the RPi since you mentioned the pobd_logger_stderr.log file).

Getting pobd_logger to terminate by itself on the Rasperry Pi when the engine is turned off was a tricky problem that took a bit of doing. The current mechanism isn't perfect but worked on the handful of vehicles I tried it on.

The code fragment in pobd_logger that implements the TERMINATE command (documented in the pobd_logger.cfg configuration file) currently just checks for a "NO DATA" response, so it is no surprise that it doesn't terminate on its own for you.

Fixing the code to allow for repeated "CAN ERROR" messages instead shouldn't be too hard. I will try to post a quick fix for this in the next day or two, and then try to formulate something a bit more flexible for a future release.

Congratulations on getting it (mostly) working on the RPi!

Automatic shutdown

David Cooley — Thu, 09 Aug 2018 18:43:59 -0000

When I turn off the engine, I currently get the following in the pobd_logger_stderr.log:
WARN: ELM error: mode 0x01 pid 0x10: CAN ERROR
It appears pobd_logger is still seeing what it considers "data" instead of no response from the pid query
Is there any way I can change the config or pobd_logger itself to terminate when it sees the CAN ERROR?
Thanks

Enhanced PID's

Johnny — Tue, 10 Jul 2018 00:32:14 -0000

Hi David,

Thanks for posting to the list. I get questions by email from time to time, but the user community does not get the benefit of the answers in those situations. So, I encourage user's with questions to post them here when possible.

As far as logging Parameter IDs with a mode other than 0x01, the code isn't currently designed to do that. In principle, that is certainly possible, but it would involve quite a bit of work to implement. The main complication is that each mode/PID combination returns information in a different format that the programmer needs to know about up front, and design the code accordingly to decode it correctly to get the desired information.

For example, Mode 0x01 PID 0x0F (intake air temp) returns a single 8 bit byte encoded as (Temp - 40) Celsius. Whereas, Mode 0x01 PID 0x24 (oxygen sensor 1) returns four 8 bit bytes with a more complicated encoding that produces two physical quantities - a voltage and short term fuel trim. For the standard mode 0x01 PIDs, these issues are not so hard to deal with as the required documentation is readily available on places like Wikipedia. Beyond that, just getting the requisite documentation is a huge hurdle in itself (e.g. not available at all, a trade secret, or only available under license at high cost).

I have given some thought as to how to approach this issue from a programming perspective. What makes the most sense is to use Perl's object oriented features, class inheritance in particular. For example, a base "decoder" class to implement decoding of standard Mode 0x01 PIDs. Then a Pontiac (pick your manufacturer) "decoder" class that inherits all the methods of the base class, overloads those methods with specific "quirks", and implements new methods for PIDs specific to that manufacturer. This at least helps keep the code tidy, readable and maintainable if the required information is available.

Anyhow, sorry I wasn't able to provide a more encouraging answer. It is what it is...

Enhanced PID's

David Cooley — Sun, 08 Jul 2018 04:34:17 -0000

Is it possible to change the Mode used for the PID's? Standard PID's are mode 01, but I have a few Mode 22 PID's I want to log for my 2006 pontiac GTO

Raspberry Pi based OBD-II logger "appliance"

Johnny — Tue, 13 Oct 2015 06:02:55 -0000

The advantages of scantools with a USB interface

Johnny — Tue, 01 Sep 2015 07:13:23 -0000

Introduction

My first scantool had a USB physical layer, mostly because the Bluetooth based units were not yet widely available at the time. I have noticed that many of my friends who are otherwise knowledgeable about OBD-II are unaware of some of the advantageous features of USB scantools that I have came to appreciate by using them. This has motivated me to put together this post.

Disadvantages of USB Scantools

To be fair to those who are critical of USB scantools, they do have some less desirable attributes;

You need to configure the software running on the host computer with the correct baud rate. This is often confusing for users with no experience with USB or legacy RS-232 serial devices. But this is a one time issue, and can be resolved by reading the manual, or by simple trial and error. Once you have identified the correct baud rate, and know how to configure it in your OBD-II software, there is no more pain.
Tablet and Phablet devices are popular these days, but OBD-II software packages for these devices rarely have support for USB scantools. However, USB scantools do work quite well with the Raspberry Pi single board computer, and "out of the box" for the most part.
There is the additional clutter associated with the cable that connects the scantool to the host computer.

Advantages of USB Scantools

For applications such as OBD-II logging, USB scantools offer some unique advantages when compared to those with a Bluetooth physical layer. The two most prominent advantages are; greater speed and more robust, reliable connections with the host computer. They also tend to be less expensive than Bluetooth scantools of comparable quality.

Greater Speed

With regard to the speed advantage of USB scantools, Perl OBD-II Logger has a simple feature that can help quantify this. When the program exits, it prints some summary statistics to the stdout unit. One of the statistics is the average reply time for each of the PIDs that were logged. This is the average time it takes for the scantool to reply to a request from the host computer to return the value of a given PID. There are many different factors that determine the reply time, such as the vehicle ECU itself. Another is the inherent communication speed of the physical layer.

Here are some example reply time statistics from a logging session that were collected using my favorite, and best performing Bluetooth scantool (a well known name brand).

Summary of PID logging statistics
                                      average
  pid  requests   overdue   replies reply time
 ==== ========= ========= ========= ==========
 0x04       301        21       301   0.031227
 0x05        31         4        31   0.030660
 0x0b      1199        35      1199   0.035938
 0x0c       600        33       600   0.031200
 0x0d      1797        37      1797   0.037195
 0x0e       600        20       600   0.032347
 0x0f        31         3        31   0.029178
 0x10      1795        32      1795   0.037678
 0x11       600        20       600   0.032282
 0x33         6         1         6   0.030730
 0x3c        41         5        41   0.033641
 0x43       300        21       300   0.030120
 0x44      1196        24      1196   0.036010
 0x45       598        22       598   0.031258
 0x46        21         2        21   0.034851
 0x49       300        20       300   0.030259
 ---- --------- --------- --------- ----------
total      9416       300      9416   0.034886
Total elapsed time: 0 hours 10 minutes  4.425 seconds
Average PID sample rate: 15.578 (samples/second)

Here are some reply time statistics from a logging session in the same vehicle as above, a trip of similar duration, but collected using my cheapest USB scantool (also a well known name brand).

Summary of PID logging statistics
                                      average
  pid  requests   overdue   replies reply time
 ==== ========= ========= ========= ==========
 0x04       395         6       395   0.020852
 0x05        40         2        40   0.025990
 0x0b      1577        11      1577   0.018967
 0x0c       788         8       788   0.019502
 0x0d      2364         9      2364   0.018996
 0x0e       788        11       788   0.019945
 0x0f        40         4        40   0.027082
 0x10      2363         8      2362   0.019105
 0x11       787         9       787   0.019387
 0x33         7         0         7   0.021131
 0x3c        53         5        53   0.021857
 0x43       393         8       393   0.020974
 0x44      1573         8      1573   0.019769
 0x45       786        10       786   0.020035
 0x46        27         4        27   0.024161
 0x49       393         9       393   0.020758
 ---- --------- --------- --------- ----------
total     12374       112     12373   0.019546
Total elapsed time: 0 hours 13 minutes 11.058 seconds
Average PID sample rate: 15.641 (samples/second)

Note that the Bluetooth scantool takes longer to respond than the USB scantool, 34.9 milliseconds versus 19.5 milliseconds on average, or about 75% longer. This speed advantage allows you to sample PIDs at higher effective rates with the USB scantool (everything else being equal).

I have tried logging with some of the inexpensive Bluetooth scantools, like those available on Amazon and EBay. The only one of them that I got working reasonably well was much slower, with average reply times of more than 100 milliseconds.

More Robust Communications

The greater simplicity of the physical layer of USB scantools translates into more robust communications with the host computer. Unlike Bluetooth scantools, they do not suffer performance degradation due to things like fluctuating signal strength or radio frequency interference.

Of the Bluetooth scantools I have tried, only one of them had (in my opinion) acceptable connectivity. One of the more common problems I saw with the inexpensive Bluetooth scantools was poor Bluetooth connectivity. On the other hand, none of my USB scantools have suffered from any connectivity issues, they always seem to stay connected just fine for me, and they are fast.

Recent posts to Discussion

Automatic shutdown

Automatic shutdown

Automatic shutdown

Enhanced PID's

Enhanced PID's

Raspberry Pi based OBD-II logger "appliance"

The advantages of scantools with a USB interface

Introduction

Disadvantages of USB Scantools

Advantages of USB Scantools

Greater Speed

More Robust Communications