In week 3 we (more nearly) finalized our product's design. In the previous week we had debated how to transmit data from the OBD device to the smartphone app. We were considering using Bluetooth, WiFi, or USB. However we discovered that Android smartphones do not support ad-hoc WiFi networks, nor do they support USB in host mode. Therefore, we are going to need to use Bluetooth.
This also informed another design decision, which was whether or not to require live access to the smartphone medium. Our original use case plan was to have the OBD device send data to the smartphone to store and do limited processing, and then have the smartphone send data to the web portal. But we recognized the smartphone as a weak link in the design, because not all potential customers will have Android phones, but more importantly the phone's Bluetooth module can only be used for one application at a time. For example, our OBD device cannot transmit data to the phone while the user is making a call with a Bluetooth headset. We thought we could get around this limitation by designing a USB or WiFi transmission protocol, but since we discovered we will need to use Bluetooth, we had to address this issue.
Our solution is to drop the requirement that the OBD device has live access to the smart phone. We will get external Flash memory for the OBD device, so it can buffer data and store date while the smartphone's Bluetooth module is not paired with the device. We reason that with a modest amount of memory, 1 MB, we could store enough OBD data on the device for several, typical-length car trips. Our minimal use case expectation is that the user will run the smartphone app to make it pair its Bluetooth with the OBD device at least once every couple of car trips.
Our optimal use case is still that the OBD device has live Bluetooth access to the phone, because then we can pair OBD data with GPS coordinates from the smartphone. If the OBD device does not have live access to the phone, we cannot determine the location of the car when data was taken. We discussed getting a GPS chip, but decided the cost was not worth it.
We also addressed the concern that our smartphone app would drain the phone's batteries because it ran Bluetooth. Our answer is buy a phone charger for the car (courtesy Ben's co-worker).
We met with Mike and discussed these issues we were encountering and how we were modifying our design. He provided us with some equipment including a Nexus One Android smartphone and an OBD to laptop product that is similar to our Hardware end, though this product was not a successful product and was recently discontinued. He also described Smart:Drive's web portal and mentioned that it uses Amazon's web services. He gave us the greenlight to continue using Google's web services, but we will try to devise a data converter to share our data with his during a product lifecycle. He also suggested that we use Google's Maps API to plot a car's routes as part of our UI. Brent will look into this.
We began ordering our hardware. The Elm 327 is responsible for retrieving data from the OBD port. The Atmega644p microcontroller commands the Elm, buffers our data within flash memory, and manages the bluetooth module. Our external storage, W25Q80BVDAIG, provides 8Mbits of flash memory. The Roving Networks bluetooth module, RN-41-SM, allows bluetooth communication through a serial connection. We began studying the data sheets for these hardware devices.