Bluetooth OBD2 connect

[mirrormurr]

Hi there, How should I proceed to connect a normal Bluetooth ELM 372 device? I have edited the /home/pi/.openauto/config/openauto_system.ini file as requested, but do I also have to pair the dongle in Raspberry OS normally in order to connect to Onboardpi? Additionally, in /etc/udev/rules.d/99-serial.rules I added the required line KERNEL=="rfcomm[0-9]*",MODE="0666" as described. Thanks for all your good work, this software looks really promising! murr

[bgunson]

Hello @mirrormurr,

I have not done any testing with a bluetooth adapter myself but would love to help you out so others can use what we do here to help them. My inital thoughts are to connect and pari the device normally to the Pi. Firstly, what adapter do you have?

Try this article to begin.

Here's a video that goes through similar steps

If you can connect and pair, head to 'Settings' > 'OBD Connection' in the onboardpi web app and see if you can see the rfcomm port in the 'serial port' dropdown.

You can poke around in python-OBD for issues regarding bluetooth adapters. Python-OBD is the underlying library onboardpi uses for obd connection.

Let me know how it goes.

Bennett

[mirrormurr]

dear Bennett, @bgunson Thanks a lot for the links and following up! I am using a Mobilly ELM 327, but it might be a bit funky, as I have had problems with a classic connection via Bluetooth in OAP as well. Quite often, I have to unplug- and plug it back again in order for it to connect while keeping the main ignition on. I followed the instructions in your first linked article, and managed to establish a connection at one point, and got the following output on the connection screen in OnBoardPi: 02_S1_WR_CURRENT 0.05 OBD Connection ELM VERSION ELM327 v1.5 ELM VOLTAGE 11.4 Protocol ISO 14230-4 (KWP 5BAUD) Port /dev/rfcomm0

My car is an old VW Golf Mk5, and I am not sure if the OBD-port is constantly powered, usually I have to turn the ignition on to get a signal. I succeeded once doing a cold-boot of the system, establishing the connection, and being able to read all the gauges, but further attempts failed, despite reboots, and un-plugging the dongle while booting. My normal phone could connect normally to the dongle, but somehow, Raspberry OS was unable to establish a connection to the serial-port. Using a bluetooth-graphical interface, also confirmed the presence of the device, but failed to connect to the serial port. Could it be that the use of rc.local-file might not be sufficient to allocate the serial-connection, and that the random timing by booting is the decisive factor here?

here a copy of my rc.local file: # IP=S(hostname -I) || true if [ "S_IP" ]; then printf "My IP address is %s\n" "$_IP" fi /usr/local/bin/rpi4pci.sh rfcomm bind rfcomme0 XX:XX:XX:XX:XX (Mac-address of the OBD2-device) exit 0

best regards, murr (updated comment after further testing)

[bgunson]

Hey again @mirrormurr,

Looks like you're on the right track. My experiences with raspberry Pi and Bluetooth has been the same as what you are experiencing. The device was not auto-connecting, etc unless manually done. As for the rfcomm port binding, that may be the missing link here but I am unsure about where to go next without looking into it more.

I prefer to use a USB OBD adapter like the OBDLink SX or similar as the connection is consistent and is automatically bound to a /dev/ttyUSB port on boot/plug in and out. If that's an option, I recommend trying one out and I am sure more cost friendly USB devices work as well.

Edit: check the spelling of rfcomm~e~0 in your .rc.local if that hasn't been resolved

[mirrormurr]

@bgunson Dear Bennett, Spelling error was only due bad screen-capture, the file itself looks ok. After using OAP again today, a reset of the adapter again did the trick and got the system up and running. Might be a timing-issue, but i am not sure where to start.
Nevertheless, I'll probably get a USB Obd2 device and see if I could install the cable discreetly pass the steering wheel -my unit is just attached onto the dashboard.

[browntownington]

I can confirm that binding the rfcomm on the host pi works for BT adapter I have - for getting oboardpi working.

There is one caveat though. You cannot pair new devices in OAP whilst the rfcomm is binded. You need to unbind the rfcomm to do the pairing then bind it again. Once this is done you can use OAP phone Bluetooth and Onboardpi.

The only time I see this being a hassle is when you have a guest travelling in your vehicle and they wish to connect to bluetooth to play music. But perhaps can create an application which runs to unbind/bind in OAP.

EDIT: Found a second caveat. BT music audio playing is very choppy when rfcomm is binded. Unbinding it resolves this but you loss onboardpi obd

[browntownington]

EDIT: Found a second caveat. BT music audio playing is very choppy when rfcomm is binded. Unbinding it resolves this but you loss onboardpi obd

So this above issue only occurs when AA is not connected via USB/wifi. From what I've learnt in my testing the music/audio/sounds are transferred over USB/wifi when AA is connected. But if AA isn't connected it's relying on the BT connection alone and choppy audio is experienced if rfcomm is binded.

Would be interesting to hear if other people notice this issue. It could be just an issue with my BT dongle/chipset or it could be related to binding rfcomm.

[bgunson]

Thanks @browntownington for all your experimenting regarding Bluetooth connectivity! It seems most of the OS/OAP specific issues are out of OnBoardPi's scope, but if there's anything else I'd love for an excuse to get back into its development.

Are you using an external Bluetooth USB adapter (if so which one) or the built in chip?

[browntownington]

Appreciate that @bgunson. I thought I'd rather just share my feedback and experience in this thread in case other OAP/onboardpi users come along using BT OBD later and run into similar problems :)

I upgraded my older Viecar OBD BT with a Vgate Pro BT4 today. And it seems like now everything is working as it should, able to pair new devices whilst rfcomm is binded. The skippy/clipping of audio has improved so much I think it only faintly occurs. If it bugs me I might upgrade the USB BT (Old generic lying around) adapter to Panda and see if that improved it.