-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Gobbed is Free Software for connecting to your vehicle's data buses.
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"
- Turn on Bluetooth and pair with your Bluetooth ELM327 adapter
- Instant access to real time data from your ECU.
- Profit?!?!
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?
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.
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."
The plan now is to use an Android WebView. This is to make it easy for future developers to update and improve the program.