Possible to just receive SCAN request, but not send SCAN response?

RE: Possible to just receive SCAN request, but not send SCAN response?

endnode — Sat, 26 Nov 2016 13:20:36 GMT

Hi Thierry,

Don't know the answer, just recommending to open new question, this is what Nordic guys want on this forum (I'd like to see related topics to follow one thread and not having similar questions posted again and again but it seems impossible to run this model on this forum so to get any attention just open new question;)

Cheers Jan

RE: Possible to just receive SCAN request, but not send SCAN response?

ThierryQ — Fri, 25 Nov 2016 17:26:40 GMT

Hi,

Alternatively would be nice to compare if using non-connectable and non-scannable advertisement doesn't reduce power consumption

Is there any way to set softdevice s132 as non-scannable ? I found a way to set it as non-connectable with ADV_NONCONN_IND or ADV_SCAN_IND however I didn't found any way to set is as "non-scannable" I would like to ignore SCAN_REQ and only accept connection request.

In fact I would like the exact reverse of: ADV_SCAN_IND, I would like to won't accept scan request but accept connect request.

Is there anyway to do that with softdevice ?

Thank you

RE: Possible to just receive SCAN request, but not send SCAN response?

Ole Bauck — Tue, 23 Feb 2016 17:25:08 GMT

RX listening part is not there for non-connectable (non-scannable) advertising. It will send out an empty scan response packet if a scan request is received. Based on measurements it will turn on RX for approx 120us after every advertisement packets (on all channels), if it receives a scan request it will turn on RX for approx 250us and then turn on TX for approx 200us. I leave it up to you to calculate the increase in current.

RE: Possible to just receive SCAN request, but not send SCAN response?

endnode — Sun, 21 Feb 2016 16:58:42 GMT

And of course you need some confirmation from Nordic about exact power profile for non-scannable peripheral (if Rx listening part is still there or not).

RE: Possible to just receive SCAN request, but not send SCAN response?

endnode — Sun, 21 Feb 2016 16:57:00 GMT

(2/2)

If you still want some "back of the envelope" model then see power profile for particular soft device event at Infocenter (e.g. this) + timings and typical power consumption values in Product Specification(s) at the same place. Some figures and profiles can be also seen in practical guide to current measurement here.

Cheers

RE: Possible to just receive SCAN request, but not send SCAN response?

endnode — Sun, 21 Feb 2016 16:47:58 GMT

This has many input parameters: are you using nRF51 or nRF52? What Tx power level you gonna use (+4/0/-4/... dBm)? Do you simplify your problem to "infinite" advertising case or you are comparing different duty cycles/power modes? And last but not least what are real power consumption characteristics of your HW (they can differ significantly making even "rough" models invalid)? I'm not HW guy and if this is really critical parameter of your product then I suggest to quickly prototype the FW on nRF5x DK and measure real consumption there. This will be probably faster then elaborating on it theoretically (and saves you some sleepless night during weeks between you decide on the model and wait for the real HW to verify it).

(1/2)

RE: Possible to just receive SCAN request, but not send SCAN response?

Brian — Sun, 21 Feb 2016 14:57:20 GMT

Thanks! This is really helpful. Roughly... how much more power is consumed by turning on the RX path after TX and making the beacon scannable with BLE_GAP_ADV_TYPE_ADV_SCAN_IND? Is it doubling the power for each TX? Thanks, Brian

RE: Possible to just receive SCAN request, but not send SCAN response?

endnode — Sun, 21 Feb 2016 14:10:06 GMT

Hi Brian,

Short answer is NO, it isn't possible to detect the SCAN_REQ but not letting SCAN_RESP going out.

If you indicate to the stack that your GAP Peripheral is scannable then it automatically handles SCAN_REQ packets and replies with SCAN_RESP burst. You can get indication that SCAN_REQ packet arrived but you cannot forbid Soft Device from sending the reply. You can limit the Tx power by providing empty data (to be precise srdlen parameter set to 0) in sd_ble_gap_adv_data_set function call (see Soft Device API specification here) which will result in empty SCAN_RESP packet, but still basic packet structure will be built and sent. Btw. is the Tx for such reply really a problem? I guess you would like to safe Rx window after every advertisement Tx burst, that can make significant power consumption over Beacon's life-time. But if you are implementing mechanism where you stop advertising completely (or for some longer time) if you detect scanning activity (maybe by some specific Central address?) then that small Tx current before you go to sleep looks negligible to me. However by experiment you cannot force Soft Device to be listening to SCAN_REQ but not sending the SCAN_RESP automatically and I assume this is in order to be BT SIG compliant. If you really need full answer then wait for Nordic guys to look into Soft Device code (if there could be the way to trick it;). Alternatively would be nice to compare if using non-connectable and non-scannable advertisement doesn't reduce power consumption (I assume Soft Device then don't perform short Rx window after each Tx advertisement burst but this would need confirmation from Nordic team) enough to stop bothering about scanning and implementing some "silent" windows (btw. you really stop advertising indefinitely after very first scanning detection? That looks like a deadlock;).

Cheers Jan