- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried to modify the hello_client and hello_sensor and make them connect via "directed" advertising. However, I cannot make it connect. From the sniffer, I can see the advertising packets, but there is no connection. Could you please confirm that Directed Advertising works for SDK 2.2.1 ? If so, do you have an example?
Also, what is the unit of the parameter "low_direct_adv_interval"? Is it in second of time slot? What is the range of values? Thank you.
Solved! Go to Solution.
- Labels:
-
Scanning-Advertising
-
SDK 2.X
- Tags:
- advertising interval
- directed advertisements
- directed_advertising
- high_direct_adv_interval
- low_direct_adv_interval
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You may want to check out the "Whitelist" scheme of doing things. And the unit is in seconds, as commented in the hello-sensor.c code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I assume the duration is how long the advertising should be running. Could you please explain what is interval for (low_direct_adv_interval) ? Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
embeddedmasters does a good job of defining these values in their BCM20737S 1.3”x1.3” Breakout Board datasheet here: http://www.embeddedmasters.com/datasheets/embedded/EMRF-BCM20737S-BOB%20UserManualV1.0.pdf
We now define the High and Low Advertising Intervals. Keep in mind that the Advertising
Interval is strictly defined by the BT Sig to be a multiple of .625ms. So for the High Advertising
Interval this is defined as 32 * .625ms = 20ms intervals. The Low Advertising interval is less
frequent and is 1024 * .625ms = 640ms. We then define the High Adv duration to be 30 seconds
and the Low to be 300 seconds long. The Low and High intervals are used because typically an
BTLE device has a use case when it is user directed say by an On/Off button press and the system
knows it should be in a scenario where the user is trying to connect the device to BTLE client.
Keep in mind ONLY slaves/servers advertise it is the master/clients that see the advertisements.
Having a High and Low allows the system to send advertising packets at a fast interval to try to
establish the connection quickly. If a connection is not made within the specified High Adv
Duration then it goes into a lower power mode and advertises at a slower rate. This is entirely
user configurable and typically the user defines a callback function to determine what to do if
after the High and Low Advertising durations have expired.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The answer above is for "undirect" advertising. It is still unclear to me what interval means for "direct" advertising. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using the reply furnished by mwf_mmfae, the "Low" duration is 300s and its interval is 640ms. This statement means that it will keep on advertising once at every 640ms interval in between, for a span of 300s. Does this clear up a little?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
low_direct_adv_interval + low_direct_adv_duration = low duty cycle directed advertisement setting
high_direct_adv_interval + high_direct_adv_duration = high duty cycle directed advertisement setting
So essentially, if a connection is not made within the specified high duty cycle directed advertisement setting, the part then goes into a lower power mode and advertises at the low duty cycle directed advertisement settings.
For some reason, it always helps me to understand advertisements by thinking of them in terms of the scanning device on the other end of the connection as well: Re: scan sometimes stops working
For instance, if the Scan Interval is 100 and the Scan Window is 10, the device will scan for 10 slots (.625ms each) and go to sleep for 90 slots.
Then scan for 10 slots then go to sleep for 90...
Getting the scans and advertisements to lineup correctly so a connection can be made quickly is one of the the challenges a developer faces when designing a low power BLE application because the two devices are essentially at odds with one another:
- The master does not want to increase scan duration
- The Slave does not want to send advertisements often (i.e. think of a battery powered sensor)
- With default scan (11.25msec out of 1.28sec) and default advertisement interval (1sec) it might take a few minutes or even hours to connect
- When a slave has data to send, it initiates a high rate of advertisements
- When a master needs to connect, it uses smaller scan intervals
Directed advertisements obviously help this scenario because with directed advertisements the advertiser advertises at near 100% bandwidth. So when the central scans for the default 18 slots (11.25mS) every 2048 slots (1.28s) the advertiser is guaranteed to get the central's attention. With undirected advertisements, the advertisement packet and the scan have to line up just right or you lose another 1.28s.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, during the low_direct_adv_interval, the slave sends "multiple" advertising beacons, correct? Does the slave send as much as it can send during low_direct_adv_interval?
Also, within one cycle, it uses one same frequency band and changes to another one the next cycle. Correct?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cut and paste from the hello_sensor app:
/*.high_undirect_adv_interval =*/ 32, // slots
/*.low_undirect_adv_interval =*/ 1024, // slots
/*.high_undirect_adv_duration =*/ 30, // seconds
/*.low_undirect_adv_duration =*/ 300, // seconds
Translated:
high_undirect_adv_interval = 32 * .625ms = 20ms
high_undirect_adv_duration = 30 seconds
low_undirect_adv_interval = 1024 * .625ms = 640ms
low_undirect_adv_duration = 300 seconds or 5 mins
So essentially, if a connection is not made within the specified high duty cycle directed advertisement setting (advertisements sent every 20ms for 30 seconds)
The part then goes into a lower power mode and advertises at the low duty cycle directed advertisement settings(advertisements sent every 640ms for 5 minutes).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The question is about "direct" advertising. How many beacons are sent during one "interval"?
I am asking because "advertising interval" is well defined for "undirect" advertising. Each interval has one advertising event. There are three beacons per event (interval) and each beacon uses different frequency bands. However, there is no "interval" definition in the "direct" advertising... So, I am not sure if it is also three beacons per "interval" or the slaves sends as much as it can during one interval.
I understand the high duty cycle will run before the low duty cycle based on duration setting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I spoke to the developers and they confirmed that what I am calling an advertisement is actually an advertisement event - which is 3 packets sent one after another on 3 advertisement channels (as you noted).
As it turns out, for directed advertisements there is no interval and servers are supposed to send them as fast as possible for a much shorter duration.
They believe that this is fixed in BT 4.2 and directed advertisements should be formed similar to undirected advertisements (similar to what I described).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content