Can services/characteristics/descriptors discovery could be made faster

[jpo38]

I'm working with a nrf51422/s110 dev kit on which I downloaded the Heart rate Monitoring sample project. On my PC, using a s130 dongle, I connect the device and wrote some code (based on Heart Rate Collector sample program) to discover all services/characteristics/descriptors of the BLE device.

When you request to disover services/characteristic/descriptors, only the first few one are retrieved, and you have to do a new request for the next ones.

For HRM device, here is the services/characteristics/descriptors hierarchy:

• Service 0x1800
  • Characteristic 0x2A00
    • Descriptor 0x2803
    • Descriptor 0x2A00
  • Characteristic 0x2A01
    • Descriptor 0x2803
    • Descriptor 0x2A01
  • Characteristic 0x2A04
    • Descriptor 0x2803
    • Descriptor 0x2A04
• Service 0x1801
  • Characteristic 0x2A05
    • Descriptor 0x2803
    • Descriptor 0x2A05
    • Descriptor 0x2902
• Service 0x180D
  • Characteristic 0x2A37
    • Descriptor 0x2803
    • Descriptor 0x2A37
    • Descriptor 0x2902
  • Characteristic 0x2A38
    • Descriptor 0x2803
    • Descriptor 0x2A38
• Service 0x180F
  • Characteristic 0x2A19
    • Descriptor 0x2803
    • Descriptor 0x2A19
    • Descriptor 0x2902
• Service 0x180A
  • Characteristic 0x2A29
    • Descriptor 0x2803
    • Descriptor 0x2A29

Here are the timings upon services/characteristic/descriptors discovery process:

• t0, Discovering primary services from handle 0x0001
• t0+110ms, Received service discovery response: UUID 0x1800, 0x1801, 0x180D (handles 0x0001 to 0x0011)
• t0+110ms, Discovering next primary services from handle 0x0012
• t0+220ms, Received service discovery response: UUID 0x180F, 0x180A (handles 0x0012 to 0xFFFF)
• t0+220ms, Discovering characteristics for service 0x1800 from 0x0001 to 0x0007
• t0+330ms, Found 3 new characteristic with handles: UUID 0x2A00 0x2A01 and 0x2A04 (handles 0x0003, 0x0005 and 0x0007)
• t0+330ms, Discovering descriptors for characteristic 0x2A00
• t0+440ms, Received descriptor discovery response: 0x2803 0x2A00

You see that, at this point, we only discovered:

• Service 0x1800
  • Characteristic 0x2A00
    • Descriptor 0x2803
    • Descriptor 0x2A00

And it took more than 400ms.

In the end, to discover the whole services/characteristic/descriptors hierarchy, it takes up to 2 seconds. For bigger devices (with much more complex services/characteristic/descriptors hierarchy), it can take up to 10 seconds, which is hardly acceptable.

Is there really no way to speed this up? Is there any setting that could be changed at the softdevice or firmware level)?

If not, the API should probably be reworked. When deploying the same code (C++) on an Android device (using Qt to access BLE), full services/characteristic/descriptors for HRM device takes only 700ms (3 times faster).

[RK]

Half the connection interval/slave latency comes from the peripheral, other half from the central connecting. So first off you need to figure out which one is limiting the connection interval and you need to also see if there was slave latency set on the connection. You have both halves of that code so it should be quite practical to see what's set. Log it too - on connection you are given the actual parameters, dump them and see what you've got. Or sniff, you can see them in the connection packet.

Most likely reason the other thing is faster is because it negotiates a lower connection interval or no slave latency. Dump it or sniff it and see what you get. Interval goes down to 7.5ms, so you should be able to get a request/response pair in 15ms.

I've never seen anything manage to receive a response and send the next request same interval, sniff to see if that's happening too.