Explaining the BLE architecture to myself was actually helpful. I worked through the code more carefully and discovered that I didn’t quite appreciate that services, and characteristics all use the same 128 bit base address. I guess that all makes sense because it’s important for listeners to be able to reject radio messages that are not from a service they care about.
So here’s the physical setup: The TS06 is playing the part of the wearable. The Nordic eval board is playing the part of the gateway to the cloud.
The black blob on the end of two black wires is a button I deftly soldered onto the TS06 board. (Exquisite huh?) It is the “sensor”.
The demo has three phases: discovery, connection, and data transfer.
- Phase 1: The TS board starts off scanning for a gateway. It has LED_0 illuminated while it is scanning.
- Phase 2: It discovers the gateway and tries to connect. If successful it turns off LED_0 and turns on LED_1. Now it is ready to transfer sensor data up to the cloud.
- Phase 3: Each time I press the button the TS06 generates a “button-down” or “button-up” event, and sends it up to the cloud.
- When the cloud receives the event it logs it.
- Then is sends an “led-on” or “led-off” event back to the TS06.
- The TS06 receives the event and does the obvious thing.
The latency is awful.