Boat Control: Realisation

Realisation

The realisation of the software started at figuring out how to get bluetooth low energy to connect to, and communicate with Android devices. It took me a few weeks to fully understand how to achieve this. As it turns out there is a big difference between regular Bluetooth and Bluetooth low energy. They require two completely separate libraries to be controlled. So, after numerous attempts to built my own solution to connect to bluetooth devices in the form of proof of concepts, I decided to use Google's own example project "BluetoothLEGatt" as the foundation for my app. This worked out quite well, I was able to quickly understand to inner workings of the example and adapt it to my needs.

I managed to automatically connect the app with the HM_10 module. Once this was done the user is brought to the main boat overview screen. On this screen they can see the status of various sensors on the boat and they'd also be able to acces the control panel to turn on/off certain features of the boat such as: water pump, lights, GPS, Bluetooth, WiFi, ect.

After this I made a system to synchronise the state of the physical control panel to the state of the digital one. I used an observer pattern for this and callback from the HM_10 module to the phone.

The same strategy was used to read out sensor data from the HM_10 as well. I request a list of available sensors from the module and then ask for their status one by one. This is all being done on a separate thread so that it doesn't mess with the UI.

Now for some issues...

While developing for the HM_10 bluetooth module I ran into some strange issues. I started noticing that sometimes when I send a command to the bluetooth module it wouldn't return anything back to me. I had assumed that it was a problem with the code I wrote since I was relatively new to the bluetooth scene but as I started looking into it I realised that it was actually the fault of the bluetooth module itself.

Communication between the bluetooth module and the phone works through a serial port. The byte data that gets sent needs to stay in a certain sequence for it to make sense to the controller on the other side. If even one of the bytes shifts, the whole message falls apart. So what ended up happening was when I send too many commands in one go, some of the commands would intertwine and make this weird command popup in the serial monitor readout. As a result, the HM_10 module wouldn't know what to do with it and doesn't send anything back.

Another issue I had was that the bluetooth module would always morph the fist command I send so some weird ASCII code. It took me a while to figure out why this was and I found two possible answers:

The module still has some data left in its buffer so it adds the first command it's sent to the buffer and prints it out, messing up the command.
It's in sleep mode (because it's low energy bluetooth) until it gets it's first command which it uses to wake up, it doesn't receive the full command because of this

I have added some images to accompany these problems, it's a readout of the serial monitor showing the messed up commands. Namely it receiving:

"j⸮e⸮⸮TDEPTH" instead of "ST+GETDEPTH"
"SET+GEVWIND" instead of "ST+GETWIND".

As a fix for this I make sure that I have failsafes in my code for when a command doesn't go through. The status of a button will only be updates once the panel returns to me that the button has changed state (on callback). And for every sensor I read out I make sure that it has a timeout of about half a second so that stuck threads don't start piling up for no reason and clog up memory.

Page updated

Google Sites

Report abuse