Carpal 2 - Your Automobiles OBD-II Dashboard Buddy

Introduction

Update Feb 21, 2017 - I have been living with the new Carpal2 for about 2 months now, and after some code tweaking in early January it's about as stable as I can get it. The default settings for WNCInterface are to "hang forever on fatal error" which I changed to return failed, and also changed a setting to reset on fatal error - because cell signal will come and go during our drives thru the country and it will need to automatically reconnect if possible. Also put many checks for WNCInterface::connect() thru the code - that returns 0 if connected and -1 if not, followed by NVIC_SystemReset() on a nonzero return code. I have created many maps of carpal data trips, and regularly check that the knock sensor (p0330) is the only thing causing the check engine light to be on! Once saw a p0440 evap system code but it went away.

Part 1

Carpal was a fun project using the Linkit One 2G capability, it has kept me connected to my car's health and location for the past year quite successfully. I could sms text it to see what the 'Check Engine Light' was complaining about, research the problem and decide if immediate action was needed or not. The GPS reporting with PubNub Eon Maps was a lot of fun so family could watch trips. Data was logged in a Mongodb database using nodejs scripts that watch the pubnub queue for events.

Now 2G / GPRS is on the verge of being shutdown so I started searching for a replacement and imagine my joy at finding this contest and the AT&T IoT Starter Kit for an affordable entry price!

Hardware assembly is largely high level connecting of major components, the OBD-II uart serial to the K64F uart4 on J199 (uart2 and 3 are used by the cellular shield), 12v from the OBD-II uart - which is permanently connected to the car battery, even when ignition is off - powers a common 7805 regulator for the K64F Vin, which powers both boards. There is a toggle switch on the outside of the enclosure to power off for long periods of parking or reset if needed.

GPS is now provided by a fast startup EM-506 module, interfaced by a soft serial port on pins PTC7(TX),PTC5(RX), as uart0 is used by mbed system.

OBD-II UART uses PTC15(TX),PTC14(RX) cross connected to the uart rx,tx pins.

I used parts around the shop - a sloping control panel box from a hamfest long ago fits nicely on the dashboard under the sloping windshield, allowing the box to sit further forward than a plain box. The LED driver transistor board is re-used from the previous Carpal. For connecting the antenna to the cellular shield I was going to feed them thru rubber grommets and connect to the board but the height of the cables and the 2 boards would be way too big to fit in my box. Luckily I had a couple of right-angle SMA coax connector cables and SMA bulkheads that worked perfectly, allowing the antenna to be attached to connectors on the outside of the box.

Part 2

Once the parts are boxed up and working, then comes the fun part! I largely cloned the example code for the firmware, using the WNCInterface, sensors and Pubnub sync examples - plus an OBD library used from the LinkitOne Arduino sketch. That was a class, but I just flattened it into a set of helper functions right in the main.cpp file, that has a lot of obd interface string handling intelligence already so I really wanted to keep it! Ideally it should be made a class and shared with the mbed community some day. The Sensors I want to use are the GPS of course, the accelerometer X and Y, and a selection of automobile data like engine rpm, load and vehicle speed. Also I want the capability to send a request for the Diagnostic Test Codes if the Check Engine Light is on.

The running cycle is to collect the location and car data every 30 seconds, bundle it up into a json string and publish it to a Pubnub topic 'carpal2'. I have node.js scripts that subscribe to that topic and collect the data and insert records into a MongoDB database for bulk collection. An AT&T Flow also subscribes to the 'carpal2' topic and does several functions. One is to translate the location into a form that eon-map can use to display the real time location on a map. The device just publishes a message with the format {"la":"37.8267","lo":"-122.423"} - but eon-map wants to see the key 'latlng' and an array {"latlng":[37.8267,-122.423]} . A simple Flow function does the translation and publishes it to another topic 'cardata' which the eon-map javascript watches for location to display on a webpage map. Eon-map is fun for sharing my travel progress with family or watching my wife travel.

Part 3

Another Flow function takes the 'carpal2' topic and prepares various data to be forwarded to ATT M2X dashboard for charting, such as the X-Acceleration, Y-Acceleration, engine load, coolant temperature, rpm, or vehicle speed.

For sending commands and requests to Carpal2 - I have an mqtt dashboard app on my Android phone, which can create a variety of interface widgets like buttons to publish a message to a mosquitto mqtt server running in Amazon AWS, in a cheap centos instance (about $10 / month). That is locked down with a username and password required to access it, and also has a TLS port. Flow can talk to the TLS port 8883 and ignore my private CA signed cert, but the cellphone mqtt dashboard still needs the CA cert loaded in a .BKS (BouncyCastle) keystore format. You can use Portecle to create a keystore.bks file, add the ca.crt used to sign the TLS port 8883 certificate, load that onto your phone and show mqtt dashboard where to find it for SSL and it works!

The mqtt dashboard sends a command {get:dtc} to mosquitto, and a Flow process subscribed to the topic 'carpal2cmd' forwards any messages on to Pubnub 'carpal2' topic. When the device publishes a message bundle of sensor, gps and automobile data, it also checks for new messages. If any are found with the string "get:" a case statement routes it to the appropriate function, in this case a 'd' starts a GetDTC() function to get the diagnistic test codes and puts them in a json string for reply. Another Flow function looks for reply strings and forwards them on to mqtt topic 'carpal2msg' which my phone mqtt dashboard is subscribed to - that displays any incoming diagnostic test codes, like P0330 for knock sensor malfunction.

As of submission project is still in progress of refinement and fleshing out, but all services are working - data from the car obd2 port (coolant temp, rpm, speed and engine load) + accelerometers X & Y + GPS position are being published to Pubnub, saved in MongoDB, processing in Flow for location displayed on a web page with eon-map, recorded in an M2X device charts and responds to a request for DTC codes from a cell phone running mqtt dashboard.

Part 4

Now the really fun part begins - living with the new device, tweaking and adding features and services to increase usefulness.

All the different services are interconnected as in this diagram.

Interestingly in this phone screenshot, after getting the P0330 for the knock sensor as the check engine light is usually on - later on during a trip to get celery for wife's stuffing, the light went off, which is rare, and then it reported the expected 'none' for get:dtc.

Once the raw data is collected it can be sliced, diced, charted and plotted many ways - I just discovered 'geojson' to create this clickable mapbox map (available in the github repo) from today's test trip.