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

Weird ble timing

Hello DevZone,

Recently I've been testing connecting multiple servers to one client and fiddling around with some settings regarding timing and packet size.

In the following image I have one to six devices active (set the total count of devices in the client accordingly) with a minimum connection interval of 7.5ms and maximum connection interval of 15ms. I would expect the following things to happen,

  • One server one client, time between each message to be 7.5 to 15ms
  • Two servers one client, time between each message to be 15 to 30ms
  • Three servers one client, time between each message to be 22.5 to 45ms
  • Four servers one client, time between each message to be 30 to 60ms
  • Five servers one client, time between each message to be 37.5 to 75ms
  • Six servers one client, time between each message to be 45 to 90ms

Yet, as the image shows this is not the case. Most packages are transferred below the time I expected it to happen.

I've also tried to extend the connection interval to 30ms minimum and 180ms maximum but this results into something that blew my mind.

Most of the packages are around 360ms (double of maximum connection interval) instead of between 30 and 180ms what I would expect.

Is there any logical answer for the things I encountered or is this part of the unknown Bluetooth magic happening inside the softdevice?

Currently using Segger 4.42, SDK 15.0.0 S132

Kind regards,

T IJ

  • Hey Hung,

    So I've been testing stuff with the GAP event length and I stumbled upon something which I cannot explain. My PHY is set to 1Mbps.

    The GAP length is set to 2.5ms.

    I want to transmit 140 bytes of data in this 2.5ms using a notification.

    I've read and calculated the amount of time needed to transmit this package.

    80µs from the master sending empty PDU

    150µs switch over time from RX to TX

    1288µs total data time plus overhead

    150µs switch over time from TX to RX.

    Totaling to 1688µs of time which is within the 2.5ms GAP length, yet the softdevice gives me an error on my data length extension above 72 bytes. 

    Is there an explanation for this? 

    Kind regards,

    T IJ

  • We need to look into the actual data length that the central assigned to the connection (BLE_GAP_EVT_DATA_LENGTH_UPDATE event) . 


    The softdevice can't dynamically schedule based on the actual data and will calculate only the worst case scenario, this includes the max size of TX and max size of RX. Please check the effective RX and TX octets/time you get in  BLE_GAP_EVT_DATA_LENGTH_UPDATE  event. 

  • If the data length is set to its default settings if the length is exceeded, it doesn't even send a length request when it results to default.

    I did manage to capture an packet with 72 and 50 bytes which is allowed. Something tells me that the Max RX and TX time is not correct in this image because the time is the same when I set the data length to 50 bytes.

  • Please upload a full sniffer trace file so I can have a look. You can convert this case to private if you want. 

  • 2.5ms 50 bytes.pcapng2.5ms 72 bytes.pcapng2.5ms 140 bytes.pcapng

    Somewhere in my mind I might have found the reason I'm not able to set the data length to 140 because to my believe the TX and RX time must be equal to each other, because the master does not only send an empty packet but also needs the time to send data as well.

    To me this makes, after a lot of thinking all the sense of the world. 

    I do believe I have to find a different method to (mis)use the Bluetooth connection to a way it suits my purposes. 

    If you can tell me how to privatize this thread I will be happy to explain in a bit more detail what my need is.
     

Related