data streaming application. reception problem in nrf connect app (android)

[shiva74638]

Hi, I am coding an application on nrf connect sdk 1.9.1. which requires to send some data at 25packets per second. and each packet will be ~37 bytes. On the receiver side in my particular use case, it may not be possible to update mtu size everytime

So to make the data streaming work with any mtu sizes, In the code, I am checking the mtu size before sending any data and if mtu size is larger i am sending the data packet as it is. if not, splitting the packet into two each of with 20bytes size with additional headers and numbers and sending one packet after the other.

When I run the application on 52840 eval board and use nrf52dk_52832 eval board with nrf connect desktop app as receiver or vice versa the app receives all the packets in order without any error (first pack then second pack which are split in the application).

But if i use android mobile app as the receiver and run the streaming then, it works fine for a couple of seconds and then the second packet starts missing. This is only happening with the android app. on the desktop app it works fine as long it is run.

I am attaching the modified peripheral uart code file. To reproduce,
1. flash the code to nrf52840 or 52832 eval board.
2. connect to the board with android nrf connect app.
3. give the command 'S' to start the streaming. without updating the mtu.
4. you will notice alternating data packet with headers 'X' and 'c' and after a while you will only receive 'X' packets
5. command 'S' also stops the streaming.



2728.peripheral_uart_data_stream_test.zip

[Edvin]

Hello,

Does the log at any point print: "Failed to send data over BLE connection" when you start missing packets?

Your requirements seems a bit too strict to work with any BLE device without changing the MTU. Remember that it is always the BLE central that dictates the BLE connection parameters. That means that if the phone decides on a connection interval other than what you use on a DK as a central, it may behave differently. 

However, the application should tell you that it was not able to queue more packets, because the TX queue is full, and it should print "Failed to send data over BLE connection" in the log.

By the way, you don't need to send the data through the fifo_uart_rx_data structure. You can use bt_nus_send() directly. 

Typically, the mobile phones will use a larger connection interval, so if you send a lot of small packets, they will not be able to keep up (this is a bit simplified, but that is what is happening). You can then either send longer packets, or try to shorten the connection interval (but I suspect the phone will not allow for it.

Best regards,

Edvin

[shiva74638]

Thanks for the quick reply. I also expected some message on log if any packet missing happens, but it doesn't print any message like that. Memory overflow warnings are also not seen.
Will try with shortening the connection interval.

[Edvin]

Hello,

Make sure that you check the return value of bt_nus_send(), and print something in the log if it returns anything other than 0. A connection may fail to queue packets, but all the packets that are queued successfully should never be dropped, as that is part of the SoftDevice Controller, and the Bluetooth Low Energy stack.

Therefore, all messages that are queued using bt_nus_send() and bt_nus_send() returns 0 will be sent at some point. If it returns something other than 0, it means that the packet was not successfully queued, possibly because the queue was full, meaning you need to queue it again later.

Best regards,

Edvin

[shiva74638]

Hi Edvin, I was able to solve the issue by directly calling the bt_nus_send() and checking the return values instead of pushing data to fifo_uart_rx_data. But,

When I checked the connection intervals of mobile application and eval board, noticed that the eval board as central uart has a 7.5ms interval right after the connection and after about 5secs gets updated to 30ms. and with mobile application sometimes it settles to 37.5ms sometimes to 45ms. 
At first it didn't seem to be any big difference, and both are expected to behave the same way, but when I changed the central uart's connection interval to 37.5 ms and 45ms, it started to behave the same way as the mobile application. 

Although I haven't dealt with the connection intervals directly, just putting this observation for anyone's reference.

thankyou.