Skip to content
davidhubbard edited this page Apr 20, 2016 · 3 revisions

Gobbed wiki

Gobbed logo Gobbed is Free Software for connecting to your vehicle's data buses.

Table of Contents

Design

Gobbed began life as a bash script for Mac OS X to talk to almost any Bluetooth ELM327 adapter out there:

#!/bin/bash
# Gobbed: shell script to talk to an ELM327 adapter from Mac OS X
# For linux users, just update /dev/cu.ELM327* to your desired /dev/ttyFoo
#
if screen -ls | grep -q '^\t[^\.]*\.ELM327'; then
  : #echo "found: screen ELM327"
else
  #echo "start: screen ELM327"
  screen -d -m -S ELM327 /dev/cu.ELM327* 115200
fi
#
sendcmd() {
  screen -S ELM327 -X stuff "${1}$(printf \\r)"
  # Ugly hack: a better script would have screen capture output to a file (-C flag)
  # and process responses from the file looking for a ">" character instead of just
  # sleeping here:
  sleep 0.2
}
#
sendcmd "ATE1"
sendcmd "ATL1"
sendcmd "ATI"
  1. Turn on Bluetooth and pair with your Bluetooth ELM327 adapter
  2. Instant access to real time data from your ECU.
  3. Profit?!?!

Android Adventures

Next up was to make an Android app and permanently mount a tablet in my car.

Easier said than done: The BluetoothChat Sample on Android Developers hasn't been updated in a while. A few hours of hacking and I had an app with:

  • Updated code to the latest SDK.
  • Ripped out com.example.android.common.logger, a library designed to "drop-in replace" java.util.Logging and fix Android logging.
  • Without com.example.android.common.logger, com.example.android.common.activities.SampleActivityBase is no longer needed.
  • Bug: device rotation killed a running connection.
  • Bug: BluetoothChatService.ConnectedThread.run loops around to receive more data while a reference to 'buffer' is queued as an android.os.Message, leading to a race. Calling obtainMessage(buffer.clone()) in run() fixes that.
  • A few more minor bugs.

It was a good exercise but the result was still just a Bluetooth Chat app. It can talk to an ELM327, so all I need is a nice GUI, correct?

Chrome App

Google Chrome is a great solution for separating the UI from the controller. Although I have not tested the chrome.serial API on my tablet, it seems to have what I need.

First off, I need to cache the JS so it is available offline. My options include:

  • Chrome App: I get this error when visiting the Chrome Webstore on my tablet: Sorry, your operating system is not supported just yet. The Chrome Web Store is available on Windows (except RT), Mac, Chrome OS and Linux. Why don't you send yourself a reminder...
  • Apache Cordova: compile a Chrome App into a native app.
  • React Native: same, though not specific to Chrome. I could add a Bluetooth Serial plugin.
  • Android WebView: now I'm getting somewhere.

Android WebView

I had the stack wrong. Instead of Android OS > Chrome App > My code, the best choice is:

Android OS > Android Native App (with JS resources) > WebView

The advantages include:

  • Best backward compatibility. WebView has been a part of Android since Android 1.
  • Better long term support. ChromeOS is being merged with Android, so it probably doesn't have a bright future.
  • I still get to use the awesome Chrome Devtools
  • I could actually use it on my tablet. (The Chrome Web Store doesn't work for my tablet, but the Google Play Store does.)

And the disadvantages list:

  • If I fiddled with Apache Cordova long enough I could probably get to a truly "write once, run on a lot of platforms."

Conclusion

The plan now is to use an Android WebView. This is to make it easy for future developers to update and improve the program.

Clone this wiki locally