NRF_ERROR_NO_MEM in NUS using FIFO

[Antonio]

Hi,

I am testing the NUS using the UART example in the SDK11 with the PCA10040 board.

Since I want to achieve the maximum speed of transmission I used the FIFO buffer to place my out data and I am constantly calling the ble_nus_string_send when there are 20 bytes available on the FIFO. I am transmitting to the android UART 2.0 app with android 6.0 @ 15ms interval.

If I receive a NRF_ERROR_NO_MEM, I assume that the 6 packets of the interval have been filled, but then I keep retrying, without delay, until I receive the NRF_SUCCESS. It seems to work.

Am I forcing something with this brute force on the ble_nus_string_send? Can the SD be skipping some packages because I retry too often? Is it safe?

Thanks!

[Stefan Birnir Sverrisson]

Hi Antonio

Im not sure why you get NRF_ERROR_NO_MEM. The normal procedure is however described on this thread. Throughput limitations can also be limited by the phone you connect with. For Android phones, throughput capabilities are different from phone to phone. There can also be limitation in the S132 v2 softdevice, see the S132 v2 migration document, section about "configurable bandwidth". The migration document is bundled with the S132 v2 archive.

[Antonio]

Hi Stefan, Thanks. I am getting a 3004, the NUS service is only returning what comes from the SD. I read the migration document and I am getting count = 7, so that should be good. I read also the thread, and in one of the recommendations it essentially is doing what I am doing, just adding another packet when no error is returned, but in my experiment I serialized the packets out and counted them on the input to check for sequence, and some packets would have garbage. (2 out of 1000) I implemented now not attempting to write the next packet before I received the BLE_EVT_TX_COMPLETE, but that is diminishing the throughput. So is it ok to just while(1) the package out until it returns no error and then send the next one? Do you think the occasional garbage in the packet is on the output? or in the android [email protected]?

[Antonio]

This is the throughput example github.com/.../main.c

[Stefan Birnir Sverrisson]

Hi Antonio

I think error code 0x3004 is actually BLE_ERROR_NO_TX_PACKETS but not NRF_ERROR_NO_MEM. The BLE_ERROR_NO_TX_PACKETS simply means that there was no buffer space for the packet and it was not queued for transmission.

The documentation here states that it fine to call HVX repeatedly even though there is not buffer space available. You probably get the maximum througput that way. If you only transmit a packet after receiving the BLE_EVT_TX_COMPLETE event arrives, I assume that other events or interrupt can delay both the BLE_EVT_TX_COMPLETE event to arrive and also delay the process of filling the buffer again. Therefore, the following connection event might occasionally occur before you fill up the buffers, resulting in degraded throughput.

What do you mean by " but in my experiment I serialized the packets out and counted them on the input to check for sequence" ? Can you explain better?

[Antonio]

Thanks Stephan. I got it working now and I feel more comfortable knowing that I can just keep retrying without breaking the SD and that I do not have to rely on the BLE_EVT_TX_COMPLETE. By serializing I meant that in a FIFO buffer I earmarked each packet to see if I was receiving it on the other end without dropping packets. It is ok now, the garbage was a bug of mine :). Thanks!