How to increase notification throughput on nRF52840?

RE: How to increase notification throughput on nRF52840?

LWittland — Fri, 30 Nov 2018 12:08:07 GMT

Hello Edvin,

I finally managed to nail down the problem. It seems that the only thing wrong with my application was that I set BLE_GATT_ATT_MTU_DEFAULT to 247. This seems to produce some undefined/unexpected behaviour of yout BLE stack.

I now have

BLE_GATT_ATT_MTU_DEFAULT 23

NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247

The actual MTU of course is lower than 247 Bytes thanks to the phone on the other side.

Still, I now can accumuate my data and can send one notification instead of ten, which is a tremendous help. Btw, I still use sd_ble_gatts_hvx() for this, I didn't have to use the nus.

Thanks for your help (and patience) in the last weeks!

Best Regards,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Tue, 27 Nov 2018 09:00:50 GMT

Hello Lasse,

I am sorry, but I am starting to loose track of where we are. Your phone supports a higher MTU, and the ble_app_uart example from SDK15.2.0 does as well, so there is something missing from your project that is not allowing it, I think.

Do you have gatt_init as in the ble_app_uart example?

void gatt_init(void)
{
    ret_code_t err_code;

    err_code = nrf_ble_gatt_init(&m_gatt, gatt_evt_handler);
    APP_ERROR_CHECK(err_code);

    err_code = nrf_ble_gatt_att_mtu_periph_set(&m_gatt, NRF_SDH_BLE_GATT_MAX_MTU_SIZE); //247
    APP_ERROR_CHECK(err_code);
}

What is your NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h?

Can you compare your gatt values from the log in the ble_app_uart example and your example?

In both projects, set #define NRF_LOG_DEFAULT_LEVEL 4 in sdk_config.h, and make sure you are looking at the log, and not the uart output in ble_app_uart. You need to check the RTT log.

Try to send a string larger than 20 bytes using the ble_app_uart example. You should see a string longer than 20 *cencored* bytes in the mobile application. Do you see a string longer than this in your example?

RE: How to increase notification throughput on nRF52840?

LWittland — Fri, 23 Nov 2018 14:26:21 GMT

Hi Edvin,

Using nRF Connect I see the same *censored* 20 Bytes I saw with any other application so far.

However, there is something curious: If I use the "Request MTU" command from the Menu besides "SERVER" to increase the MTU to x Bytes, nRF Connect shows x-3 Bytes (the header, I know) of my string. That's great, but...

-The gatt_evt_handler() of my device still says that the nRF Connect requested 0xF7 Bytes regardless of the Value I entered. I have no confirmation that the actual x Value was send to the device.

-Only the first time I use "Request MTU" triggers the gatt_evt_handler(). I have to dis- and reconnect the device for it to trigger the gatt_evt_handler() again.

-If I increase the MTU twice (i.e to 40 and then 60 Bytes) the nRF Connect still only shows 37 Bytes. If I increase and then decrease the MTU (i.e to 40 ant then 30 Bytes) the nRF Connect doesn't show any new notifications (allthoug it will again if i increase the MUT back to 40 or more).

Do you know if this behaviour is a (misunderstood) feature or a bug in the nRF Connect?

I'd love to send you a sniffer log of this, but still, we can't get the sniffer to work.

Best regards,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Thu, 22 Nov 2018 08:12:58 GMT

Ok. But when you try to send one single string of length 80 bytes, or even longer, what is shown in nRF Connect? do you see the entire string?

BR,

Edvin

RE: How to increase notification throughput on nRF52840?

LWittland — Wed, 21 Nov 2018 15:22:41 GMT

Hi Edvin,

we have tried to get the sniffer working on three PC by now, but we had no success. We have followed the instructions as well as the steps in the troubleshooting chapter, but we couldn't find an error. And yes, we tried multiple times.

The screenshot was from the Toolbox, yes. I also have the Connect app, though.

RE: How to increase notification throughput on nRF52840?

Edvin — Tue, 06 Nov 2018 11:41:19 GMT

The nRF Sniffer is a bit buggy if everything isn't correct with the segger versions. Did you remember to flash the sniffer-DK with the firmware for nRF Sniffer?

If it still doesn't show up, try to close it and open it again (Wireshark), and it usually shows up after a few tries. Also remember to reset the DK after programming. Turn it off and on to be sure.

Sorry that this description isn't very good. I usually have to close and open Wireshark a couple of times myself, but because it works eventually, I haven't looked into why it doesn't show up.

You can try to update to the latest version of nRF Connect. Have you tested the nRF Connect app for mobile by the way? It looks ilke your screenshots is from nRF Toolbox, is that correct?

BR,

Edvin

RE: How to increase notification throughput on nRF52840?

LWittland — Tue, 06 Nov 2018 11:04:26 GMT

Hi Edvin,

it doesn't complain. It always returns NRF_SUCCESS.

p_len is 86 Byte (I'm trying a fixed string at the moment), the array is fine.

I can't sniff the BLE connection. I've tried to get the sniffer software running on two different PCs, but each time anything didn't work (usually the sniffer wasn't visible in wiresharks main window).

I willl try a third time.

Best regards,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Mon, 05 Nov 2018 15:28:40 GMT

Ok. So then we know that the phone supports more than MTU = 247 bytes, and it is actually updating to it.

In the part that you have imported from the ble_app_uart example, can you see if you can find out where it complains after 20 bytes? Do you get the return value NRF_SUCCESS (=0) if you try to send more than 20 bytes?

If it does, can you try to set a breakpoint on sd_ble_gatts_hvx() and look at the parameters that you are sending? Is the array larger than 20? Is p_len larger than 20?

Is it possible to do a sniffer log of the connection?

BR,

Edvin

RE: How to increase notification throughput on nRF52840?

LWittland — Mon, 05 Nov 2018 14:16:04 GMT

Hello Edvin,

Your test_app_2.hex' application produced the following output:

<info> app: Connected
<info> nrf_ble_gatt: server_rx_mtu = 247, p_link->att_mtu_desired = 247
<info> app: Data len is set to 0xF4(244)

My application gave me

ATT MTU exchange completed. central 0xf7 peripheral 0xf7

Best regards,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Wed, 31 Oct 2018 16:15:16 GMT

Oh. sorry again. I forgot to mention that the log backend is RTT. Can you check it with the RTT viewer? The same as I used in an earlier reply.

Can you enable RTT logging on your project as well, and then check the RTT output on both applications?

You can find RTT viewer here, if you don't have it already.

BR,

Edvin

RE: How to increase notification throughput on nRF52840?

LWittland — Wed, 31 Oct 2018 13:26:43 GMT

Hi Edvin,

I wasn't able to use the your application with our first tablet (it always lost connection during service discovery), but it worked with the 2nd one.

this is what I got:

The line beginning with "Es ist der Vater" was send from the dev kit to the tablet; more than 20 Bytes received, all fine.

However, when I compile and run the example code, i get the following:

The red error message occured wehin I tried to send data to the device (not good, but not my main concern). The "Er erreicht" line was send from the device to the tablet. it is longer than 20 Bytes, but only the first 20 Byte are shown in the application.

What have you done that I am missing?

Note: In these screenshots I used two different DVK-BL654 boards, but I also tried it on the same board. The results were the same (your App worked, mine not).

RE: How to increase notification throughput on nRF52840?

Edvin — Wed, 31 Oct 2018 10:27:06 GMT

I'm sorry. I forgot. Try this one, then:

devzone.nordicsemi.com/.../test_5F00_app_5F00_2.hex

(this .hex file also includes the softdevice)

RE: How to increase notification throughput on nRF52840?

LWittland — Tue, 30 Oct 2018 16:26:36 GMT

Hello Edvin,

the app doesn't say anything. It seems that it isn't running at all (or at least, it isn't running very long).

I think the problem may be the soft device clock configuration. We are using a DVK-BL654 development kit which doesn't feed the XTAL clock. Since most examples do use the XTAL clock source I think your code does too, in wich case it will stall as soon as the soft device is initialized.

Here are our soft device clock settings:

#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1

Best regards,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Mon, 29 Oct 2018 11:56:34 GMT

Try to program the attached app on your device, and check the RTT log. What does it say?

devzone.nordicsemi.com/.../test_5F00_app.hex

NB:

The app is an application AND the softdevice, so no need to program the softdevice first.

Just use:

"nrfjprog -e && nrfjprog --program test_app.hex && nrfjprog --reset"

Then connect to it with your android devices, and check the log. The app should advertise as Nordic_UART.

BR,

Edvin

RE: How to increase notification throughput on nRF52840?

LWittland — Mon, 29 Oct 2018 10:35:51 GMT

Hello Edvin,

> Do you use the unmodified example, ble_app_uart from SDK15.2.0, or did you pull some parts of it into your application?

I did both, each with at least two different android devices. In neither case the "Data len is set to ..." line was called (only "ATT MTU exchange completed. central 0xF7 peripheral 0xF7").

Regarding the "kill": I didn't want to say that the application ran into a hard fault or similar problems. It runs fine and stable. What I meant was that it is pointless for me to increase the MTU and/or use the nus as long as the 20 byte restriction still is in place (whatever the reason may be).

Sorry for the misunderstanding.

No, I don't have a sniffer trace. I keep trying.

Best regards,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Thu, 25 Oct 2018 07:39:15 GMT

Hello Lasse,

I am a bit confused. Do you use the unmodified example, ble_app_uart from SDK15.2.0, or did you pull some parts of it into your application? The reason that I ask is that the unmodified example should ask for a higher MTU (247), but most phones don't allow this, and typically gives a bit less.

Is it possible to do a sniffer trace of your connection? If possible, the nRF Sniffer would be sufficient.

When you said, a couple of posts ago, "the 20 byte border kills this approach"

Can you try to debug to see what "kills" the application? It is probably an APP_ERROR_CHECK that receives an err_code != NRF_SUCCESS. Can you see where it comes from?

Most likely it is ble_nus_data_send() if that is the only thing you change, but can you also debug to check whether it is the sd_ble_gatts_hvx(), or one of the checks before? And what value does it return?

I tested just now with the unmodified example from SDK15.2.0, and the log output is like this when I connect with an iPhone 8:

I then modified the example to send a dummy array of size 182 with some random numbers whenever the uart handler triggered, and it was sent with the return value NRF_SUCCESS, and I received this array on my phone when notifications were enabled.

Can you check the log output when you run your application. I don't know what your pcb looks like, but if you are able to program the chip, you should be able to view the RTT log using the same application as in the screenshot above.

BR,

Edvin

RE: How to increase notification throughput on nRF52840?

LWittland — Wed, 24 Oct 2018 14:14:53 GMT

Hello Edvin,

the gatt_evt_handler() isn't called.

I've logged the m_ble_nus_max_data_len value prior to a call to ble_nus_data_send(); it was an unchanged 247.

Best redargs,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Tue, 23 Oct 2018 08:24:34 GMT

Hello Lasse,

You are correct. ble_nus_data_send will only use the sd_ble_gatts_hvx() function, in addition to doing some checks first, e.g. that notifications is enabled and that the conn_handle is correct, and so on.

Can you check whether you get the gatt_evt_handler() callback function? If you do, what is the att_mtu_effective from the event?

In the ble_app_uart example, the gatt_evt_handler() looks like this:

void gatt_evt_handler(nrf_ble_gatt_t * p_gatt, nrf_ble_gatt_evt_t const * p_evt)
{
    if ((m_conn_handle == p_evt->conn_handle) && (p_evt->evt_id == NRF_BLE_GATT_EVT_ATT_MTU_UPDATED))
    {
        m_ble_nus_max_data_len = p_evt->params.att_mtu_effective - OPCODE_LENGTH - HANDLE_LENGTH;
        NRF_LOG_INFO("Data len is set to 0x%X(%d)", m_ble_nus_max_data_len, m_ble_nus_max_data_len);
    }
    NRF_LOG_DEBUG("ATT MTU exchange completed. central 0x%x peripheral 0x%x",
                  p_gatt->att_mtu_desired_central,
                  p_gatt->att_mtu_desired_periph);
}

What is the m_ble_nus_max data_len after this call?

You can log it like it is done in this function:

NRF_LOG_INFO("Data len is set to 0x%X(%d)", m_ble_nus_max_data_len, m_ble_nus_max_data_len);

Best regards,

Edvin

RE: How to increase notification throughput on nRF52840?

LWittland — Fri, 19 Oct 2018 12:42:47 GMT

Hi Edvin,

I'm using SDK 15.2.0.

I've tried to integrate the nus from the ble_uart_example into my code. However it didn't work as expected, since the notifications I send were truncated after 20 Byte. This is the same behaviour i got with a normal notification and the sd_ble_gatts_hvx() function. After digging through the nus code, I saw that it essentially boils down to calling the sd_ble_gatts_hvx(), so this is not a big surprise after all.
I may have overlooked something, but at this point I cannot see why I should need the nus - I could as well hand the array in which I accumulated the data to sd_ble_gatts_hvx() directly.

Either way, the 20 byte border kills this approach.

These are the parameters I've used:

#define NRF_SDH_BLE_GAP_DATA_LENGTH 251
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
#define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 14080

After negotiation, the mtu size was still 247 byte.

Any more Ideas?

Best regards,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Thu, 04 Oct 2018 12:48:59 GMT

There is no functionality in the SoftDevice to put together small packets to larger packets, unfortunately. You will have to do this in the application. So you have to collect the data that you want to send in larger packs, before you send them to the softdevice. The limit of the size of the pack is defined by the MTU size of the connection.

I don't know what SDK version you use, but at least in the later SDKs, v15.0.0 and later, the ble_app_uart example is initialized with maximum MTU. The actual MTU, though, is dependent on the connected device. If it is a fairly new mobile phone, you will usually get an MTU of about 180B, but if it is connected to another nRF (with the ble_app_uart_c example) you will get the maximum possible MTU of 247.

You can see the actual MTU in the gatt_evt_handler(), which will update the m_ble_nus_max_data_len in the ble_app_uart example.

If you change the application to send messages based on UART input, but instead send packets from the main-loop, you can test the throughput.

In this example, you can use ble_nus_data_send() with arrays of size m_ble_nus_max_data_len, and send them until you get the return value NRF_ERROR_RESOURCES. This means that your queue is full. Then you must wait for the BLE_GATTS_EVT_HVN_TX_COMPLETE event (you must add this to the ble_evt_handler() ), which means that a packet has been ACKed, and you can queue another.

Best regards,

Edvin

RE: How to increase notification throughput on nRF52840?

LWittland — Thu, 04 Oct 2018 12:23:09 GMT

Hi Edvin,

the throughput is definitively our priority. A latency of ~100 ms is no problem, and even if it gets larger we can accept it as long as no notifications get lost.

You say that a high connection interval is preferrable for our application due to the lesser overhead. So far I consent, but my problem is that no matter if the interval is 200ms or 20 ms, only one notification is transferred per interval (5 at 200ms, (nearly) 50 at 20 ms).

Is there an option i've overlooked (or uintentionally set) that has to be set (or unset) to enable the soft device to gather several notifications in one big packet?

Best regards,

Lasse

RE: How to increase notification throughput on nRF52840?

LWittland — Thu, 04 Oct 2018 11:53:26 GMT

Ih Nathan,

I'm using sd_ble_gatts_hvx() with BLE_GATT_HVX_NOTIFICATION type, so unless there is some hidden overruling at work I'm certain that it ain't indications.

Thanks for the CONNECTION_PRIORITY_HIGH advice, I'll forward it to our android programmer (I'm programming the embedded side only) and let you know how it worked.

Best regards,

Lasse

RE: How to increase notification throughput on nRF52840?

Edvin — Tue, 02 Oct 2018 11:07:49 GMT

Hello Lasse,

It is true, like Nathan says, a phone will give an application 100% of the radio time, so a phone will typically not allow a connection interval too low.

The minimum connection interval allowed by the BLE stack is 7.5ms. At this connection interval, you will not have time to send 6 packets (because 1 packet takes longer than 7.5ms/6). However, phones would typically allow 15ms or 30ms connection intervals.

What is the critical part for your application? Do you need updates every 10ms (low latency), or do you need a high throughput?

Low latency => short connection interval => more. but shorter packages => more headers => less throughput.

High latency offers longer packs which could mean less headers and more throughput.

So do you need to transfer data continuously, and is it important that the phone receives these packs as soon as possible, or is it OK for the application to gather up several packs and send it as one big pack?

Best regards,

Edvin

RE: How to increase notification throughput on nRF52840?

Nathan — Mon, 01 Oct 2018 16:41:40 GMT

Hi Lasse,

Although your device can do better than what it's currently handling, you won't get 6 notifications in 7.5ms connection intervals on pretty much any phone out there. The phone operating system has to allow an arbitrary number of Bluetooth apps to run simultaneously, so it won't allow a single application to hog the entire radio interface for itself. On the latest OS's it might be a bit better, but a couple years ago I found that most phones at the time would allow either 6 notifications at 30ms connection intervals max, or 4 notifications at 20ms connection intervals max, which both come out to ~4KB/s theoretical max rate assuming 20 byte packets for BLE 4.0 level operation. You can now take advantage of BLE 4.2 and 5.0's longer packet sizes to increase the throughput though.

One thing you could do that could help right away is in your application, from the Bluetooth GATT class call the requestConnectionPriority function with the CONNECTION_PRIORITY_HIGH argument. What this will do is cause Android to pick the lowest connection interval that both the phone and the device will support, so you can keep reasonable MIN_CONN_INTERVAL and MAX_CONN_INTERVAL values in your device code. When you're done with high transfer rate, you can call requestConnectionPriority again with either the balanced or the low priority settings to save battery power.

To queue up multiple notifications, push the data you want to output to the phone onto a software queue, and call a function that tries to write them out to the softdevice in a loop. The softdevice call that handles putting a packet onto its outgoing queue is sd_ble_gatts_hvx, and once it has all the notifications it can handle it will return with the error code NRF_ERROR_RESOURCES. Basically whenever sd_ble_gatts_hvx returns success, remove the packet from your software queue and try pushing the next one. If you get an error or run out of packets to queue up, break out of the loop and retry after getting a BLE_GATTS_EVT_HVN_TX_COMPLETE event from the BLE events handler. The event will tell you how many notifications were sent successfully during the connection interval associated with the event.

Also I'm pretty sure you've check this already but just to double check, make sure you're using notifications and not indications, as indications are limited to one at a time max.

Edit: Whoops, needed to read your notes, you're already doing the NRF_ERROR_RESOURCES thing. The exact size of the internal queue should be 6, so you could write a piece of test code to verify it. And definitely check that you aren't accidentally doing indications instead of notifications.