Audio-feedback Speedometer

Should cars use sound instead of a dashboard?

Speedometer checks take attention away from the road. Audio could communicate the current speed without the driver needing to check the dashboard. It seems reasonable that, with audio feedback, a driver should spend less time looking away from the road.

I put this to the test and it turns out that, no, audio is distracting and annoying.

PLX Devices Kiwi2 Bluetooth ODB-II Interface

To prototype the idea, I purchased a Kiwi2 Bluetooth adapter made by PLX Devices. The device plugs into the On-board Diagnostics (“OBD-II”) socket found in virtually all cars made since 1996. The OBD-II standard is designed for technicians to check engine trouble codes as well as retrieve real-time engine performance data.

Apps for the Kiwi2

The Kiwi2 Bluetooth device bridges the ODB-II interface to bluetooth. It implements the Bluetooth Serial Port Profile (SPP). Details of the serial protocol are available on the PLX website (see the “Software Development” tab).

Several apps in the Android Play and Apple iPhone App stores use this interface. The apps provide enhanced dashboards and diagnostics. None provide audio feedback.

An Audio Feedback App

I created a simple Android app to test the idea on my phone. Android has a Bluetooth API and an Audio API. The rough design of the app was as follows:

  1. Connect to the Kiwi2 using Bluetooth.
  2. Every 500ms poll, the current vehicle speed.
  3. On a separate thread, convert the speed to tones in an audio buffer.
  4. Pass that buffer to the phone’s audio player.

Audio Feedback “Protocol”

In Australia, all speed limits are multiples of ten. I designed the system to provide feedback about the current speed in relation to the nearest multiple of ten.

In addition, it uses two other rules:

Audio Generation

I generated and mixed these tones in real time using a 32 bit arithmetic and an 8 bit sine look-up table. The 8 bit look-up table was intended only to be a first test of feasibility. I had planned to improve the audio quality later. However, the rounding errors gave the tones a pleasing ‘woodwind’ effect so I kept the low quality.

You can listen to an MP3 file playing a test sequence. I admit that it may be difficult to follow without context. It is easier to understand when driving.

Evaluation

I couldn’t find any law prohibiting such devices.

I first tested it off the road and then in quiet streets. It worked perfectly. I did notice that the speed reported by the OBD-II was 7% slower than that reported by dashboard! Perhaps the car manufacturer errs on the side of caution.

I then tried it in real traffic.

It was actually helpful. I didn’t need to look at the dashboard. I could keep my eyes on the road all the time. However, the help came at a significant cost. The audio communication does not adapt to the traffic conditions: it keeps playing during difficult manoeuvres. More seriously, I felt that the audio communication significantly adds to the ‘cognitive load’ while driving.

Even though my eyes were always on the road, the complexity of the audio meant that my mind was occupied. I felt that I had reduced awareness. I felt that I wasn’t as aware of my surroundings.

I gave the system a few more days of testing. I did feel that I did partially adapt: the ‘cognitive load’ partly reduced as I got used to the audio. However, the distraction remained and I felt less safe. I stopped.

Conclusion

I don’t think sounds should be used instead of a dashboard: audio is annoying and distracting.

The idea could be made to work with map and GPS data. I’m sure it would work if it remained quiet at all times except when the driver exceeds the speed limit. Without access to quality mapping and speed limit data, developing such a system would be a major undertaking.

Sample Code

Having just highlighted the dangers of the idea, I’m not comfortable publishing the code.

However, the code to connect to Bluetooth and Audio APIs may be helpful for other projects.

The following code connects to the Kiwi2:

BluetoothAdapter adapter = BluetoothAdapter.getDefaultAdapter();
if (adapter != null && adapter.isEnabled()) {
   adapter.cancelDiscovery();
   Set<BluetoothDevice> devices = adapter.getBondedDevices();
   BluetoothDevice kiwi = null;
   for (BluetoothDevice device : devices)
      if (device.getName().toLowerCase().contains("kiwi"))
         kiwi = device;

  if (kiwi != null) {
     BluetoothSocket socket = kiwi.createRfcommSocketToServiceRecord(BT_SPP);

     .....

  }
}

To generate the sound, I used 8-bit 16kHz Mono audio. This is low quality but sufficient for the experiment. The following code writes a byte[] of unsigned audio into the audio output buffer.

AudioTrack audioTrack = new AudioTrack(
   AudioManager.STREAM_MUSIC,
   16000, // sample rate
   AudioFormat.CHANNEL_OUT_MONO, 
   AudioFormat.ENCODING_PCM_8BIT, 
   16000, // internal buffer size (i.e., 1sec)
   AudioTrack.MODE_STREAM
);
audioTrack.play(); // starts the stream

byte[] buffer = new byte[16000 / 2];
while (.....) {
   .....
   audioTrack.write(buffer, 0, buffer.length);
}

Note that buffer is only half the size of the AudioTrack’s internal buffer. This is to ensure continuous, smooth playback. It generates a half-second of audio while the AudioTrack plays the other half-second.

Published 2 February 2014 by Benjamin Johnston.