BLE_GAP_EVT_ADV_REPORT event condition?

[cl]

Hi.

I'm currently working on hrs_scanner example and have a question.

I'm working on latest nrf5 sdk11.0

and hrs_scanner example is in the 'ble_peripheral/experimental_ble_app_multiactivity_beacon/'.

The example, 'hrs_scanner', is consist of two scanner_beacon.c file.

One is scanning BLE GAP advertise packet using softdevice(?) event handler.

The other is scanning it using timslot API.

And it seems like timeslot API is accessing lower level interrupt than softdevice example.

The example using timeslot API has a Radio event handler which is called on advertise packet event for each three channels(37,38,39).

But event handler in the example using softdevice called only once for three channels. (that's what I checked through several tests.)

Then, what is the trigger condition of BLE_GAP_EVT_ADV_REPORT event?

Is it triggered when there's at least one advertise packet for three channels?

Or is it triggered when all of three channel receives advertise packet?

If it's the first case, can I change the triggering condition?

p.s. nrf52 Keil pack is not updated for this 'hrs_scanner' example. When it will be?

[tesc]

Hi,

The BLE_GAP_EVT_ADV_REPORT event is triggered as soon as the scanner receives an advertising packet.

Advertising can be visualised like this, using channels a, b and c:

    time -->
Scanner:         aaaaaaaa        bbbbbbbb        cccccccc
Advertiser:  abc          abc          abc          abc

The advertiser advertises in small bursts, each time sending one packet on each channel. The scanner scans one channel at a time, but for longer periods of time and with a longer interval. Sometimes they use the same channel at the same time, and those times the scanner successfully reads an advertising packet.

In the example above the BLE_GAP_EVT_ADV_REPORT event is first triggered while scanning on channel b. The scanner receives an advertising packet again while scanning on channel c, which wil trigger another BLE_GAP_EVT_ADV_REPORT event.

See also the Scanning Message Sequence Chart.

Regards, Terje