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

[jm_laird]

Hi Kenneth,

The original code was using the 32KHz crystal and I switched to the LFSYNTH to see if it was perhaps an issue with our 32KHz crystal or the capacitor selection for it but that didn't seem to fix it. I've now switched back to the 32KHz crystal with 251-500ppm and the results are:

I've then switched to RC oscillator with 251-500ppm and the results are:

I then kept it on RC but removed out code that scans for devices and it does now seem to be fine so that's the big cause of the issue, perhaps the scan window settings will need to be adjusted:

Thanks,
Jamie

[Kenneth]

jm_laird said:

I then kept it on RC but removed out code that scans for devices and it does now seem to be fine so that's the big cause of the issue, perhaps the scan window settings will need to be adjusted

I am thinking the same, try to make the scan window much less than the scan interval. What are your current settings?

Kenneth