• State Verified Answer
  • Replies 4 replies
  • Subscribers 87 subscribers
  • Views 946 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 259914
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Disable TX notifications

Simon

Hello,

the peripheral (nRF52) bonds to a central (Android nRF Connect), central enables TX notifications, and the peripheral sends over 80 bytes by NUS.

If the central does not disable TX notifications and lets disconnect occur, and because the devices were bonded, TX notification on the central will already be enabled on the next connection. If the peripheral tries another ble_nus_data_send() a NRF_ERROR_INVALID_STATE is returned. (Not looking to have the peripheral send data automatically on subsequent connections).

Is the standard procedure to have the central disable TX notifications before disconnecting, or for the peripheral upon reaching BLE_GATTS_HVN_TX_COMPLETE to some way disable TX notifications, or some way let the central know that there is no more?

thank-you,

Parents
  • 0

    Hi

    Correct, the central will remember the settings of a paired connection and "automagically" keep the same settings for the next time the peripheral connects, so you will have to disable the TX notifications when you disconnect if you don't want to have notifications enabled upon the next connections. When disabling the notifications, the queue will be emptied before the transmissions are stopped, however the application won't be able to place new notifications in the queue after notifications are disabled by the peer.

    Typically, notifications are enabled on the initial connection, and then enabled for the remainder of the devices life time. This allows the peripheral to send notifications as it sees fit to the central device. If you want to control the amount of data received on the central device, it's more common to add a characteristic that the central can write commands to. This may be a command to tell the peripheral device to send X amount of notifications and then stop.

    If you enable and disable notifications dynamically, you'll quickly end up in race conditions between buffering of notifications on lower levels in the stack.

    Best regards,

    Simon

Reply
  • 0

    Hi

    Correct, the central will remember the settings of a paired connection and "automagically" keep the same settings for the next time the peripheral connects, so you will have to disable the TX notifications when you disconnect if you don't want to have notifications enabled upon the next connections. When disabling the notifications, the queue will be emptied before the transmissions are stopped, however the application won't be able to place new notifications in the queue after notifications are disabled by the peer.

    Typically, notifications are enabled on the initial connection, and then enabled for the remainder of the devices life time. This allows the peripheral to send notifications as it sees fit to the central device. If you want to control the amount of data received on the central device, it's more common to add a characteristic that the central can write commands to. This may be a command to tell the peripheral device to send X amount of notifications and then stop.

    If you enable and disable notifications dynamically, you'll quickly end up in race conditions between buffering of notifications on lower levels in the stack.

    Best regards,

    Simon

Children
Related
Terms of service