Bluetooth (BLE)

I have been working on some more educational R&D for the last week or so - exploring the possibilities with Bluetooth, specifically BLE.

The application involves four battery operated devices that need to link together.

1. A helmet, with a servo to power a visor up and down, and LEDs for the eyes.
2. A left glove with a disc of LEDs in the palm (I believe called a "repulser").
3. A right glove, the same.
4. A suit with speakers and a large ring of bright LEDs (I believe called an "arc reactor").

Why linked together?

Each works independently, and each has a button to trigger working. The repulser will quickly fade up to a bright light then go off. The helmet goes up or down.

The ideas is that when you activate the repulser, a synchronised sound effect of an increasing sound and a whoosh and crash happens at the same time. Similarly when the visor closes there is a synchronised clunk as it finished closing. A few other synchronised novelty effects have been added as well.

How to link them together?

The obvious, and low power, way to link would be cables, plugs and sockets. But this would be hugely inconvenient for the weather.

So - Bluetooth, specifically low energy BLE.

Daunting task

This was indeed a daunting task. I have done a little with BLE, just passively scanning advertisements to pick up and decode advertisements from temperature sensors. This would need a lot more.

But I went for it, and, well, it took a day!

Basic example code

I used the basic security gatt example - and to my amazement it worked. Minor bug and slight tweak, but very quickly I had a "heart rate monitor" server, and there clients connected. I then succeeded in having clients change the heart rate monitor location (text) which I used to tell the suit what sound to play.

Moving on

I tried to adjust the GATT fields, and failed. I need to read up more and understand how to do this, and add device information perhaps. Then consider making custom service codes - after all, calling an arc reactor a "heart monitor" is perhaps a stretch.

I need to properly understand the example code in the process, and prune it down.

I've also applied for a Bluetooth manufacturer code.

Bluetooth Low Energy DEFCON

I have been meaning to get my head around Bluetooth for some time, and I think I have finally come up with a project idea which is a bit whacky, but I think should work.

I have discovered that Bluetooth Low Energy (BLE) is different from full bluetooth, something I had not realised, but that BLE should do what I want. The little ESP32 chips with which I am very familiar can do BLE, so this should be simple (LOL).

So here is the idea - DEFCON box. I have one of these at home :-

The way this works is that it shows a DEFCON level depending on who is in the house, so each of the kids has a level, and the lowest level shows. It beeps and the lights click as the go off and on to change levels. All good fun. We know who is about to open the door just before they do...

However, the way it actually works is quite complex. It works on WiFi and MQTT and is told by an MQTT command what level to show. The command comes from a FireBrick, which uses its profiles to decide what level applies. It does that based on the DHCP leases for people's phones on the WiFi. It is really quick to pick up people arriving, but takes the DHCP lease timeout to realise they have gone. But in spite of this complexity it works.

I did think it would make a fun present for someone, but the complexity of WiFi, MQTT, FireBrick and so on makes it really not simple to set up at all.

So this is where BLE comes in...

The idea is that it would scan for BLE devices and pick up phones being present directly. Of course BLE is designed to not allow you to track people, so needs a bit more, and it needs a simple way to tell it which phones are which DEFCON level.

The idea is a button, you press it, and press it repeatedly to pick a level that will flash. The device would be BLE discoverable so show on a phone, and the phone then connects and bonds with the DEFCON device. It then remembers the phone and the level. Because (I hope) the bonding will have an identity resolution key for the phone, it should be possible to passively scan and work out when each phone is present or not.

This makes for a really simple user interface - one button and bond from a phone.

Of course I may face issues with the libraries. A passive scan to find a device you know may not be possible as normally when found you connect to confirm the device is not a fluke random match (which, for this application I am not really too worried about). I'm also assuming a phone will tell my device a key for this - it may not, or may only if it thinks the device is something it expects to want to request a connection. But even so, I can try, and this should cover quite a lot of BLE learning.

So, watch this space :-)

Update1: Demo code works - but I need to advertise only when adding a phone, and as something an iPhone would want to connect to, this was pair using a BLE app not the main settings menu. And I need to work out scanning. Much to do.

IoT

I have not done much on the IoT for over a week, but being rather ill for a few days has not helped 🤮🤮🤮🤮🤮.

The Brexit clock is getting scary!

My grandson wants to do something with LEDs some time!

The environmental sensors are working well, and I have nice graphs from it... This will probably lead to some fans in the office now.



I am thinking the next IoT thing to look at may be Bluetooth. Any suggestions for how that could be fun?

But yeh, the LEDs for my grandson are going to be a thing soon. Here he is abusing his first LEDs.