nRF connect on iOS displays wrong MTU (version 2.4.12)

[jm_laird]

Using the nRF Connect mobile app for iOS (version 2.4.12) we are trying to get the MTU that our nRF5340-based device is using, however it always seems to be wrongly displayed at 23 bytes, see:

When using an nRF52840 sniffer on this connection however, the device does seem to be correctly using 4.2 DLE with a larger packet size:

This is not helpful as we are trying to debug a slow DFU speed (7+ minutes for a 400KB file) and we're not sure if there is an issue with our application core configuration, network core configuration or the mobile app:

[Kenneth]

Hi,

Can you share the sniffer trace? That should help see what may be causing the low throughput. 

Regarding displayed MTU size, that may seem like a bug in the app.

Kenneth

[jm_laird]

Hi Kenneth,

Sniffer trace attached. This was tested with the Nordic nRF connect device manager iPhone application

bl5340_fota_slow.pcapng

Thanks,
Jamie

[Kenneth]

I am not familiar with DFU, but I can see there is only 1write for 1notification, this implementation will by design be slightly slow, so it may be that I should create an internal jira to look into DFU improvements. However I can also see there are a lot of retransmissions occuring, either by noise (but more likely) due to tolerance in timing, can you for test try to increase the ppm tolerance, I believe by using:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

Kenneth

[jm_laird]

Hi Kenneth,

I've changed both network and application core to use the LFSYNTH whereby it gets the low frequency clock from the high frequency clock source and changed the ppm to 251-500ppm, I flashed that and did another check but I see the same behavior whereby the phone seems to be re-transmitting:

Thanks,
Jamie

[Kenneth]

Can you use the internal RC (or even external 32kHz crystal if available) instead of synthezised 32kHz for comparison? I do not believe the LFSYNTH have been qualified and tested for BLE operation (yet at least, also the LFSYNTH will not achieve low power operation).

Kenneth