Short Duration Connection with Long Characteristic Write - MTU change vs. Queued Writes

[Rob C]

I have an application with Nordic devices as Central and Peripheral.

The first device is a multi-protocol device (nRF52840) and acts as BLE peripheral.  Min connection interval is about 100mS to prevent interference with the other radio user.

The Central is a BLE-only (nRF52832).

The Central device connects only briefly (no bonding) and wants to deliver a 112-byte payload to a single characteristic quickly, disconnect, and get back to sleep.

I am currently doing this with CONNECTION_INTERVAL = 100mS, GAP_DATA_LENGTH = 27, GAP_EVENT_LENGTH = 6, MTU = 115.

Its working fine, but it appears (based on RTT output) that the MTU negotiation takes about a second to complete.  I see from the sequence diagram, MTU change takes a few messages.  I'm wondering if its worth the 1 second delay and addition power consumption on my Central.  Are my settings (esp. GAP_EVENT_LENGTH) somehow slowing MTU negotiation?  Or, would I be better off leaving MTU as-is (since this is a short-lived connection) and use queued writes instead?

Thanks,
Rob

[Vidar Berg]

Hi,

Is the peripheral bonded with the central so that you can store/cache the attribute table across connections? Most of delay is probably coming from the service discovery procedure. MTU is typically negotiated afterwards. 

I suspect Queued writes will be slower compared to increasing the MTU, but haven't tested it for this particular scenario. Another possible option could be to use normal MTU with write commands and just arrange the data in your application code. 

Best regards,

Vidar

[Rob C]

Vidar,

Thanks for your reply.

Peripheral isn't bonded and connections can be fleeting.  I hadn't considered the service discovery could be slowing me down -- I'll debug that to see.  Thanks also for confirming Queued writes vs. MTU is probably not worth it.  I understand that splitting my payload into a number of smaller registers is an option too.

Best,
Rob