S132: Is it possible to send an empty notification

[jcormier]

My previous product uses an empty notification to indicate that a bulk transfer is finished. I attempted to send an empty notification but got error code 0x10 (NRF_ERROR_INVALID_FLAGS).

Is there a way to send an empty notification?

ble_gatts_hvx_params_t hvx_param =
{
    .type   = BLE_GATT_HVX_NOTIFICATION,
    .handle = p_ctx->bulkdata_handle,
    .p_data = data,
    .p_len  = &len,
};
hvx_param.p_len = 0;
err_code = sd_ble_gatts_hvx(p_ctx->conn_handle, &hvx_param);

[Edit]

No empty packet sent when p_data = NULL and p_len = 0.

Example of an empty notification packet being sent by TI CC2540.

[Edit 2]

Alright. Added print on TX_COMPLETE.

Heres the log at the end of the transfer. Its hard to tell if one of these completes correlates to the empty notification.

BULKDATA:INFO:on_tx_complete: 503
BULKDATA:INFO:on_tx_complete: 504
APP:INFO:Sent 10 KBytes
BULKDATA:INFO:on_tx_complete: 505
BULKDATA:INFO:Sent empty packet, error code: 0x0
APP:INFO:Finished.
BULKDATA:INFO:on_tx_complete: 506
BULKDATA:INFO:on_tx_complete: 507
BULKDATA:INFO:on_tx_complete: 508
BULKDATA:INFO:on_tx_complete: 509
BULKDATA:INFO:on_tx_complete: 510
BULKDATA:INFO:on_tx_complete: 511
BULKDATA:INFO:on_tx_complete: 512
BULKDATA:INFO:on_tx_complete: 513

I rebuilt without sending the empty packet and there does appear to be one less "on_tx_complete" after the Finished printout.

BULKDATA:INFO:on_tx_complete: 503
BULKDATA:INFO:on_tx_complete: 504
APP:INFO:Sent 10 KBytes
BULKDATA:INFO:on_tx_complete: 505
APP:INFO:Finished.
BULKDATA:INFO:on_tx_complete: 506
BULKDATA:INFO:on_tx_complete: 507
BULKDATA:INFO:on_tx_complete: 508
BULKDATA:INFO:on_tx_complete: 509
BULKDATA:INFO:on_tx_complete: 510
BULKDATA:INFO:on_tx_complete: 511
BULKDATA:INFO:on_tx_complete: 512

Next I modified the code to send only empty notifications. This is where things get weird. It appears that each notification is 9 bytes of 0xFF. 9 bytes happens to be the initial length of the characteristic however the characteristic is initialized to all zeros.

Char init code, generated by BDS:

ble_app_app_generic_data_rcv_t app_generic_data_rcv_initial_value = p_app_init->ble_app_app_generic_data_rcv_initial_value; 

ble_add_char_params_t add_app_generic_data_rcv_params;
memset(&add_app_generic_data_rcv_params, 0, sizeof(add_app_generic_data_rcv_params));

add_app_generic_data_rcv_params.uuid                = 0xFF25;
add_app_generic_data_rcv_params.uuid_type           = ble_uuid.type; 
add_app_generic_data_rcv_params.max_len             = NRF_BLE_GATT_MAX_MTU_SIZE;
add_app_generic_data_rcv_params.init_len            = app_generic_data_rcv_encode(&app_generic_data_rcv_initial_value, app_generic_data_rcv_encoded_value);
add_app_generic_data_rcv_params.p_init_value        = app_generic_data_rcv_encoded_value; 
add_app_generic_data_rcv_params.is_value_user       = 1; 
add_app_generic_data_rcv_params.char_props.notify   = 1; 
add_app_generic_data_rcv_params.char_props.write    = 1; 
add_app_generic_data_rcv_params.write_access        = SEC_OPEN; 
add_app_generic_data_rcv_params.cccd_write_access   = SEC_OPEN;
// 1 for variable length and 0 for fixed length.
add_app_generic_data_rcv_params.is_var_len          = 1;

err_code = characteristic_add(p_app->service_handle, &add_app_generic_data_rcv_params, &(p_app->app_generic_data_rcv_handles));

How did you setup your characteristic?

[Susheel Nuguru]

No, you cannot have p_len == 0 when p_data != NULL. you will get NRF_ERROR_INVALID_ADDR = 0x10 error when hvx_param.p_len = 0;

[endnode]

So it means you are sure there is no ATT MTU sent over LL PDU supported by BLE sniffer? i know that empty Write is definitely triggering GATT Server events on nRF5x with S110 and S13x, I do expect the same for other ATT methods like Notify. On GATT Client side it's a question if empty ATT MTU with given OPcode and handle number will go out, unfortunately I cannot test it now. But if you are testing this scenario please make sure you are watching what happens in radio not somewhere in mobile API or controller.