Problem with scan window

Connection interval - 750ms.

I dont need more scanning time. I just need constant scanning time - always 275ms.

But when the two devices are connected, I see that the scan time becomes not constant, as you can see in the picture.

Tim,

As far as I understand, if scanning window equals to scanning interval, it would mean that our device always scan for new devices and it is not good both for power consumption and application itself.

The scenario is as follows: the customer has a main cycle in their application, which is equal to 750ms. During the cycle the device should scan the environment looking for other devices that are not currently connected and also exchange the data with devices that are already connected. That is why they want to set scanning window shorter then the main cycle (which is considered as scanning interval) to allocate the rest of the time for data exchange with connected devices.

So far the requirements are to have scanning interval (main cycle) 750 ms and scanning window 250-300 ms. The issue is that we can not get width of scanning window stable.

Please advise what should be the settings for such setup.

Best regards,

Ilya

Aslak,

Many thanks for the comment. Proposed method also doesn't fulfil the requirements. Idea of the customer is to split their RF activity between scanning and data exchange. If they have fixed scan window for example 300ms out of 750 ms, they know that deice will consume current for scanning only for 300 ms. If there is no connected nodes, the device is simply goes to LPM for the rest 450ms.

If they will run scan every 10ms it would mean that out of 750ms they will scan for 750ms if no connected nodes, so it will increase overall power consumption.

Are there any limitations on stack to set scanning window shorter then scanning interval?

One thing to add - with one and even two connected devices we can keep scanning window somehow stable (+/- 5ms), but with more deices it begins gradually decrease.

Best regards,

Ilya

Ilya,

Here's a sort of .. graph over how it works:

|< Scan Window >       |< Scan Window >       |< Scan Window >       |
|<    Scan Interval   >|<    Scan Interval   >|<    Scan Interval   >|
|<                   Scan duration                                  >|

So, scan duration tells you how long scanning should be going on. Scan window is how much of the interval should be occupied by scanning. Scan interval is how long scanning should be done on each channel.

Best regards,
Aslak

Hi!

I changed scanWindow and scanInterval to 16. scanDuration to 300 and added the task to restart discovery every 750ms.

But results is negative: discovery happends not every cycle. And duration of discovery is less ten needed. There is oscillogram:

Ch1 is the voltage of 13Ohm shunt on supply bus.

Ch2 is the diagnostic output (Board_LED1). It becomes logic 1 when discovery is started by program, and becomes to logic 0 when GAP_DEVICE_DISCOVERY_EVENT recieved.

There was no active connections.

As you can see only 1 of 5 discoveries was "real" with RX but it have duration less then i expect.

Files of the project in attachment.

I have some modifications for tests: by clicking right button LCD is powering down, and programs automatically start discovery every 750ms. I have also modificated board_lcd.c and .h with Board_closeLCD func.

Application.zip

I think we need to take a step back here...

Your request to get exactly 300 ms of scanning duration may not be possible due to the fact that you are connected to a smartphone as a slave. Therefore, you are subject to connection parameter updates coming from the smartphone. Firstly, the multiRole demo has not been tested with a smartphone and states:

"The controller's scheduling mechanism after parameter updates occur has not been fully characterized. Parameter updates will not cause the connection to drop but may cause missed connection events. For greatest stability, all connections should be established at the same interval or multiples of the smallest connection interval."

Essentially what will happen if you are connected to three slaves at 750 ms and one master (smartphone) at a changing connection interval is that the available time to performing secondary actions (scanning / advertising) will vary based on the periodicity of how the master connection event lines up with the slave connection events.

However, I  don't think that you need to scan for 300 ms consecutively and smaller windows / durations will actually be more effective. Am I correct that the ultimate goal is to successfully scan for devices while connected to 3 slaves and 1 master at 750 ms connection interval each?  This is easily accomplished within the confines of the multiRole demo (i.e. not using a smartphone as a central).  For example, consider the following test starting with the default multiRole project.

1. Change the following parameters in multiRole.c:

//connection parameters
#define DEFAULT_CONN_INT                      600
#define DEFAULT_CONN_TIMEOUT                  1000
#define DEFAULT_CONN_LATENCY                  0

2. Compile and load the modified multiRole project.

3. Using the hex files included with the demo,

- load three devices as peripherals (CC2540_SBP.hex, CC2541_SBP.hex, or CC2640_SBP.bin)
- load one CC2540 dongle with CC2540_HTR.hex to function as the central

4. Connect to the three peripherals using multiRole such that multIRole forms a connection in the master role

5. Use BTool to control the CC2540 central to connect to multiRole such that multiRole forms a connection in the slave role. Ensure to set the connection parameters to 750 ms:

6.  Scan with multiRole

-------------------------------------------------------------

I profiled this by using a logic analyzer to capture the range extender signals (http://processors.wiki.ti.com/index.php/CC26xx_Range_Extender_Control). I would prefer if you could follow this same process as it is cleaner and allows us to see the entire connection.  Here is a capture of my entire connection (open with Salae): /cfs-file/__key/communityserver-discussions-components-files/538/capture.logicdata

Here is an example sequence, starting when all connections have been formed and the multiRole is scanning (at marker B1 ~ 41.45290317 sec):

Red = 3 slave connection events
Blue = advertising
All other times (when Rx is high), the device is scanning

This is continued here...

Green = master connection event
Red = 3 slave connection events (restart of cycle)
All other times (when rx is high) = scanning

As you can see, the device is scanning at all possible times.

The goal of this is to confirm that this behavior is acceptable for the standard multiRole demo for your use case.  That is, it is acceptable (and more effective) to scan for smaller windows / durations instead of attempting one long scan which will be broken by uneven connection intervals.

Now, if you provide some more information about what the master is doing, we can begin profiling this. Mostly, I need to know what connection interval the master connects at and how often / what the connection parameter updates are.