BSP_INDICATE_SCANNING - period 2 s or 4.4 s

[Jan Kinander]

In the description of example BLE Heart Rate Collector, it says that it can indicate state BSP_INDICATE_SCANNING and state BSP_INDICATE_CONNECTED.

In the description of BSP indication states for PCA10040 and PCA10056 it says that BSP_INDICATE_SCANNING is LED1 blinking with period 2 seconds and duty cycle 10 %.

When I run the BLE Heart Rate Collector example on PCA10040, LED1 is blinking with period 4.4 seconds and duty cycle 10 %. This is strange since

1. Accordning to the description of BSP indicate states, this blinking indicates BSP_INDICATE_ADVERTISING_SLOW.

2. The description of the example does not mention BSP_INDICATE_ADVERTISING_SLOW.

3. A Heart Rate Collector wouldn't advertise.

Can you explain this?

 

[Simonr]

Please provide details on what heart rate collector example from what nRF5 SDK version you're using when seeing this behavior and I'll take a look. 

Can you also explain more in detail on point 3? Does the heart rate collector device not advertise at all? How do you see that it is not advertising, is it not discovered by the central, or do you not see any logging information? Does the application start at all, doing initializations and so on?

Best regards,

Simon

[Jan Kinander]

You can find the Heart Rate Collector exampel in folder nRF5_SDK_17.1.0_ddde560\examples\ble_central\ble_app_hrs_c

I can see that I used the wrong words. What I was trying to say is that only BLE peripherals do advertise, never centrals - they scan, so the fact that this central indicates BSP_INDICATE_ADVERTISING_SLOW violates both the description of the exampel and fundamental BLE principels.

[Simonr]

Okay, so the central example indicates that it is advertising only by the LED1 blinking every ~4.4 seconds, is that so? The example seems to behave as intended, but I agree that the LED seems to blink way slower than at a 2 second period. How exactly are you measuring it to be 4.4 seconds?

I think this might be a documentation bug, where the period should be longer when indicating scanning than when advertising. I can assure you that the Heart Rate Collector (ble_app_hrs_c) does not actually advertise, and it's only scanning on my end at least.

Best regards,

Simon

[Jan Kinander]

Yes, it does SCANNING as it should, but according to your documentation it indicates ADVERTISING_SLOW (period 4.4 s, measured with a stopwatch: 10 flashes in 44 seconds).

So, I can see that you have to initiate a major investigation here! How do all other examples on PCA10040 and PCA10056 indicate scanning? Do they use period 2 s or period 4.4 s? What must be corrected, the documentation or the Heart Rate Collector exampel? I can't imagine that you are happy with the current situations, since it causes a lot of confusion (and our long conversation ...).

infocenter.nordicsemi.com/index.jsp

[Simonr]

Thank you for the thorough explanation and investigation. There seems to have been made some simplifications in bsp_led_indication()  by combining BSP_INDICATE_SCANNING and BSP_INDICATE_ADVERTISING, but this has not been taken into consideration in 

next_delay = indicate ==
BSP_INDICATE_ADVERTISING ? ADVERTISING_LED_OFF_INTERVAL :
ADVERTISING_SLOW_LED_OFF_INTERVAL;

This will cause the INDICATE_SCANNING to always go to "slow" mode  which is 4.4 seconds.

I have reported this issue internally, and we'll look at whether we will update the documentation or SDK to reflect this. Thank you again!

Best regards,

Simon