Peripheral UART, rx timeout and notification size

[Lars M]

Hi,

I'm running the sample "peripheral_uart" on an nRF52dk. It has a config called CONFIG_BT_NUS_UART_RX_WAIT_TIME, which is set to 50. The comment says the unit is milliseconds. That value is sent into function uart_rx_enable(). When I read about that function (docs.zephyrproject.org/.../uart.html, it is said that the unit is microseconds. Which is correct?

What is the behaviour if two bytes are sent on UART to the DK right after each other? That is, the first bit of the second byte comes immediately after the first byte is finished. If communicating at 115200 it takes about 70 microseconds for a byte to be transmitted. If having the timeout set to 50 (supposing the unit is microseconds), will the timer expire before the byte is completed? Or how does the timer work?

What is a good value to have on the timer if communicating at 115200?

The sample handles long UART messages by splitting them into several 40-byte parts before they are supposed to be sent on BLE. But if a message is more than 21 bytes, I get the following warnings (in this case the UART message was 22 bytes):

<wrn> bt_att: No ATT channel for MTU 24
<wrn> bt_gatt: No buffer available to send notification
<wrn> peripheral_uart: Failed to send data over BLE connection

There is a maximum of 23 bytes (CONFIG_BT_L2CAP_TX_MTU) for notifcations. Is it meant that each programmer should solve this? If splitting, for instance, the UART-data into 20-byte parts instead of 40 bytes, it works fine.

Best regards,
Lars

[Edvin]

Hello Lars,

It seems like there are some mismatches between Zephyr and this NCS sample at this point in time. Zephyr updated this from ms to µs, and the peripheral UART sample didn't update anything. So the correct should be microseconds, but the peripheral_uart believes it is milliseconds. Try changing it from 50 to 50000.

For the rest of your questions:

All BLE connections start with a message size of 23 bytes of payload. After connecting, they can negotiate a higher message size (MTU) up to 247 bytes. What version of NCS are you using? I believed that this sample would already have the larger MTU negotiation implemented. Are you in a connection when you are testing this, or are you advertising?

Best regards,

Edvin

[Lars M]

Hi Edvin,

And thanks for your answers! Ok, so 50000 should be a good value when using 115200?

But how does the rx timeout work? If I use 50 microseconds and run the UART at 115200 (70 microseconds for a whole byte), will there be an interrupt after each byte since the timer is set lower than it takes for a byte to be transmitted?

I use version 1.8.0. Maybe it is updated to version 1.9.1?

My device is connected when I test this.

Edvin said:

All BLE connections start with a message size of 23 bytes of payload. After connecting, they can negotiate a higher message size (MTU) up to 247 bytes.

What does that mean? Is this negotiation performed automatically when the devices have connected, or do I need to do something explicitly to ba able to use a bigger payload?

Best regards,

Lars

[Lars M]

Hi Edvin,

When I run Peripheral UART, 50 microseconds is selected. I have adjusted UART_BUF_SIZE (CONFIG_BT_NUS_UART_BUFFER_SIZE) from 40 to 20 to deal with the size limit for notifications. When I send 100 bytes contiuously on UART to the nRF, it works fine to send them as notifications.

I have taken the UART-part from Peripheral UART and added it to my own BLE-application. Then it works sometimes with 50 microseconds, but quite often it doesn't work. And the 100 byte data sending never works. But adjusting from 50 to 100 microseconds, it works. I don't know why there is a difference, perhaps things are drawn to their limits, and one implementation happens to work, while the other doesn't.

Best regards,

Lars

[Edvin]

Hello Lars,

It is difficult to know without knowing more details. What do you mean by "doesn't work"? Do you loose data? If so, where is it lost? Over BLE or do you loose it when receiving over UART? What are the "not working" symptoms that you are seeing?

BR,

Edvin

[Lars M]

Hello Edvin,

I got error messages saying something like "not able to allocate UART receive buffer". I try to repeat it now, but I don't get this error anymore... This message is printed from three places in the UART-code, and I don't remember from which I got the message. I have tried to use different versions of the SDK, but it always works with 50 microseconds. I guess I will try this later on to see if I can repeat it.

BR,

Lars

[runved]

Still not fixed i v2.2.0, whay? Thanks Lars, i had the same problem and now it is solved thanks to you.

uart_rx_enable(uart, buf->data, sizeof(buf->data), 5000); not 50.

br

Rune

[Edvin]

Hello,

I have pinged the internal ticket. Thank you for the reminder!

Best regards,

Edvin