Increase characteristic value max length

[Geass77]

Sorry ,I have the problem with increasing the max data length(more then 20 bytes) in the characteristic , I change the att_mtu size like the value in the picture, but after I changed it, I  can't even detect my device name , is there any else I have to do when I change the size?  I'm using sdk 15.3 ,template project.

[bjorn-spockeli]

Hi Geass77,

I change the att_mtu size like the value in the picture, but after I changed it, I  can't even detect my device name ,

DO you mean that the nRF is not advertising after you change the  GATT max MTU size?

Best regards

Bjørn

[Geass77]

Yes,but I fix the problem when I change the register start address, can I ask how to how to calculate the throughput , if my 

time interval is 7.5 ms, and my att_mtu size is 247 byte, my throughput is like 247 /7.5ms ,however, I don't know how many package can I send in one connection interval ,and the number of characteristic is related to throughput or not. 

[bjorn-spockeli]

Im not sure if you will be able to get out two packets if sd_ble_gatts_hvx is called every 3ms. It could be that the SD will end the connection event if there are no data in the queue. So if you update the data and call sd_ble_gatts_hvx right before the start of the connection event and then call sd_ble_gatts_hvx again after 3ms, then the connection event may already be closed. However then you should be see two packets going out on the next connection event if sd_ble_gatts_hvx was called twice before the start of the event. If you are getting NRF_ERROR_RESOURCES when calling sd_ble_gatts_hvx then please see the API doc, quoted below.  

The number of Handle Value Notifications that can be queued is configured by ble_gatts_conn_cfg_t::hvn_tx_queue_size When the queue is full, the function call will return NRF_ERROR_RESOURCES. A BLE_GATTS_EVT_HVN_TX_COMPLETE event will be issued as soon as the transmission of the notification is complete.The application can keep track of the available queue element count for notifications by following the procedure below:

• Store initial queue element count in a variable.
• Decrement the variable, which stores the currently available queue element count, by one when a call to this function returns NRF_SUCCESS.
• Increment the variable, which stores the current available queue element count, by the count variable in BLE_GATTS_EVT_HVN_TX_COMPLETE event.

[Geass77]

So if I can put the package  into queue if I use sd_ble_gatts_hvx , and send the data to client  every connection interval or NRF_SDH_BLE_GAP_EVENT_LENGTH? if  it happened NRF_ERROR_RESOURCES.  it will loose the data , I have tested that  if my  sd_ble_gatts_hvx event is shorter longer than connection interval ,but it will almost always happen when I set the  sd_ble_gatts_hvx event to 1ms?  

In addition ,how can this problem happen?

[bjorn-spockeli]

Ok. Please check if the sd_ble_cfg_set call that passes the NRF_SDH_BLE_GAP_EVENT_LENGTH  to the SD in nrf_sdh_ble_default_cfg_set() does not return an error code. Also check if you end up in the app_error_handler_bare() error handler. 

Regarding your previous comment. If you get the  NRF_ERROR_RESOURCES return code from sd_ble_gatts_hvx , then you need to increase the ble_gatts_conn_cfg_t::hvn_tx_queue_size as stated in the API doc. 

Best regards

Bjørn

[Geass77]

Thank you very much ! Can I ask the last question is that if NRF_ERROR_RESOURCES happens ,the data will be loose or send in next notify, if my NRF_SDH_BLE_GAP_EVENT_LENGTH is same as my connection interval the power consumption will increase?

[bjorn-spockeli]

When you get the NRF_ERROR_RESOURCES return code from sd_ble_gatts_hvx , then the notfication/indication will not be queued and you need to call sd_ble_gatts_hvx() again with the same parameters when you get the BLE_GATTS_EVT_HVN_TX_COMPLETE event.

As stated previously the connection event will be closed if there aren't any more packets in the queue. So if there are only one or two packets in the queue, then those will be sent and the connection event will be closed. It will only remain "open" as long as there are packets to send. So it should not affect the current consumption that much, but this will depend on how many packets you send. 

Best regards

Bjørn

[Geass77]

Thank you!!