Use NUS Service on bonded devices without discovery

RE: Use NUS Service on bonded devices without discovery

BjoernSchmitz — Thu, 23 Apr 2020 05:37:32 GMT

Ok, thanks. I will try that.

RE: Use NUS Service on bonded devices without discovery

Simonr — Wed, 22 Apr 2020 13:42:02 GMT

Thank you for your clarification Björn!

The reason the MTU negotiation is initialized upon connection is that the ble_conn_params.c file starts this negotiation for you upon a connected event. In order to skip/avoid the MTU negotiation, you can remove the ble_conn_params.c file from your project. Keep in mind that there are some other functions in this file as well that you'll miss out on.

Best regards,

Simon

RE: Use NUS Service on bonded devices without discovery

BjoernSchmitz — Tue, 21 Apr 2020 14:35:29 GMT

Tanks, but I already know this Blog Post and it really helped me back then, when I searched for it. However, throughput is not the Issue here. I measured Latency from peripheral to host as about one Connection Interval, which is set to 7,5 ms. This is as good as it can get, according to Bluetooth Spec.

What I am trying, is to minimize the delay from start of advertising, till receiving the first application data package on the central. My problem is that when I set NRF_SDH_BLE_GAP_EVENT_LENGTH to something different from 23, my packets are blocked until the MTU size is negotiated between Host and peripheral (NRF_BLE_GATT_EVT_ATT_MTU_UPDATED received).

I understand why this is happening, what I would like to know is if it is possible to directly start a connection with a higher MTU size then 23, when the peripheral has been bonded before. Thus, I could skip negotiating the maximum MTU size between Peripheral and Central and could directly start sending application data.

Best regards,

Björn

RE: Use NUS Service on bonded devices without discovery

Simonr — Thu, 16 Apr 2020 12:21:36 GMT

That NRF_SDH_BLE_GAP_EVENT_LENGTH should be sufficient. Did you take a look at the blog post I linked to in order to see how to best increase the throughput? I'm having some trouble seeing what exactly is causing this. Are you able to upload a sniffer trace for me to take a look?

Best regards,

Simon

RE: Use NUS Service on bonded devices without discovery

BjoernSchmitz — Thu, 16 Apr 2020 05:34:37 GMT

Yes, NRF_SDH_BLE_GATT_MAX_MTU_SIZE in file sdk_config.h is set to 247 for both devices, so I expect that these values are used by default. And this seems to be correct, since I receive the NRF_BLE_GATT_EVT_ATT_MTU_UPDATED event without asking for changing the MTU size from my application.

NRF_SDH_BLE_GAP_EVENT_LENGTH is set to 320 on both device. Is this correct, or would you suggest a higher value? I tried to enlarge this value but this did not have any effect.

RE: Use NUS Service on bonded devices without discovery

Simonr — Wed, 15 Apr 2020 09:54:47 GMT

Yes, I did. Very sorry about that. I have updated my previous reply to include the link to the blog post I mentioned now.

Is the MTU size set to 247 in both devices by default? You might have to increase the NRF_SDH_BLE_GAP_EVENT_LENGTH for the devices to have enough time to transfer packets with an MTU size of 247, what is this set to in your application?

Best regards,

Simon

RE: Use NUS Service on bonded devices without discovery

BjoernSchmitz — Tue, 14 Apr 2020 13:56:02 GMT

Hi, did you forget to add a link to your comment?

I finally found the problem. I still don't know exactly how to fix this, though. It seems that sending data is blocked by an ongoing ATT_MTU exchange. I attached the trace log from my peripheral device:

devzone.nordicsemi.com/.../logTrace.txt

What I do, is starting to send data as soon as I receive the BLE_NUS_EVT_COMM_STARTED event from the NUS module. Data is sent in 20 ms Interval.

I would expect to receive a BLE_NUS_EVT_TX_RDY event right after sending that first data package. However, this event is received more than 100 ms after my first attempt to send data. I also logged the answer I receive from ble_nus_data_send. The function always returns 8, which is "NRF_ERROR_INVALID_STATE", for my firsts attempts.

It seems that shortly after receiving the GATT event NRF_BLE_GATT_EVT_ATT_MTU_UPDATED, ble_nus_data_send returns 0 and data is transferred.

I looked deeper in the code of ble_nus_data_send and I can say for sure, that the following if statement never evaluates to true.

    if (!p_client->is_notification_enabled)
    {
        return NRF_ERROR_INVALID_STATE;
    }

Thus, "return NRF_ERROR_INVALID_STATE" is skipped from the first time, I call the function. Instead, sd_ble_gatts_hvx, which is called at the end of ble_nus_data_send, seems to return the error code 8. I looked to the API reference of sd_ble_gatts_hvx, which may return NRF_ERROR_INVALID_STATE, if "An ATT_MTU exchange is ongoing".

To make sure that this really is the problem, I did set NRF_SDH_BLE_GATT_MAX_MTU_SIZE to the default value of 23 on peripheral and central side. Before it was 247. This did speed up the connection process massively. Now ble_nus_data_send directly returns 0 after the characteristic has been notified, and I do not receive "NRF_BLE_GATT_EVT_ATT_MTU_UPDATED" anymore. I can now connect, encrypt and send data from peripheral to host within about 70 to 80 ms. This would satisfy my needs in theory but skipping the MTU update is not really an option, since I want to maximize throughput, which is hard with an MTU size of 23. Is there a way store the MTU size for bonded devices, so that both devices do not need to negotiate the MTU size on each connection?

Best regards

Björn

RE: Use NUS Service on bonded devices without discovery

Simonr — Tue, 14 Apr 2020 08:58:11 GMT

In order to maximize throughput for your application, I suggest you check out this blog post, which is very thorough on throughput. Please check out that to see if you have missed anything there. Next, I'm not able to say what is causing this delay with the information you've provided. Are you able to capture a sniffer trace so we can see what event causes this delay?

Best regards,

Simon

RE: Use NUS Service on bonded devices without discovery

BjoernSchmitz — Wed, 08 Apr 2020 14:34:49 GMT

Hi Simon,

thanks for the quick response. This helps a lot. My solution is to store handles, when bonding the devices, and reusing this handles for all later connections. And this actually does speed up the connection process, since I can skip discovery. It doesn't help as much as I hoped it would, though.

Currently, I can establish a connection within less than 50 ms after advertising was started on peripheral side. Since I reuse the handles, and both devices are bonded (thus pairing process should also be skipped), I would expect the device to directly be able to communicate via NUS. However, even though I start transmitting value notifications from the peripheral side, as soon as the connection is established, it takes another 100 ms (more or less) until the first notification reaches the central. It seems that the notifications are queued somewhere. Then 100 ms after the connection was established, I receive all notifications, which I did send in the meantime.

Do you have an idea how to speed that up, or what could cause the initial delay? Min and max connection interval are already at 7.5 ms, so that shouldn't be the problem. After the initial delay, latency from peripheral to central side is constantly below 20 ms. So this problem seems to exist only directly after connecting.

My aim is to transmit data from peripheral to central side, via NUS value notifications, within 100 ms (counted from start of advertising to the reception of the value notification in the NUS event handler on central side). Do you think that is possible? Currently, I managed to transfer data within 150 ms, so I need a way to save at least another 50 ms, within the connection process.

Best regards

Bjoern

RE: Use NUS Service on bonded devices without discovery

Simonr — Wed, 08 Apr 2020 11:37:21 GMT

Hi Bjoern

This has been discussed in length in this thread, even though it is rather old it should still be relevant. It should be fairly simple, seeing as if you know the handles you can just utilize these directly. It might be that some SDK functions are tied together and make some trouble, but I think you should be fine if you remove the discovery module from your project altogether.

Best regards,

Simon