Simple, WiFi-enabled, OBD-II vehicle data logger and cloud services creating a platform for custom software development.
We want to give application developers the opportunity to develop and sell applications that make use of vehicle data. The MotoBox installs easily under the dash in any vehicle, and continuously records data while the vehicle is in use. It’s configured one time with a WiFi access point configuration and whenever it returns to that access point it automatically uploads its logged data to our cloud services platform.This data can then be accessed through our APIs and used in custom software applications.
Before you back us please make sure the MotoBox is compatible with your vehicle. The MotoBox is designed to be compatible with all 2008 and later model year light-duty passenger vehicles sold in the United States, as well as many model year 2003 to 2007 vehicles. Check the compatible vehicle list below for supported 2003 to 2007 models. Note that this list is not necessarily complete, if your 2003-2007 vehicle is not in the list try the alternate vehicle compatibility test instructions.
The MotoBox continuously collects data from your vehicle's OBD-II port. Data is retrieved from the MotoBox using WiFi, either by querying the device directly over the internet (we're calling this the "MotoBox API") or by querying the persistent database where we store MotoBox data (we're calling this the "MotoServer API").
We're currently working hard on the project but need funds to build a pilot production run at scale! We think this is a really cool idea and we'd love to help you get vehicle data for your own projects. There's an incredible amount of vehicle data that can be obtained, and you can also view and clear diagnostic trouble codes (which trigger the "check engine" light in your car).
If you want to see more about how the project got started, please jump down to the "Project History" section.
When you back us at the "DEVELOPMENT KIT" levels, you'll get access to MotoBox API or the MotoServer API depending on the reward level (see rewards). Access to an API means that you'll get an account that will allow you to develop applications for any MotoBox, as long as that MotoBox has given you the right to access it's data. We reserve the right to limit excessive data use.
The MotoBox API is our simplest API, intended for developers who want to query the MotoBox directly without storing any persistent vehicle data on our servers. This will be useful if you want to roll your own persistence database, or write applications that don't require persistence at all.
The MotoServer API is intended for developers wanting to build custom web applications around persistent vehicle data. It contains all the functionality of the MotoBox API, plus some extra persistence features. The MotoBox can be configured to log its data to the MotoServer, where it may be accessed via this API. The advantage of using the MotoServer is that it stores all vehicle data in a central location. If a user has multiple MotoBoxes in use, all of this data may be accessed simultaneously.
Our initial delivery will include a proof-of-concept implementation of a custom web application using the MotoServer API. This will demonstrate an example of how this web API may be used to develop custom applications.
All MotoBoxes are the same in that they may be accessed via either API. However, the owner of each MotoBox will control who will be allowed access through the API. This sets up two different models for custom application development, both supported by the MotoBox.
Open "app" model
In the open model, users purchase MotoBoxes on their own and other developers create their own applications. These applications provide a way for MotoBox owners (through our APIs) to grant access to the data in their devices.
Closed "enterprise" model
In the closed model, a developer provides a complete system to customer, which consists of the software and one or more MotoBoxes. In this case the developer owns the access rights to the MotoBox, and can grant access to his/her own application.
Vehicle Data (OBD-II)
The "On-Board Diagnostic" System known as OBD-II has been required in all light-duty passenger vehicles sold in the United States since 1996. It has primarily been intended as way to maintain and enforce emissions compliance, to improve fuel efficiency and reduce pollution. In practice, it makes a lot of vehicle data openly-available through the OBD-II port.
The OBD-II port is 16-pin, trapezoidal-shaped connector found in all vehicles supporting OBD-II. It is generally found near the steering column, somewhere underneath the dash.
When OBD-II was initially mandated, each auto manufacturer had their own implementation which required different hardware to interface. Additionally, at first only a few features were available. As the OBD-II standard and implementations have matured, the interfaces are much more standardized and much more data is now available.
OBD-II provides a standard way to access a variety of vehicle data across different manufacturers and models of vehicles. The actual data available varies from model to model, but generally newer vehicles provide more types of data.
The data available from OBD-II falls into three categories: parameter data, diagnostic trouble codes (DTCs) and emissions monitor data. These are described in more detail below.
The OBD-II system provides a variety of different data parameters, for which the current value can obtained at any instant. Some of these parameters come directly from sensors in the vehicle (e.g. vehicle speed, engine speed or coolant temperature), while some values are calculated by the vehicle from other data (e.g. engine loading). The MotoBox may be configured to sample and log these parameters at requested intervals.
Additionally, there are static parameters such as vehicle identification number (VIN), which may be recorded by the MotoBox.
OBD-II Parameter Data List - A summary of the possible parameter data available from OBD-II.
Diagnostic Trouble Codes
A diagnostic trouble code (DTC) is an event message generated by the vehicle to indicate a warning or error. Typically, these are very specific messages indicating a problem with a particular vehicle system. The MotoBox detects and records when a DTC is active and when it has been cleared. Some examples include:
- P0112: Intake Air Temperature Circuit Low Input
- P0306: Cylinder 6 Misfire Detected
- P0450: Evaporative Emission Control System Pressure Sensor Malfunction
DTCs may also cause the malfunction indicator lamp (MIL), often known as the "check engine light," to be illuminated. This is a warning lamp on the dashboard of all OBD-II equipped vehicles. The MotoBox is capable of monitoring and recording the status of the MIL.
Diagnostic Trouble Code List - A more complete listing of DTCs from the Delaware Division of Motor Vehicles.
Emissions Monitor Data
The third major category of OBD-II data is emissions monitor data. Most modern vehicles are continuously running vehicle emissions compliance monitors. These monitors are designed to ensure that all of the emissions compliance equipment is operating correctly. Some monitor examples are:
- Catalyst monitor
- Exhaust gas recirculation monitor
- Evaporative system monitor
The results are generally presented as a simple "pass" or "fail" (or "not ready" if the vehicle has not met the conditions to complete the test). In many jurisdictions, the results of these OBD-II tests are used to certify vehicles for emissions compliance (replacing older tailpipe exhaust gas sampling methods). The MotoBox can monitor and record the status of these tests.
Emissions Monitor List - Full list of OBD-II system monitors.
In addition to the raw data provided from the OBD-II system, the MotoBox may also derive some additional data parameters. Examples include:
- Trip start/end events
- Vehicle distance
- Engine run time
- Engine idle time
- Fuel fill-up events
- Fuel consumption/efficiency
- MotoBox installation or removal
In the beginning, Matt had just gotten a new car and was trying to keep track of how much gas he was using. Whenever he'd fill up the tank he'd record (on paper!) the amount he put in, as well as the odometer. He could then manually do the math to track his fuel efficiency.
However, this seemed like a lot of work especially since Matt had a background in using OBD-II to get data from vehicles. He envisioned creating a simple OBD device to do this simple task, and so began work on his hardware prototype.
Some time after Matt had a functioning hardware prototype, he talked to Joe about his idea. Joe thought this a really great idea... not particularly about the fuel mileage calculations, but just about using vehicle data to do all kinds of things. He quickly rattled off several different potential applications.
Matt wasn't very interested in changing the application at that point, but he and Joe continued to discuss the feasibility of the project. Eventually they came to the realization that there are a whole host of applications that are possible, including many that no one has even thought of yet.
Not wanting to limit themselves to one particular application or market, they thought the best approach would be to provide this vehicle data to other developers -- in an easy to use way -- using the MotoBox. Joe pitched Matt on how they could provide this data over the web through a custom API and they were off and running.
Now -- without hardware development skills, or knowledge of OBD-II -- a software developer can access vehicle data to create whatever they can imagine.
Here's the first-ever demo we shot. If you compare this to our current demo in the "Project Status" section, you can see we've come a long way!
Joe is developing our application-level software including our web APIs and database.
Joe is a software engineer who has done extensive work developing solutions for vehicle-connected devices. He's also designed web applications for embedded servers, and thus has broad knowledge of low- and high-level software development. He's looking forward to connecting with other developers and seeing all the amazing ideas they have for the MotoBox!
Even though Joe is our high-level developer, he is no stranger to automotive protocols. He's worked extensively with SAE J1939 which is used mostly on heavy-duty trucks and off-road vehicles, but is built on the CAN protocol just like modern implementations of OBD-II used by the MotoBox.
Joe knows what it takes to build maintainable, scalable, robust software systems and is excited by the challenge of providing a platform for other developers. He’s very responsive to good suggestions, so don’t hesitate to bring new ideas to his attention.
Matt is developing the MotoBox hardware and firmware. He's the OBD-II expert on the the team.
Matt has been working with embedded systems for his entire professional career of more than 10 years. Most of that work has been in the automotive and vehicle telematics sectors. He's spent years developing vehicle-based communications devices and is highly experienced in a variety of automotive protocols such as OBD-II (SAE J1979) but also other protocols such as SAE J1587/J1708 and J1939.
In addition, he has the advanced embedded skills of a guy who's been around the block with a product or two. This includes hardware and firmware development based on a range of microprocessor architectures and many types of communications interfaces e.g. RS232, SPI, I2C, CAN, USB, wireless.
Matt has experience bringing products to market and knows what it takes to manage the supply chain for a hardware build like this. He's spent most of his career at smaller companies, and so he's had to cover a variety of roles, including working directly with vendors to supply and manufacture products.
The MotoBox is an opportunity for Matt to apply a decade worth of product development experience. He's excited to create a product that will allow him to share his accumulated knowledge of OBD-II.
We have designed and built our alpha prototype MotoBox. This is a custom board with most of the functionality that will be required in the final design, which has been designed to fit into an off-the-shelf enclosure. Collected data on the alpha prototype is accessed via USB. These prototypes were built up from bare boards by us at BlueMoto Labs.
This video shows our alpha prototype in action:
And here are some pictures:
Now that the alpha prototypes are up and running, we're in the process of developing our next revision of the hardware -- the beta prototype. These will be very similar to the alphas, and the changes will mostly be minor updates to the board. The only significant addition will be to add WiFi support. This will be done with an off-the-shelf module, so the hardware impact will not be complicated.
Once the beta prototypes are proven, this hardware will be used in the MotoBoxes which are delivered.
We have also constructed an initial prototype of the web application, which we are using to develop our APIs as well as our back-end database and connectivity layers:
As you can see from the video, we now have the ability to store vehicle info to our database and chart the data by vehicle and parameter. There is still a significant amount of work to be done before we’ll consider this complete -- we want to add the ability to view and understand diagnostic trouble codes and also to create different kinds of reports based on date ranges that the user provides. We’ll continue to add functionality as time goes on and we’re definitely open to suggestions on how we can make the tool more useful.
Once the hardware design is finalized, we'll begin manufacturing MotoBoxes at quantity for delivery.
All of our parts should be readily available from a variety of vendors. We will buy enough parts to build at least as many boards as we'll need to ship, including extra parts where necessary. Building many boards at once will allow us to buy parts at discounted quantity pricing, keeping costs down.
Printed Circuit Board Manufacture
We'll have our circuit boards manufactured by a "board house." They'll send us a pile of bare circuit boards, ready to be "stuffed" with all of our parts.
Printed Circuit Board Assembly
Board assembly -- putting the parts on the board, i.e. "stuffing" the boards -- will be done at a dedicated board assembler. We'll select this assembler based on the quantity of boards that we'll need to produce. We'll send them our circuit boards and parts (along with your money) and they'll send us back assembled boards.
To complete assembly of the MotoBox, the OBD-II cable must be assembled, the cable must be attached to the board and the board must be mounted in the enclosure. This will be done in-house at BlueMoto Labs.
The processor on each board in each MotoBox needs to be programmed with firmware. This is a relatively simple procedure which requires just a few seconds per unit. This will be done in-house at BlueMoto Labs.
Before each MotoBox goes out the door, we'll test each of them to ensure that they are working properly. This will be a high-level functional test exercising the key features such as the OBD-II interface and WiFi. This will be done in-house at BlueMoto Labs, and we'll automate this test make it quick.
Currently our plan is designed to handle production of up to around 300 MotoBoxes. Should we need to deliver more MotoBoxes than planned, this would be a great problem to have! Our circuit board production will scale easily, however final assembly, programing and testing would likely need to be done by a third party. We'd need to select a manufacturer to perform those steps.
The MotoBox units that will be shipped are prototypes for engineering and development purposes only. These are not finished products and may not comply with all technical and legal requirements for finished products, such as electromagnetic compatibility or certifications such as FCC, CE or UL. Note that the WiFi module used in the MotoBox prototype will be fully certified. If this initial prototype production run is successful, we'll turn the prototype into a finished product.
Risks and challenges Learn about accountability on Kickstarter
This project presents two separate categories of challenges: hardware and software.
Most of our hardware risks are manufacturing related. For example, it's possible that there may be problems manufacturing the boards. To mitigate this risk, we'll use reputable vendors, electrically and functionally test our boards and plan for some manufacturing defects. Additionally, any time you use a wireless interface its possible to run into problems. We'll use a certified, off-the-shelf WiFi module to reduce the probability that these may occur.
On the software side, the risk is that we'll hit major bugs that will delay web application and API releases. To mitigate this risk we're implementing a well-defined iterative software development process, and are ensuring that we have places where we can incorporate services that will speed up the development process if that becomes necessary.
The MotoBox has a developer-facing API which provides a platform for custom software development.
The MotoBox connects to the internet via WiFi, removing the need for a cell phone with a data plan.
The MotoBox uploads its data automatically, without any user interaction required.
The developer API is built to scale, providing a single developer access to data from potentially thousands of vehicles.
Yes. The way the MotoBox is designed requires data to be accessed through our servers, which means that the MotoBox API (non-persistent) and MotoServer API (persistent) will both require a developer subscription. These will be very low-cost.
No. Data is logged by the MotoBox while the vehicle is in use and uploaded via WiFi only when it returns to a configured WiFi access point.
The MotoBox targets a particular use case which is not yet served in the market. There are many other devices that already provide real time vehicle data, typically over bluetooth to a mobile phone app, requiring user interaction with the phone to view the data. The MotoBox is not intended to compete with these systems.
The MotoBox is designed to provide an extremely simple user experience. It works in the background, continuously collecting data and automatically uploading it. There is no user interaction in the vehicle itself -- all user interaction is through internet-connected software applications.
These applications have access to all current and historical vehicle data as well as data from any other vehicles managed by the application. We believe that providing an easy way for application developers to get access to this quantity of vehicle data is a novel approach and will allow for the development of powerful, data-driven apps.
WiFi is ubiquitous. Most users will already have a WiFi access point, meaning there will be no other infrastructure or costs required to get started using the system. A cellular modem interface could provide real time data, but would require costly service plans for each vehicle. A bluetooth interface would require some other device, i.e. a mobile phone with its own service plan, as well as some phone application to upload data.