BLE NUS service

[Jed Marti]

We're having trouble reading more than 2 bytes from BLE NUS.  SDK 16. Software based in ble_app_uart but running custom board (no buttons, no LED), this is a ble peripheral.

SEGGER embedded studio, JLINK Base programmer, nRF52832 processor.

When more the two bytes are written, the blcm_link_ctx_get call inside on_write in ble_nus.c fails (does not return). Two byte writes from central succeed but do not raise the BLE_NUS_EVT_RX_DATA event type though with fiddling of \r and \n in two bytes we do get BLE_NUS_EVT_COMM_STARTED and BLE_NUS_EVT_COMM_STOPPED events.

[Vidar Berg]

Hello,

It looks like your GATT client is using the wrong attribute handle for some reason. It should only access the 2 byte CCCD handle when it wants to enable or disable notifications on the NUS TX characteristic. To generate the BLE_NUS_EVT_RX_DATA event it needs write to the p_nus->rx_handles.value_handle. Is your client doing service discovery on connection, or does it rely on existing hardcoded attribute handles?

Note that you can test the Service with our nRF connect app on Android or iOS as well.

[Jed Marti]

I'm using Light Blue as the client on an iPAD and just sending random values for the first two bytes.Sending only two bytes of  /r/n or \n\r gets its attention but I only get STOP and START events.  I'm using read/write characteristic 1. I'm unable to get nRFconnect to behave - when I try to send messages it just blinks the message text and doesn't do anything.

[Vidar Berg]

It is writing to the wrong handle, and it's likely related to attribute caching. Attribute caching is a feature defined by the BT spec. that allows GATT clients to store the attribute table (i.e. layout of services and characteristics) of "known" device across connections, and thus removing the overhead of having to repeat service discovery on subsequent connections. You may take a look at core spec 5. vol3, part g, section 2.5.2 for more details. It gives a good summary of the feature and how it's used. 

The problem with caching arises when the same device is updated with a different attribute table and thus invalidates the existing cache on the client side. It isn't uncommon for this to happen during development and having the client accessing the wrong characteristics as a result.  The solution for this is to make a new service discovery. iOS does not expose an API, so it's not possible to do programmatically, but you can force rediscovery by clearing the cache. The cache can be removed by first making sure your device is not in the "MY DEVICES" list in Bluetooth settings, followed by a reboot. Please try either that or try connecting with another device. 

[Jed Marti]

Tried it with another device and yes that's the problem. Dave P. and I fiddled with this for hours. Now to figure out how to reset the iOS device (not really a fan of it).

[Vidar Berg]

Good to hear that it works now.

Jed Marti said:

Now to figure out how to reset the iOS device (not really a fan of it).

 Reboot/restart the iPad, not reset it.