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

Timing of central RX and peripheral TX

I got an easy but fundamental question: How to make sure that the central sees the advertising package of the peripheral..

For example when the peripheral advertises only every 5 seconds.. The centrals scan windows would have to be >5seconds? (and also the scan interval) So ongoing RX current??? (Or does the RX current only occurs when it actually receives an advertising packet?)

If they would establish a connection.. could I decrease the current consumption of the central while not increasing the current consumption of the peripherals? (Do they synchronize their RX/TX or something?)

  • There is no way to guarantee that a central device can see an advertising packet (due to noise etc.), and as a peripheral in essence could modify its advertising interval, this is usually not a design goal of a central.

    The peripheral uses two scan parameters when looking for advertisement packets. As explained in the BLE Spec (v4.0 Volume 6, Part B 4.4.3):

    During scanning, the Link Layer listens on an advertising channel index for the duration of the scan window, scanWindow . The scan interval, scanInterval , is defined as the interval between the start of two consecutive scan windows.

    As long as the devices would overlap at some time you would get connected. To "guarantee" that your central would see the peripheral within a single scan window you would need a scan window of >15 seconds.

    The RX current will occur as long as the peripheral is "listening" i.e. scanning.

    By establishing a connection you would allow the devices to operate synchronously. This way they will both know when to enable/disable RX/TX, and you would spend less power. The maximum allowed value for connInterval is 4.0 seconds, of which their radio would only have to be active for a couple of milliseconds.

  • @muhkuhns: As shibshab mentioned there is no way to guarantee a packet will be received even if the central was listening on that channel due to interference.

    If we leave interference & noise aside, what you need to make sure that the central can catch all the advertising packet is to listen all the time. Usually the peripheral will advertise in all 3 channels. The S120 listen to each of them one at a time (rotating between 3 channels). So what you need to do is to configure the scan windows equal to scan interval. This will make the scanner scan all the time. It doesn't have to be 5 second scan windows and scan interval. Just set the scan window = scan interval. Note that to make sure the scanner listen all the time, there should be no connection should be active on S120 when scanning.

    When connected, the scanner doesn't have to listen all the time any more. They synchronize and agree on timing windows and channel maps to continue.

  • Thanks for your detailed answer! Especially the last part is what I was looking for.. so in a connection they can operate synchronously.. Where can I read more about this? I haven't had any luck finding something that tells me more about it...

    As far as I got it its basically something like this (in a connection):

    Peripheral: Hey central, I want an to use an intervall between 3,75 to 4seconds. Central: Okay, I'm fine with that. 4 Second it is!

    And then they turn of TX respectively RX and wait for 4 seconds?

    How does it work with 4 peripheral and 1 central. The central manages the timeslots for each?

  • Thanks for your explanation! Can you name a good free ressource to read more about the last part? How they synchronize when connected. Is this implemented in the Multilink Example?

  • @muhkuhns: There are 2 documents you may want to have a look:

    • Chapter 11 in the S120 Softdevice Specification v2.1, It's a brief on the connection timing.

    • For more detailed information, please have a look at section 4.5 at Vol 6 part B in the Core Bluetooth v4.2 specification.

    It is defined in the spec of Bluetooth Smart, so it is strictly followed in any BLE connection.

Related