This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52832 BLE improve transfer file with UART service

Hi

We are using today nRF52832 and communicate through Nordic UART service (NUS).

Sometimes we would like to transfer files from our device to the app. This is going very slow.

Our default setup is:
- connection interval 50ms
- MTU size 23 bytes

We are currently using SDK 12.3.0 and S132 ver. 3.00.
Our device can be both Central and Pheripheral depending if communicate with Phone or with other Pheripherals.

This is what we see with Wireshark and nRF Sniffer (hope the screen dump is readable...):

So my questions are:

1) What is the reason why our device (slave) respond with an Empty PDU first, after received a write request?

2) We have now set wr_auth=1. If we set this to 0, will we get higher transfer rate? And if so what kind of pitfalls can there be?

3) Should we increase the MTU size from 23? Is this a good choice? If increasing the MTU size will this mean higher current consumption?

4) Is it possible within the same software, since our device can both act like Central and Pheripheral, to have two different MTU sizes?
E.g when Master runs with 23 bytes and Slave with 128 bytes.

4) Are there other ways we can improve the transfer with NUS?

5) Should we look into another service, e.g. Object Transfer Service?


Please advice

Peder Olav

Parents
  • HI Peder Olav, 

     

    1) What is the reason why our device (slave) respond with an Empty PDU first, after received a write request?

     If the slave does not have any data to send at the scheduled connection interval it will respond with an empty PDU. Both master and SLave will send empty PDUs if there are no data to be sent in order to maintain link synchronization, i.e. make sure that the timers that keep track of when to turn the radio on in TX/RX mode does not drift apart. 

     

    2) We have now set wr_auth=1. If we set this to 0, will we get higher transfer rate? And if so what kind of pitfalls can there be?

     Yes, Write Commands and Write Requests will require the application to authorize any values that is written to which reduce the throughput., please see the GATT Server Message Sequence Charts as well as the Bluetooth Low Energy data throughput section of the S132 SoftDevice Specification. Read/Write Authorization can be useful in some cases, but if throughput is the most important factor, then you should go for Write Commands without authorization. 

    3) Should we increase the MTU size from 23? Is this a good choice? If increasing the MTU size will this mean higher current consumption?

     Increasing the ATT MTU size will result in less overhead as you can fit more ATT data within one BLE packet. You reduce the overhead by not sending the ATT header, which in turn is more effcient use of the radio. 

    4) Is it possible within the same software, since our device can both act like Central and Pheripheral, to have two different MTU sizes?
    E.g when Master runs with 23 bytes and Slave with 128 bytes.

    As of S132 v4.0.x the MTU length can be individually configured per link. So yes. 

     

    4) Are there other ways we can improve the transfer with NUS?

    5) Should we look into another service, e.g. Object Transfer Service?

     I recommend that you take a look at the Experimental: ATT_MTU Throughput Example in our SDK. 

    Best regards

    Bjørn

  • Thank you very much for good and understandable answers :-)

    Best regards

    Peder Olav

Reply Children
No Data
Related