Peripheral connection event gives unusual measurement peaks?

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Fri, 11 Aug 2017 18:07:30 GMT

Okay I think I'm starting to get it. Thanks for helping me again Sigurd :) Slowly but steadily moving my way through the world of BLE and the Nordic way of doing it :)

RE: Peripheral connection event gives unusual measurement peaks?

Sigurd — Fri, 11 Aug 2017 11:54:18 GMT

If you are in fact sending 8 packets per interval, then I guess this is because the increased connection interval (from 7.5 ms to 30 ms) makes it possible to fit the extra packet in the event for the S130. Notice this sentence in the BLE data throughput chapter in the spec:

The SoftDevice may transfer more packets than reserved by the bandwidth configuration when data transfer is simplex (read or write only), because extra time is available in the event to transfer data.

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Thu, 10 Aug 2017 17:04:41 GMT

Okay I think that the IPhone 7 doesn't exacly give a higher throughput because I get 8 packets per interval but it seems that the minimum connection interval that the IPhone 7 supports is around 30 ms so the throughput then seems to be ((1/ 30 ms) * 1000) * 8 packets * 20 bytes * 8 = 42.67 kbps, which is much less then the maximum throughput (149.2 kbps). So I'm a bit more at ease now I think. Still don't understand why S130 allows 8 packets per interval though...

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Thu, 10 Aug 2017 16:39:51 GMT

After looking into the specs of the SoftDevice 130 I saw that 7 packets per interval could also be possible (giving a max of 149.2 kbps) when communication is just only the peripheral sending notifications to the central and nothing more (simplex communication). But so I don't understand how the DK with s130 allows the 8 packets per interval that the IPhone 7 supports...

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Thu, 10 Aug 2017 15:56:09 GMT

I honestly don't know what could have messed it up.. I'm using firmware that nRFConnect for Desktop automatically wants to install when I try to connect to the COM port that the Dongle is using. I'm using SDK 11 on my DK.

What I also tried today is connecting an IPhone 7 as a central with the DK and with that I seem to get 8 packets per interval, which could be possible because the IPhone 7 uses a fairly new BLE chip but the DK uses SoftDevice 130 which supports max. 6 packets per interval so I don't know 8 packets per interval could be possible in this connection...

RE: Peripheral connection event gives unusual measurement peaks?

Sigurd — Thu, 10 Aug 2017 15:41:00 GMT

Why do you think you messed up the firmware on the dongle ? What code are you running on the dongle? Also, what SDK version are you using?

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Thu, 10 Aug 2017 12:00:42 GMT

The data I'm sending needs 6 packets per interval if it is possible, I made sure of that, because I was/am testing maximum throughput with different connection intervals and compare the power consumption then as well :)

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Thu, 10 Aug 2017 11:59:46 GMT

No no I use a nRF51822 DK as peripheral and with the same code I have done measurements with 6 packets per interval using the nRF51 Dongle as central. But since I configured the power kit (and I think the dongle did a bit weird back then so I think I messed up the firmware or ...) I seem to not get 6 packets per interval anymore. With the Dongle as central I now always get 3 per interval and with the phone as central I get 4. I'll see if I can find a modern iOS device here to see if I can get 6 packets per interval.

RE: Peripheral connection event gives unusual measurement peaks?

Sigurd — Thu, 10 Aug 2017 11:49:42 GMT

If the phone only supports 4 packets per interval, you won't get 6 packets per interval on the link between the dongle and the phone. from this post here, it stated that it seems that most Android devices supports ~4 packets per interval, while most iOS devices supports up to 6 packets. But this also varies from model to model, newer android phones also support 6 packets per interval.

Also make sure that you set the bandwidth configuration to high in order to ensure that the nRF51 can support 6 packets per interval. See this link.

Also note that the link will only use 6 packets per interval if it's needed. I.e. if the data you are sending fits into 3-4 packets each interval, then there is no need to use 6 packets, even if it's supported.

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Thu, 10 Aug 2017 11:32:46 GMT

Okay superb! Now only to solve my 6 packets per interval problem.. :( I think I found the issue, it's not within my code but I think it's the firmware for the dongle I use. I think I'm suddenly using older firmware or something because when I measure with a phone as central (that supports up to 4 packets per interval) I get 4 packets per interval. Have you heard of this issue with the nRF51 dongle before?

RE: Peripheral connection event gives unusual measurement peaks?

Sigurd — Thu, 10 Aug 2017 11:29:23 GMT

Yes, that will add additional current consumption!

The internal pull-up and pull-down resistors on the nRF5x have a typical value of 13kohm. In order to detect button press, the buttons will be configured with internal pull-up, and when they are pressed, they will be connected to ground. If you then have supply power of 3.0 volts then the current consumption is 3/13k=230uA when the button is pressed.

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Thu, 10 Aug 2017 11:06:48 GMT

I think the unusual power consumption between intervals could be because I need to press and hold the button to make my application change the value of my custom characteristic. I'll try to change it to press and release to start changing.

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Wed, 09 Aug 2017 12:43:29 GMT

Okay, I used to get 6 packets but now I did another throughput measure and I see I'm only getting 3 now per interval. Maybe I messed something up with my code or with the firmware of the dongle, I'll see.

Not that I'm really aware of. I only use a timer to make the led blink during advertising but that's normally part of the template already I think. UART I don't use (didn't write anything for it).

RE: Peripheral connection event gives unusual measurement peaks?

Sigurd — Wed, 09 Aug 2017 12:19:16 GMT

Q: But how is it that the RX and TX events each take 3 pulses instead of 1.

A: You typically get 1 of these pulse for each packet sent during the event. With 3 pulses you are sending 3 packets.

Q:And is it normal to have 100 - 120 µA current during the time between two intervals?

A: 100 µA could be a little high, but that depends on what other peripherals that are active. Are you using the UART or TIMER ?

RE: Peripheral connection event gives unusual measurement peaks?

Mathias — Wed, 09 Aug 2017 12:00:21 GMT

Hi Sigurd!

Thanks for the clarification! :) We are testing some different connection intervals actually. But how is it that the RX and TX events each take 3 pulses instead of 1? And is it normal to have 100 - 120 µA current during the time between two intervals?

RE: Peripheral connection event gives unusual measurement peaks?

Sigurd — Wed, 09 Aug 2017 11:14:12 GMT

Hi,

The behavior looks normal to me. The radio on the nRF51 will consume ~10.5mA when in TX mode with 0dB transmit power, and with DC/DC disabled. See the table 36 in Chapter 8.5.2 page 50 in the PS. Then you have the CPU consuming ~ 4.4 mA when it’s not in sleep mode. In total this will give you a peak current around 15 mA. Note that if you enable DC/DC mode, the peak current should drop with ~2.5 mA. (radio will consume 8 mA instead of 10.5 mA). Note that with such a short connection interval as 7.5 ms, the radio will be on more often and the average current consumption will naturally increase.

If you are interested in current consumption on the nRF51, I recommend taking a look at this post.