File Manager - Windows capability

[optical-o]

Hello, i wanted to ask you what is the support or roadmap to implement the same principle for the File Manager as for the Image Uploader that uses windowUpload. Is there a way how to speed up the File download/upload process ?

[philips77]

Perhaps it's not available in the nRF Connect Device Manager sample app, but the API is already there. You may use FileUploader class: https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager/blob/cc947d4fe003b5facd8fd03cb005197774bb3e89/mcumgr-core/src/main/java/io/runtime/mcumgr/transfer/FileUploader.kt#L12-L18 and set windowCapacity to one less than number of McuMgr buffers. This should work.

[optical-o]

Is there support for downloading ?

We are currently dealing with rather large files on the device and the download speeds are pretty low.

[philips77]

The download speed depends on the sender side and you need to check your implementation in firmware. The library is able to merge long SMP packets and that should work even using the normal FsManager, available from the nRF Connect Device Manager app.

When uploading a long file the following parameters matter when it comes to upload speed (or download, from App's point of view):

• MTU[^1] (recommended value is 498[^2])
• DLE[^3] (recommended value is 251 (maximum))
• Connection Interval (recommended value that fits several LL packets in a single connection interval)
• SMP packet length

[!Note] Each SMP packet consists of:

• Header (8 bytes)
• CBOR overhead (depends on the packet content)
  • FS manager sends the file name and current offset in each packet

The longer packet, the more percentage of the packet is used for sending the data.

A SMP header contains a length of the packet. Mobile libraries support merging packets split into several GATT packets, but it is the device side that needs to send as such.

[^1]: Attribute layer Maximum Transfer Unit [^2]: Why not max? Packets of size 498 can fit into 2 full-length LL packets. More data would add a short 3rd packet. [^3]: Data Length Extension, allows longer packets on Link Layer

[optical-o]

Isn't the Download also implemented as a request/response protocol ?

The download request contains the offset and filename. It probably waits until the first one finishes before it sends another one ?

We are using a MTU 498 i will check the DLE. Could you tell me a typical speed that is achieved on the nrf5240dk when getting file from the flash ?

So for downloading you recommend using large SMP buffer that will be split across multiple GATT notifications ?

[philips77]

Isn't the Download also implemented as a request/response protocol ?

Yes, but the download speed mostly depends on how big the response packet is, so you send as little requests as possible and receive as little overhead as possible.

The download request contains the offset and filename. It probably waits until the first one finishes before it sends another one ?

We can't know how many bytes are we getting as a response to the request. It may be few or a lot, so can't really send multiple requests with different offsets.

We are using a MTU 498 i will check the DLE. Could you tell me a typical speed that is achieved on the nrf5240dk when getting file from the flash ?

We only tested upload speed during DFU from the phone. With these parameters we're getting ~40kB/s upload speed.

So for downloading you recommend using large SMP buffer that will be split across multiple GATT notifications ?

Yes. Each request should be replied with a huge SMP packet split into several notifications, where only the 1st one contains the header and some CBOR parameters and the rest is just data. I don't know if that's supported in Zephyr, or not yet.