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

nRF Mcp Dfu freezes when »Number of packets« is set greater than about 356 packets

Hey there,

today I'd tested around with the Dfu service.

  • Peripheral is nRF51822 running Sdk 5.2.0 bootloader example (Softdevice 6)
  • Central is Android 4.3 running nRF Mcp 1.9.1
  • Testfile (nRF51822 Application) is Hrs Example (about 43k binary size)

In the settings of Mcp I found some Dfu options and I determined that the »Number of packets« value has an affect to the update data throughput.

My Android device connects with 48,75 ms connection intervall and transferes mostly about 4 packets at each connection intervall. So, the max throughput is theoreticly at

4 x 20 Byte / 48,75 ms = about 1.641 Byte/s

But when metering the Dfu throughput, I got just about 1.000 Byte/s. Well, after changing »Number of packets« from 20 to 300, I got about 1.600 Byte/s - nice.

But then, when I set »Number of packets« to greater values (e.g. to 400), the Dfu upload freezes at 16 % - and the same when I switching off the option »Packets receipt notification procedure«.

For »Number of packets«, I determined a treshold value of 356. This means that Dfu works with values up to 356, but for greater values the Dfu freezes at 16 %.

Ok, I don't expect higher throughput with higher »Number of packets« values. I'd just detected that issue and would report it.

Btw: Is this the right place for that kind of topics or should I rather put that in an issue tracker?

Parents
  • The number of packets gives the number of packets between each packet receipt notification. Setting this to a very low number will indeed hurt throughput a bit, as the central will stop sending data until this notification is received. With the same setup as you (except Android 4.4.3) I was unable to reproduce your findings, but if you believe this is a problem with the SoftDevice, then you should report it as such.

Reply
  • The number of packets gives the number of packets between each packet receipt notification. Setting this to a very low number will indeed hurt throughput a bit, as the central will stop sending data until this notification is received. With the same setup as you (except Android 4.4.3) I was unable to reproduce your findings, but if you believe this is a problem with the SoftDevice, then you should report it as such.

Children
No Data
Related