How to handle BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST

[brianreinhold]

For some reason when I try and connect to an Android Pixel 2 Android version 10 I get the above BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST event. I do not really understand it, but I follow the instructions on how to handle the event. I do that and I sometimes manage to get a connection event but nothing further happens. Handling the event (or not) does not change the behavior. This event does not happen on any other Android I have tried (all the others are versions 6 and 7). On those devices, connection and data transfer happen as they should. The same central is running on all the Androids and connects without issue with all the market health devices I have (5 different thermometers) so it is not the central application but I may certainly be an incompatibility between the nRF dongle and the Android Pixel 2 V 10.

The nRF dongle is acting as a Thermometer peripheral and I am using the pc-ble-driver.

[bjorn-spockeli]

Hi Brian, 

Can you capture a on-air trace of the packets sent between the nRF Dongle and the Android Pixel 2 using our nRF Sniffer plugin in Wireshark and a nRF DK? It should give us some more details about whats happening. 

Best regards

Bjørn

[brianreinhold]

I did some further studying of the newest versions of the BT spec and found out what this sequence was all about. The problem I had (at first) was using it in my peripheral (or responding to it). It did not state in the documentation how to populate the parameters depending upon whether you were a peripheral or a central. So it was not clear how the dongle used the information passed to it in the response.

The first attempt I made was to populate the parameters with the values I received in the request. It did not work. But I found a sequence diagram somewhere else and on the peripheral side the values were all populated with null. That DID work.

So in the end, I have gotten it to work, but it would be much more helpful if the documentation were clearer. Why null or what are the possible values etc.

In addition to this came a physical layer request update. I went directly to the sequence diagrams for that and did not bother with the docs. In any case, this solves the operation with the Android 10.

I suppose there is probably a generic 'unsupported command' I can invoke as well though I have not yet investigated how to do that (or if it is even possible). I am sure that existing legacy equipment cannot handle this event and must respond in such a way as the Android 10 does work with legacy devices.

To add: my sniffer cannot capture this event, especially after the data packet size is successfully negotiated. I get the entire transaction (measurement) but the sniffer shows nothing after the connection event. I don't even get a raw data packet unparsed. $2000+ bucks for that thing! Arrg.  I don't have an nrfDK - I am using the dongle from the PC. Making a huge health device test suite for health device gateways.

[bjorn-spockeli]

Yes, the Message Sequence Charts, in your case the Data Length Update Procedure specifically are very useful when debugging issue related to BLE events. We do refer to the relevant message sequence charts in the API documentation, the sd_ble_gap_data_length_update API refers to the Data Length Update Procedure. THe range of allowed values are stated in the Bluetooth Specification. 

brianreinhold said:

To add: my sniffer cannot capture this event, especially after the data packet size is successfully negotiated. I get the entire transaction (measurement) but the sniffer shows nothing after the connection event. I don't even get a raw data packet unparsed. $2000+ bucks for that thing! Arrg.  I don't have an nrfDK - I am using the dongle from the PC. Making a huge health device test suite for health device gateways.

 If you do a lot of development on nRF devices or Bluetooth in general , then I would recommend picking up a nRF52 DK to use with the nRF Sniffer Plugin. Its a very low cost tool, that we use alot for debugging issues like these. 

[brianreinhold]

The only thing I will add is what should be made more clear is how the dongle behaves when using certain values. I don't know what it means to pass in null for those values. Does that mean internal values are used? Why didn't using the values from the central work? They are certainly legal values.

If those values should work, perhaps I did it wrong at the time. In any case, the diagram had null. Do they HAVE to be null and what happened because they were null? These are the kind of things that would have been nice to document in the method.

[bjorn-spockeli]

brianreinhold said:

The only thing I will add is what should be made more clear is how the dongle behaves when using certain values. I don't know what it means to pass in null for those values. Does that mean internal values are used? Why didn't using the values from the central work? They are certainly legal values.

Yes, If you called sd_ble_gap_data_length_update with both p_dl_params and p_dl_limitation as NULL then you will use 251 as the maximum rc and tx octets and you should get a BLE_GAP_EVT_DATA_LENGTH_UPDATE event if the process was successful. Did you get the BLE_GAP_EVT_DATA_LENGTH_UPDATE event? If not then the SD did likly not receive a LL LENGTH respons from the peer. 

brianreinhold said:

If those values should work, perhaps I did it wrong at the time. In any case, the diagram had null. Do they HAVE to be null and what happened because they were null? These are the kind of things that would have been nice to document in the method.

No, you can decide the max number of rx and tx octets yourself as shown in the MSC. If the values are incorrect, then the SD will write the limitation poiner (p_dl_limitation) when local device does not have enough resources or does not support the requested Data Length Update parameters according to the sd_ble_gap_data_length_update documentation.