Fix up the heart rate example so that it conforms to the Heart Rate Service specification: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=239866
This will let this example work with external clients like exercise equipment and fitness apps.
Changes:
- Advertise the HR service UUID instead of the HRM characteristic UUID.
- Change HRM characteristic to notify only.
- HRM payload needs to be two bytes:
- 1st byte is flags specifying data type and sensor capabilities: this can be set to zero.
- 2nd byte is HR measurement in bpm.
Tested on Raspberry Pi with nRF Connect app and exercise bike. Peripheral shows up as HR monitor and data is interpreted correctly.
Use a new Duration type, which is used throughout the BLE stack for
durations. The resolutions are sometimes different (connection
parameters have half the resolution) but overall it should improve the
ease of use of this type.
This commit also provides a default advertisement interval that is
recommended by Apple (which I think is as good as any recommendation).
This might help to speed up discovery by Apple (and Android?) phones.
There used to be GAP events (connect/disconnect). The main purpose for
these events was to allow applications to re-start advertisement when a
connection was lost - on nrf. Unfortunately things work differently on
Linux, which already has this behavior and for which I haven't yet
implemented these events. Therefore I have removed these events and
instead added code to automatically restart advertisement on connection
loss.
Supporting multiple (incoming) connections as a peripheral would be
useful, but is not currently supported.
Instead of attempting to allocate multiple advertisement instances, only
use one by default. If needed, a NewAdvertisement method could be added
in the future for devices that actually do support multiple
advertisements at a time.
The motivation for this change is fix an inconsistency with the nrf51
(which already had the behavior of DefaultAdvertisement) and the
discovery that nrf52 devices also don't seem to support more than one
advertisement instance, even though their API does allow for multiple
instances. But the primary motivation is that for consistency with
hosted systems, it would be best if the nrf port would automatically
re-enable advertisement when a connection is lost (or made).
While BlueZ does support more than one instance, it is implemented by
simply iterating through the active advertisement instances so could
also be implemented by doing that manually. I haven't checked the
behavior of Windows and MacOS - but as always, the API is not yet stable
and can be changed if needed.
This changes the previous raw advertisement packets to structured
advertisement configuration. That means you can set the local name not
with a raw byte array but with a normal string.
While this departs a bit from the original low-level interface as is
often used on microcontroller BLE stacks, it is certainly easier to use
and better matches higher level APIs that are commonly provided by
general-purpose operating systems. If there is a need for raw BLE
packets (for baremetal systems only), this can easily be added in the
future.
All initialization can be done in the Enable call. This makes the API a
bit simpler and a bit more consistent between Nordic chips and other BLE
interfaces.
This allows setting up a characteristic with many properties but avoids
needing to keep the memory of that around (in Go) when the
characteristic is needed at a later time. Instead, only a handle
(currently 16 bits) is kept around to reference to the characteristic.
deadprogram
Michael Mogenson
Ayke van Laethem