What are the differences between Notify and Indicate?
The short answer is that they both basically do the same thing, except Indicate requires acknowledgement, while Notify does not. For the longer answer, please read the rest of my post.
By default, you cannot push data to your remote client whenever your Bluetooth low energy (BLE) device has new data to publish. If you read my previous post, you will know that you need to enable the proper permission and include a "Client Characteristic Configuration Descriptor" (CCCD) for that to happen. Not forgetting, your remote client must subscribe to the attribute via the CCCD to receive the pushed data.
Typically, people push data when they want their remote client to asynchronously receive updates whenever their BLE device has new data. While you can perform a periodic polling, the method wouldn't be very energy efficient and you will not get the quickest update (this depends on your polling rate). Also your BLE device might get updates in an aperiodic fashion, so periodic polling is an utter waste of energy. Furthermore, polling requires two-way communication and Notify is one way, so you will save on radio airtime which would lead to further energy reduction. However, because Notify is unacknowledged, it is unreliable since you will not know whether your remote client has received the data.
To rectify that, let me introduce the Indicate feature. It is almost the same as Notify, except it supports acknowledgment. Your remote client will have to send an acknowledgement if it has received the data. However, such reliability comes at the expense of speed since your BLE device will wait for the acknowledgement until it has timed out.
For most use cases, I would recommend you start with Notify until you find out in your test environment that data is dropping out, then you move into Indicate. In any case, Indicate might take up additional airtime, but it shouldn’t drastically affect your use case. If the communication speed of Indicate is bordering your requirement, then perhaps you should be looking at alternative wireless technologies because BLE is not meant for high-speed communication.
To celebrate our 6th anniversary, we designed and trademarked a new logo to celebrate our past successes and symbolise the future of Thesis. At Thesis, we pride ourselves on helping shape our customers’ future. Our work helps our customers extend their technological advantage over the competition and opens up new growth opportunities. To illustrate this, […]
Here we show the waveform of a zero-voltage switching (ZVS) inductive heating circuit and the thermal profile in operation. A typical buck regulator DC-DC is challenging to design when there is a significant voltage difference between the input and the output voltages. A significant voltage difference typically increases switching losses and limits the device’s switching […]
In Thesis, we develop products using various MCUs – Cypress PSoC4/5/6, STM32, Nordic nRF, Arduino, and PIC. In the past, we did that because of various client requirements and/or outcomes from our in-depth engineering evaluation. However, we do it nowadays because we aim to make our product design as MCU agnostic as possible to circumvent […]