How can I measure the advertising intervals of a peripheral?

[Malvin2000]

I would like to know how frequently my peripheral is sending advertising and data packets. I've tried using ble-sniffer-osx but it doesn't actually reveal any device names for some reason, so it's not trivial to use. Is it possible to do this using Xcode's Bluetooth Explorer utility to do this?

[Petter Myhre]

@ChipChipperson It is still unclear to me if you are talking about advertising interval or connection interval. If you want to measure any of them you should use a sniffer.

If you want to configure (and then know) the advertising interval you can modify what is typically defined as APP_ADV_INTERVAL or similar in our SDK examples.

In regards to connection interval, you would typically view it using a debugger or by printing it.

P.S. The connection interval doesn't necessary tell you how often you are sending data to the peer, it tell you how often you can send data to the peer.

[ChipChipperson]

Thank you both for your responsiveness and information/guidance, very much appreciated. I am only about a few weeks into groking BLE and it is certainly not a trivial protocol, so all the help is great, thanks again.

To your point @endnode yes, I may have been mixing two different aspects of the connection protocol into one, I think. What I wanted to be asking was two-fold: how do I measure the frequency of advertising packets ? AND How do I measure the frequency of data packets (with data form a sensor) being sent from the peripheral to central? Just to be clear, I'm assuming that by "connection interval" that is referring to the frequency of data packets being sent, yes?

Yes, APP_ADV_INTERVAL is what I was looking for, thank you!

[endnode]

I'm afraid you won't be happy with my answer: it's more complex then this;) Briefly:

• In Broadcasting/Scanning phase (Advertising) should advertiser periodically send either one or 3 packets (if one then it should rotate all 3 adv. channels, if 3 then it should send one per channel in short sequence and then wait another advertising interval).
• This is normally valid but note that a) broadcaster can decide to avoid some adv. channels (for whatever reasons but typically to reduce power consumption), b) if it is scannable advertisement then it can after any ADV_xxx packet receive active SCAN_REQ which means that it will send out another Tx packet with up to 31B of payload, c) broadcasting shouldn't be really taken as clear data transport because it's unreliable and by default there is no way to find out if data reached the listener or not, d) in BT 5.0 it becomes more... (1/x)

[endnode]

...(2/x) complicated in terms of packet size, numbers, data rate etc. and e) with new BT SIG mesh broadcasting can offer even more complex situations then this.

• In connection based link it becomes again complex because there are suddenly much more layers involved.
• In general there is some basic period called "connection interval" where both sides of (asymmetric) link exchange typically one packet. This happens even if there are no effective data, simply they exchange empty PDUs containing only Link Layer and PHY headers. Do you count this into your analysis?
• To make it worse if there are higher layers active they can (if both sides of the link support it) exchange suddenly more PDU pairs within one interval (it's not uncommon that good BLE stacks support 6 o even more packets per interval when needed).
• To make it total mess for you there are link parameters which may ...

[endnode]

...(3/3) permit to save power on slave (GAP Peripheral) side of the link and in case that there are no higher layers active one or more connection intervals can be "missed" meaning that device will sleep and neither Tx nor Rx activity happens.

• And to continue with complexity higher standards then BT4.0 introduced features such as PDU length extension, ATT_MTU length extension (just higher layer;) and recently also different on-air speeds (2Mbps) and PHY codings (500/125kbps).

So this is basic overview. I hope it's more clear why it is hard for us to answer your "simple" questions, they simply doesn't make much sense in BLE context;)