Automatically re-connect OBD

Has anyone else wanted their OBD app to automatically re-connect each time the car is started? Probably this is only important to those who use a dedicated display device (an old phone or tablet) left permanently in the car for OBD connection. Here is a method that works for me with a Bluetooth OBD interface device.

ScanGauge (and its imitators) does this without Bluetooth, but it has a very limited screen which must be connected to the OBD interface by a cable.

The Torque app does it by keeping Bluetooth on and constantly trying to reconnect to the paired Bluetooth OBD interface, which some users complain rapidly depletes the Android host device battery.

Other apps like OBDLink / Fusion can be set to autoconnect to a designated and paired Bluetooth OBD interface. They do this when launched afresh, but generally not so reliably to re-connect from the background each time the car is started. There is a long delay on launch to load all the data for sensors / PIDs available in a Toyota hybrid vehicle, so it makes to keep the app in the background between car starts.

Part of the problem may be that classic Bluetooth devices only ‘broadcast’ their presence in ready to pair mode, not in ready to connect mode. In fact it is a security risk to leave an OBD interface in ready to pair mode, so some devices (like OBDLink LX and MX+) are designed to enter this state only when a button on the device is pressed. They are also designed to go to a low-drain sleep state after a few minutes of inactivity, then wake and be ready to connect when the car is opened and started. (In fact this is still a work in progress, but hopefully it will work with future versions of the firmware.) OBD software is designed to connect to a designated and pre-paired Bluetooth OBD interface, though it cannot pre-confirm that the device is present by a Bluetooth discovery scan.

In Android, the solution for me is to use the free (and add-free) Automate app, provided the host device is not set to lock. The “flow” I use currently is attached below. It performs the following tasks:- When the car is turned on: Enable BT > Foreground OBDLink app > Delay 1s > Click ‘connect’ > Delay 1s > Click ‘connect’ in dialog box > Delay 8s awake > Click ‘Dashboard’ > Monitor power source. When the car is turned off: Android ‘back’ > Delay 1s > Click ‘disconnect’ > Delay 3s awake > Disable BT > Background OBDLink app (allow host device to sleep) > Monitor power source.

This makes the re-connection truly automatic (no manual input required) provided that MX+ (firmware v 5.6.24) is plugged in before the car is started. If the “flow” does not work as expected; eg if OBDLink (v 5.30.0) decides to reload OEM data, or if a delay is too short, or if MX+ is not plugged in, or if the car is turned on in ‘ignition’ instead of ‘ready’ mode; it will be necessary to intervene manually to restart the “flow”. For example, my car sometimes needs more than 7s for the OBD and CAN re-connection, but the “flow” is 100% reliable if I allow 8s. Anyone else may need to tailor the flow to suit their own OBD app or display device, but this is easy.

Automate uses very little power while running in the background. In v 1.35 it can not detect Bluetooth SPP devices (like MX+) in ‘waiting for connection’ mode, or directly connect them through apps like OBDLink. So the “flow” relies on simulated screen clicks that are a method of last resort (because this method does not work on some android host devices, and such devices vary in speed and screen dimensions). It may also be necessary to load extensions and use ‘native’ in the ‘timing accuracy’ settings in Automate.

It is best to apply any settings needed in the OBD app before controlling it through Automate. With the OBDLink app, I use settings: (a) Preferences > Communications > Connection Mode > Manual, and (b) Preferences > General > Dashboard > Do not Start on Dashboard Page.

Although MX+ works under Android or iOS, I think Automate is Android only. There may be an equivalent iOS app, though I understand that iOS puts restrictions on Bluetooth connections. I have not tried it. Perhaps an iOS user can provide a solution there.

 

Prof: Toyota hides its (non-legislated) PIDs very carefully, You can read more here, but the short answer is to use an OBD app (like OBDLink) that licenses the PIDs from Toyota.

ChapmanF: The Android system broadcasts to all apps when external power supply is connected to an Android host device. So when the Android host device is plugged into an ignition-switched outlet (eg cigarette-lighter to USB adapter) an app like Automate (or Tasker if you want to pay money and have a steeper learning curve) knows when the car is switched on or off, without using any substantial power to monitor this independently in the background. All the other tricks mentioned by Prof are not necessary for this purpose.

Leadfoot: the OBD port always supplies 12v, but good OBD interface devices drop back to low drain (<2mA for OBDLink LX or MX+) after a short period of inactivity. Then they use a trick like voltage change monitoring to wake up and return to waiting to connect mode when a door is opened or the ignition is switched on. Classic OBD devices do not advertise their presence in waiting to connect mode, only in waiting to pair mode. They are waiting to connect, but they are not discoverable with an Android Active Discovery Bluetooth scan. It is a security risk to have an OBD interface continuously open to pairing, so good (expensive) devices do this only for a short time after button press on the device. As mentioned above, OBD software is designed to connect to a designated and pre-paired classic Bluetooth OBD interface, though it cannot pre-confirm that the device is present by a Bluetooth discovery scan. BLE may be different, I am told that it has easier connectivity and lower throughput. Which would you prefer for an OBD interface connected to a modern car CAN bus? Based on these two claimed characteristics, I would prefer classic Bluetooth. But I may be mislead, as I have not researched BLE.

 

The OBDLink devices can reveal ~100 PIDs/second for PC & Android. According to Wikipedia, classic BT has a maximum data rate of 1–3 Mbit/s (vs 0.27–1.37 Mbit/s for BLE). Toyota HVs have a lot of useful PIDs (licensed to OBDLink). Not the kitchen sink though. Still, some folk find it useful to monitor (or log) some of them in real time. My understanding is that ScanGauge cannot access most Toyota PIDs, and it cannot log. Horses for courses.

 

All true, and anyone with the expertise and equipment can 'discover and deduce' the PID addresses and formulae. Some early Prius fans did that, then Toyota changed the PIDs for subsequent HV models. That is easy for Toyota, and the "ECU hackers" have to start all over. Worthwhile if anyone places little value on their time (which no mortal should do), but why bother when access can be obtained so cheaply? Included in the MX+ price (or about US$ 8 + 10 for Fusion + one Toyota model OEM add-on) is the full set of (non-registered) Techstream PID data. You should check first if your car is covered. I would be careful about other potential suppliers: judging by the reviews of the Toyota add-on for Torque. As Prof found, nobody (including PriusChat users, bless their souls) seems to have discovered and made public more than a very few of the available PIDs for any current Toyota HV; it is just too easy to buy OBDLink or Fusion with a data add-on. That leaves ScanGauge users mostly in the dark, for a lot more investment. Then there is that last-century screen (think dot matrix), inability to log etc. But it is horses for courses.

Closer to the topic of this thread, I think ScanGuage is the King for security. But a bluetooth "dongle" that only enters 'ready to pair' mode when a button is pressed on the dongle is fairly close. I also think ScanGuage has been King for ease and reliability of re-connection. The purpose (or effect) of this thread is to show how to make this just as easy and reliable for a quality BT dongle.

 

If anyone really objects to paying about US$ 8 + 10 for access to the full licensed set of (non-registered) Techstream PID data, and has the necessary technical ability to DIY, they might enjoy this paper on Canhunter: https://par.nsf.gov/servlets/purl/10139471.