Beacon Advertising with 20msec Interval

[FA]

Hi,

As discussed here a way to advertise each 20msec is changing the mode to BLE_GAP_ADV_TYPE_ADV_IND. This is a connectable mode and assume we do not want a connection happen at all.

I don't know if there are ways to program the advertiser to reject all connection (maybe by using whitelist), but again if we can't do this, please comment on the following approach:

• We are updating advertising data by using radio notifications (discussed here)
• What if we configure the mode to be BLE_GAP_ADV_TYPE_ADV_NONCONN_IND with 100msec interval, and after each advertisement when we receive the radio inactive notification, we disable the radio and in 20msec after that again enable and start the advertisement.

Expectation is that with this method we should get non-connectable advertisements with 20msec interval. I know that this sounds against the BLE spec for non-connectable advertisements, which I don't know what was the reason of setting this limit while connectable ones can go down to 20mses, i.e., there isn't any hardware limitation for that.

But, I want to know if this is feasible, what could be the downsides of it? Does disable/enabling the radio consumes a lot more power compared to programmed intervals?

[endnode]

Hi, I find this possible (beside the fact that you might have problem to tune starting procedure in order to match your desired interval - btw. will you also add timing variance as expected by BLE spec or you are planning to violate this as well?;). However you can also go with standard way: use connectable advertisement @20ms and if anyone connects terminate it straight away at BLE_GAP_EVT_CONNECTED event.

Cheers Jan

[Phil Young]

I have been considering the same issues since the BT specification states that the minimum gap for ADV_NONCONN_IND should be 100ms, however I also noted that CSR state a latency of 15ms node to node in CSRMesh, yet they also state in their webinar that they are using this packet format, and in their patent application also. I read elsewhere that there was to be a rev4.3 spec for Bluetooth which would include support for meshing in BT_LE, so is it possible that this parameter will be reviewed in the next spec revision ?.