Back to project homepage

NOTE: This protocol is to be implemented and is not currently implemented in the source

Protocol Version : 1.0

Dash protocol. This document describes the data link protocol between the can to bluetooth module (or any other data stream creator) and the Android Tablet bluetooth.

The bluetooth profile used will be SPP (Serial Port Profile) to provide a simple means of data communication between the data generator (cantobt) and the data consumer (Android Tablet). The data will be packetised in such a way so as the Android tablet can connect to the bluetooth data link at any time and synchronise with the data packets easily.

Although the link is over bluetooth, both bluetooth devices must have matching COMs parameters in order to work properly. So the following parameters must be used by both devices to establish the bluetooth SPP link:

  • Baud Rate: 56,000
  • Data Bits: 8
  • Stop Bits: 1
  • Parity: None

The protocol will be ASCII, enabling the use of a non-printable character to delimit the data records. The protocol should be easily extensible, and easily encoded and decoded.

The Dash software is running in a Dalvik VM, there is no hope of anything like real-time operation, so any specific timing cannot be incorporated into the protocol. Instead, simple ASCII will format the entire packet.

A type associated, comma-seperated list of values suits the needs.

This requires us to produce packets which start with some ASCII character (referred to in this documentation as <start>), followed by type-associated records that are comma-delimited. This is all that is actually required, but a packet termination character (referred to in this documentation as <end>) will also help packet synchronisation.

Type-association means that we will tag a data value with an ENUM value which describes what the data value means. For example, in C, we might have a the following ENUM declaration for data types:

typedef data_type_t enum {
RPM = 0,

Now our packet could look like the following:




Both packets will give us the same result, there is no dependancy on the data value order because they are data values are type associated.

This also helps us reduce bandwidth usage, and increase efficieny. If we chose to fix a packet to include a fixed set of data values in a particular order, we could decode easily – but we would have to send all data in every packet. This is undesireable for some data values. Data values such as battery voltage do not need to be updated as regular as say engine RPM.

We must decide on <start> and <end> characters, and define a list of data types (don’t confuse this with programming language data types – this is for data value association, this implicitly tells us what format the data value is in anyway), and we must define some units for the data value types.

<start> character – The start character shall be ASCII ‘!’ (Exclamation mark)

<end> character – The <end> character shall be ASCII ‘x\D’ (Carriage Return)

<sep> character – The <sep> character shall be ASCII ‘-‘ (Heiphen)

<type> and <value> – Numerical Values

Numerical values shall be in Big Endian format, ascii encoded hex. For example, given the enum previously mentioned and again an RPM of 1024 (0x400), and a road speed of 60mph (0x3C) we get the following values in the packet:

0400 003C

Note: preceding zeros is entirely optional as they serve little purpose except to increase readability with an increase in bandwidth. The following would also be entirely acceptable:

400 3C

Positive or negative signs must NOT be used to signify the polarity of the data. Only ascii-encoded hexidecimal values can be used in numerical values.

Furthermore <type> shall only include values from the data type enum and <value> will only include valid values for the data type associated with it.

The complete protocol layout is:

<start><type><sep><value>,<type><sep><value>, ... <end>

Therefore an example packet of RPM = 1024, and ROAD_SPEED = 60 becomes:


DON’T FORGET that the <end> character is a carriage return at the end of that string!

Leave a Reply