How does nRF Connect interpret the RR Intervals in nRF Connect?

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

Simonr — Thu, 16 Dec 2021 12:21:32 GMT

Hi again

After some further debugging on the Android side, we found a bug in the nRFConnect application where a rouge offset causes these two bytes not to be printed by the nRFConnect log.

Thank you for reporting this and helping us reproduce it so we could get to the bottom of it. This fix will hopefully find its way into the next update of the nRFConnect for Android scheduled early next year.

I'd also like to thank you for your persistence.

Best regards,

Simon

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

mmnano — Thu, 16 Dec 2021 10:27:32 GMT

Hello,

Thank you again for your time on this.

As I said previously, the spec does not explicitly say that you need to put RR intervals from byte 2 onwards.

It is interpretation of (GATT Specification Supplement 5 – Bluetooth® Technology Website):

and:

"For a 23-octet ATT_MTU and the Heart Rate Measurement Value format set to UINT16, when notifying the Heart Rate Measurement characteristic, the maximum number of RR-Interval values that can be contained within a single Heart Rate Measurement characteristic with Energy Expended is 7 and the maximum number of RR-Interval values that can be notified if Energy Expended is not present is 8."

+ "The number of RR-Interval sub-fields present is determined by a combination of the overall length of the characteristic and whether or not the characteristic contains the Energy Expended field" (in GATT Specification Supplement v5)

In the table, EE is of size 0 when the flag for it is deactivated. And it is said multiple times that the number of RR-Intervals in the packet depends on whether EE is activated or not.

All this can only mean that if EE is not present (flag deactivated), RR-Intervals start at byte 2 (Heart Rate Value set to uint8) or byte 3 (Heart Rate Value set to uint16). This is because the packet is constrained. The max number of RR-Interval is increased by 1 (uint16) when EE is not present (uint16 too). This can only mean that RR-Intervals start 2 byte earlier in the packet. How is it possible otherwise ?

I cannot make it clearer than that. You could say it is a matter of interpretation, the documentation is indeed not very clear.

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

Simonr — Thu, 16 Dec 2021 09:48:51 GMT

I am discussing this with a colleague, and we're not able to see where the specification says that RR intervals should be from byte 2 onwards, in 2 byte format, could you point to it? We're currently investigating why the nRFConnect app is not printing the first RR interval, but don't have a conclusion yet. Thank you for your patience and thorough feedback. I've been able to reproduce it on my end, so it's not specific to your specific phone at least.

Best regards,

Simon

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

mmnano — Wed, 15 Dec 2021 08:16:51 GMT

Hello

Here is a sample (build folder inside also has a .hex for nrf52840dk_nrf52840): devzone.nordicsemi.com/.../Peripheral_5F00_RR_5F00_Interval_5F00_nRF_5F00_Connect_5F00_App.zip

It alternates between sending the RR Intervals from byte 2 and byte 4 while keeping the EE flag deactivated.

It shows this behavior:

The RR-Interval with value 0x15e (341.80ms) is thus ignored on the display when place on byte 2 but not when placed on byte 4.

I am using Android. As far as what I tried, iOS does not seem to offer an obvious way to interpret a heart rate measurement packet.

Best regards,

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

Simonr — Wed, 15 Dec 2021 06:47:51 GMT

That's true, can you double check that the energy expended bit is actually disabled in your application? Do you have a second nRF52 device that you can use as a HRS central device to connect and see if you're able to print RR-values from there as well, so we can see if this issue is specific to the nRFConnect app or not. Or alternatively do you have a .hex file of the app I can test to reproduce this on my end?

Are you using the Android or iOS version of the application. Let me know and I'll ask the app developers if they're aware of something like this.

Best regards,

Simon

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

mmnano — Tue, 14 Dec 2021 10:07:34 GMT

Hello,

Thank you for your time on this.

The paragraph that makes me hesitate is this one (page 12 of 15):

For a given MTU size, the maximum number of RR-Interval that can be fit changes depending on if Energy Expended is present or not. That can only mean that 1 RR-Interval measurement is put where EE should be (bytes 2 and 3) ! I don't see any other way to go from 7 to 8 RR-Interval within a constrained packet ?

Best regards,

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

Simonr — Tue, 14 Dec 2021 09:34:12 GMT

Hi again

I'm not able to see where in the HRS specification it's stated that bytes 2 and 3 should be used for RR intervals if the EE bit is set to 0. Aren't these for the EE field, and thus when the EE bit is set to 0 these bytes are ignored, and only the later bytes are printed by the central app. At least that's my understanding. Let me know if I missed something.

devzone.nordicsemi.com/.../HRS_5F00_SPEC_5F00_V10.pdf

Best regards,

Simon

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

mmnano — Mon, 13 Dec 2021 07:31:25 GMT

Hello,

The data packet is constructed in a straight forward way.

A Packet where byte 02 and 03 are ignored: 10-BA-F2-03-18-01-22-FA-00

0x10: Byte 01 is the flags. Bit 4 is true for indicating that RR-Intervals are present and Bit 3 is false for Energy Expended deactivated. Bit 0 is false for heart rate in the uint8 format

0xBA: Heart Rate measurement value.

0x3F2: RR-Interval

0x118: RR-Interval

0x0FA: RR-Interval.

This number of RR-Intervals is very much within what the packet should be able to handle (which is 7 to 9 I believe).

The thing is nRF Connect does not display 0x3F2 despite Energy Expended flag being deactivated. Seems like the fact this is ignored: when EE is deactivated the RR-Interval part should start at byte 2 and not 4 (as per the spec).

If you send the same packet with 0x0000 at byte 2/3 (10-BA-00-00-F2-03-18-01-22-FA-00), suddenly 0x3F2 is displayed correctly.

Best regards,

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

Simonr — Fri, 10 Dec 2021 08:35:27 GMT

What seems to be happening is that it's not room for all the RR-iterval values. From the spec.:

"If more RR-Interval values are measured since the last notification than fit into one Heart Rate Measurement characteristic, then the remaining RR-Interval values should be included in the next available Heart Rate Measurement characteristic"

Can you show me what your data packet looks like on the nRF side as well as where you have disabled this Energy Expended bit?

Best regards,
Simon

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

mmnano — Thu, 09 Dec 2021 13:23:30 GMT

Take the first values on the first example.

Per specs, RR intervals should be from byte 2 onward, in 2 byte format.

So I should have 0x3f2, 0x118, 0x122 and 0xfa as RR intervals. This corresponds to 986ms, 273ms, 283ms and 244ms.

As seen on that first screenshot, the 0x3F2 (986ms) is ignored, not the others. Kind of like the RR intervals are only read from the byte 4 onward, which would happen if Energy Expended would be activated. But, Energy Expended flag is not activated.

On the bottom screenshot I manually code the RR intervals to be on byte 4 onward in the packet. No value is ignored there, it once again acts like byte 2 and 3 are Energy Expended (but the flag is not set which means that no energy expended field is shown).

RE: How does nRF Connect interpret the RR Intervals in nRF Connect?

Simonr — Thu, 09 Dec 2021 13:15:00 GMT

Sorry if I'm misunderstanding, but where do you see that the RR interval values are ignored? In both these screenshots it seems to me that RR values are printed as they should. What exactly are you expecting in the top screenshot that you are able to see in the bottom one?

Best regards,

Simon