Close

Bluetooth Comms

A project log for Hypoglycaemia (low blood sugar) alert system

A compact Bluetooth device that acts as a safety net for sleeping type 1 diabetics, detecting hypoglycaemia and calling for help.

noviriumnovirium 08/21/2014 at 06:270 Comments

A key part of the current system and how it works is the Bluetooth communication between the sensor device and the Android phone. As a mobile device, the power supply is limited by a relatively small battery. When connecting or sending data, the current draw from the Bluetooth module vastly outweighs anything else in the circuit, peaking around 28 mA and averaging closer to 18 mA. To stop this from quickly flattening the battery, the data exchange is instead periodic, and is adjustable from the Android app.

As neither device wants to leave the Bluetooth connection discovery running (this will significantly drain even the larger battery found in a phone), both devices need to be synchronised, so they can reach out and start burning power at around the same time, quickly exchange information, and power down again. The duty cycle of this communication can be very low (data exchange is only a couple of seconds, and the waiting period is often up around 15 minutes), and so loss of synchronisation can be disastrous, as the device needs to keep the Bluetooth turned on for the entire next 15 minutes.

To try and combat this, the current system uses pretty standard acknowledge messages which can be seen in the flowchart...thing, below.

To stop the sleep periods from drifting out of sync, the Android app dynamically controls the sleep period of the sensor device at every data exchange, telling it how long it should wait before waking up again. As well as allowing a means for the user to change the sleep period, this also neatly allows for delays in the process that can occur if the Android phone is being used heavily at the time, delaying the background communication service.

I probably should also point out the large difference in power consumption between simply waiting for a Bluetooth connection, and trying to find one (finding one, called discovery, consumes much more). Accordingly, when the sensor device turns on the Bluetooth module, it simply starts spitting out query message on the USART, even though none will actually get anywhere until the Android app initiates a connection. 

With that, I've only got a couple more pretty diagrams left to talk about, namely the AVR firmware and the Android app structure. If anyone wants more information on an aspect of the system, let me know and I'll write another log about it.

Discussions