How can I measure the advertising intervals of a peripheral?

RE: How can I measure the advertising intervals of a peripheral?

endnode — Thu, 20 Jul 2017 23:40:01 GMT

If you are pro and your company has spare $4k-$15k then having one of these sniffers solves most of your question. Otherwise with little bit of learning and patience nRF51 DK board with Nordic Sniffer SW will do such simple job as well (until you stay with BT4.0-4.2).

RE: How can I measure the advertising intervals of a peripheral?

ChipChipperson — Thu, 20 Jul 2017 23:35:08 GMT

Clearly I'm not asking a question that cannot be answered concisely, nor obviously am I interested in edge cases, right? Generally, I'm just inquiring after the possibility of measuring the frequency of data packets sent from a peripheral to a central, in any given scenario (device/chipset, etc). For maximum groking, procurement of either an Frontline or Ellisys is in order :) Thanks again!

RE: How can I measure the advertising intervals of a peripheral?

endnode — Thu, 20 Jul 2017 20:59:24 GMT

...(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;)

RE: How can I measure the advertising intervals of a peripheral?

endnode — Thu, 20 Jul 2017 20:53:06 GMT

...(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 ...

RE: How can I measure the advertising intervals of a peripheral?

endnode — Thu, 20 Jul 2017 20:46:19 GMT

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)

RE: How can I measure the advertising intervals of a peripheral?

ChipChipperson — Thu, 20 Jul 2017 18:52:52 GMT

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!

RE: How can I measure the advertising intervals of a peripheral?

Petter Myhre — Thu, 20 Jul 2017 08:02:35 GMT

@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.

RE: How can I measure the advertising intervals of a peripheral?

endnode — Wed, 19 Jul 2017 20:58:40 GMT

Oh and if you really wants to know PPCP (aka Preferred Peripheral Connection Parameters) as you indicate above that should be visible after connecting to GATT Server right under GATT Primary Service.

RE: How can I measure the advertising intervals of a peripheral?

endnode — Wed, 19 Jul 2017 20:54:16 GMT

To connection parameters (which is quite different story so it looks like you are mixing several things into one question):

You can read it precisely from RF packet sniffer because it's in CONNECT_REQ packet and then it can be changed later but always explicitly by Master (GAP Central device) by LL command so you can again see the value in the log.
You can also observe it on upper layers if LL/GAP API allows it. I'm afraid that's not the case on Android or iOS (but I suggest to verify in API documentation) but you can again measure it indirectly if devices exchange one packer each interval you can measure time in the app, it should be pretty close to reality.

RE: How can I measure the advertising intervals of a peripheral?

endnode — Wed, 19 Jul 2017 20:52:03 GMT

I've updated my answer. As Petter mentioned this indication is only measured and displayed by Android app. There is no way to find out Adv. Interval, app is just measuring deltas between received events from lower Android BT stack (through API) and it displays it. As explained if you want exact value you either need to know it from app developer or you need to run some larger statistics (dozens of packets) and precise time measurement with some more professional 2.4 GHz (BLE PHY enabled) analyzer ("sniffer" if you want) and take average value (assuming interval is not changing over time and that you don't miss any packet).

RE: How can I measure the advertising intervals of a peripheral?

ChipChipperson — Wed, 19 Jul 2017 18:14:16 GMT

Hi Petter, thank you for the response and info. I am basically just trying to find out how frequently my peripheral is sending out data (from a sensor). Regarding the link here, I'm not clear on where I would be viewing evt.gap_evt.params.connected.conn_params.max_conn_interval, etc

RE: How can I measure the advertising intervals of a peripheral?

endnode — Wed, 19 Jul 2017 08:26:56 GMT

Yes, pretty much any BLE Peripheral examples do it, e.g. there is examples\ble_peripheral\ble_app_beacon (but runs only on PCA10040 aka nRF52 DK, otherwise you need to do small modifications)

RE: How can I measure the advertising intervals of a peripheral?

Petter Myhre — Wed, 19 Jul 2017 06:49:29 GMT

nRF Connect for Android shows this in the scan window, next to the RSSI. I don't think the iOS app shows it. Could you explain exactly what you want to achieve? You can configure the advertising interval, so you can select how often you want advertising packets to be sent out. Data packets is a bit more complex, but finding the connection interval isn't hard. See this. If you want to see what is actually happening on air you need to use a Sniffer. The best would be a commercial one, from for example Frontline or Ellisys. Or you can use our nRF Sniffer (it has some issues, but it is free)

RE: How can I measure the advertising intervals of a peripheral?

ChipChipperson — Wed, 19 Jul 2017 00:00:32 GMT

Thanks for the response. Do you happen to know of any examples in the NRF52 SDK that show an example of very frequent advertising or data packets being sent as a peripheral?

RE: How can I measure the advertising intervals of a peripheral?

ChipChipperson — Tue, 18 Jul 2017 23:18:10 GMT

Where though? I see the RSSI reading (usually some fluctuating number like -86 or something), but where do you see the actual advertising interval frequency? Is that the X axis at the top of the RSSI graph (maybe in seconds) ?

RE: How can I measure the advertising intervals of a peripheral?

Daniel Wang — Tue, 18 Jul 2017 21:11:59 GMT

You don't need a sniffer to check this. A very easy way to check the advertising interval is to use the nRF Connect app on your smartphone. when scanning for devices, the adverising interval will be listed together with the name of the device and RSSI.

RE: How can I measure the advertising intervals of a peripheral?

endnode — Tue, 18 Jul 2017 08:34:21 GMT

BLE devices are normally identified by 6-byte Adv. Address (MAC). By using good sniffer you can easily follow advertisers and deltas between packets they send (note that BLE broadcasting has some mandatory jitter from specification so you will wither "tip" the actual adv. interval or you will need some larger statistics to be "almost sure"). If you have problems to identify MAC address of your target (e.g. because it changes it to be pseudo-anonymous or because you have too many devices in the field) then moving to quieter place and using RSSI indication to see which is the closest device or at least which is moving when you move with your target should solve it.

Update

Some screenshots from nRF Connect mobile app (note that this applies only to Android version, iOS seems lacking this indication according to Petter). As you see beside graph view it computes delta between ADV events in list view for each advertiser (152ms in this case, I would guess real value is 150ms exactly):