CC2642R: CC2642 scan issue

Hi Franco,

Thank you for posting. I've assigned someone on my team to help assist here and we will follow up accordingly. 

Firstly, understand that the scheduler considers two different priorities of tasks:

- primary. this is the highest priority and consists of connection events

- secondary. this is the lowest priority and consists of everything else: advertising, scanning, etc.

In general, you do not have much fine control of interleaving secondary and primary tasks because the primary task will always interrupt the secondary task. If you want to achieve exact duty cycles for each task, you need to experiment with the parameters and scan start times (in relation to the connection event) to find a set of parameters that work as you are doing. I think you were just missing the knowledge that primary tasks will interrupt secondary tasks. Essentially you need to ensure that the connection event never occurs during a scan period.

Of course, this is only deterministic if you control all parameters in the system. If you do not, then you should not expect your duty cycle goals to be achieved 100% of the time. Some potential issues:

- the amount of data sent during a connection event. Connection events with larger amounts of data will take longer, potentially spilling into a scan period.

- connection parameter updates. If you update the connection parameters, you will likely need to update the scan timing. If you are a slave device, then this is a serious issue as ultimately the master can decide the connection parameters.

Hi Tim,
thank you for reply.

We understood that there is somehow a priority inside the module. The priority handling cannot be different from the one we discovered, off course connected devices shall be kept in higher consideration respect to the potentially connectable ones.
This is not our problem.

It's not possible to avoid connection interval collision with scan interval. These event are fully asynchronous.
This is not a possible solution

The issues are the following:
1)The scan mode is not recovered after the connection interval task is completed
2)Depending from the scan window and scan interval you select there is an unwanted behavior: the effect is like you chose scan interval = scan window.

Regards,
Franco

Hi,
an update on the following issue:
2)Depending from the scan window and scan interval you select there is an unwanted behavior: the effect is like you chose scan interval = scan window.

We discovered that this has nothing to do with the previously active connection.
It happens In general, even if there is no active connection.
If the scan window and/or the scan period are not multiple of 5, then they are both rejected. The effect is like selecting scan interval = scan window.
Knowing this limitation we can anyway select some valid combinations that are multiple of 5.
Even is this issue will be not corrected, we can live with it.

We have no way instead to find a workaround about issue 1.

Hi,
can you confirm that the two issues are clear now?

As I said in the previous post we found a workaround for the "full scan" bug that is not limitating too much our degrees of freedom. It is enough to roud scan window and scan period by 5 ms multiples.

The other issue is instead highly limitating our development.
We see that in case of full scan the scan window is immediately resumed when a connection event ends.
Instead using any duty cycle lower than 100% this doesn't happen.
Are you aware of this issue?
If yes, when do you plan to release a fix?

Franco

I am not understanding the issues as you are describing them. Are these the same issues that the attached captures were describing from the original post or different issues? Can you provide the following for each issue?

1. Captures of RF Observables annotated to show exactly where the bug is occurring.

2. A list of the scan parameters and connection intervals that are used for each issue.

Hi,
yes, I'km still speaking of the same issues.

The one related to 5ms rounding I think it's clear.

Let's focus on the other, the scan window interruption issues.
All parameters I used you can find listed in the first post:

The first always connected slave uses a 100 ms connection interval with no data exchange.

The master device has to use a low duty cycle scan mode due to power constraint. In this example the duty cycle is about 1/4.

We see two strage effects that makes impossible such implementation:

1) Scan period 205 ms, scan window 50 ms.
When the connection event of the first slave falls inside the 50 ms scan window, the scan window is interrupted. This makes the scan duty cycle lower and the discovery time higher.
The scan continues with the original duty cycle in the next scan period.

Also, in the same post I attached a Scan issues.zip archive, containing oscilloscope screenshots of the RF observables when the bug is occurring.

Hi,
have you checked the provided information?
Are these information enough?

Meanwhile I can give you some info about screenshots interpretation:

FULL SCAN ISSUE
Don't thing the screenshots will give you any hint, since we already discovered that issue happens when you do not round to 5ms the scan window or the scan period.
Anyway the folder
Scan issues.zip\Scan issues\204 ms scan period 50 ms scan window\
contains all the screenshots related to this issue. You can see in BLUE the TX status and in CIAN the RX status.
Initially we believed issue was related to background active connection with 100 ms interval. That's why you see the periodic switch to TX mode every 100 ms.
Anyway from the screenshots you can see that in full scan mode the RX status is restored afte each connection event.

SCAN INTERRUPTION ISSUE
This is the issue that is mostly limitating our development. Screenshots are in th folder
Scan issues.zip\Scan issues\205 ms scan period 50 ms scan window\
Again you can see in BLUE the TX status and in CIAN the RX status.
Issue is for sure related to background active connection with 100 ms interval. That's why you see the periodic switch to TX mode every 100 ms.
1 - 50 ms scan .BMP it's an example of good behavior.
The scan window is fully contained between two connection intervals, in fact the duration is the expected 50 ms.
3 - scan stopped at 15 ms by connection event.BMP
The scan window begins mere or less 15 ms before the connection event. So instead of having a 50ms over 205 ms coverage we obtain a 15 ms over 205 ms.
You can see that RX status is restored after the colliding connection event.

Regards
Franco

Hello. I understand your request now. Essentially, you are asking for deterministic, guaranteed handling of scan duty cycle. Unfortunately, the scheduler is just not designed to handle this. I have filed a feature request for this functionality in the future but I can not comment on when / if this will be implemented.

For an intermediate workaround, you can try the following:
- scan with the smallest possible scan interval at 100 % duty cycle (i.e. scan interval same as scan window)
- control the effective scan duty cycle from your application by manually enabling / disabling scan.
   - You can use the connection event callback to be notified when a connection has ended and start the scan after this. Then, you can set a timer and stop the scan when the timer expires.

Hi,
the workaround could work.
We have to try it and uderstand the impact on consumption, but I think that is feasable.
Let you know if it works.

Thanks
Franco