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

[mmnano]

Hello,

I was trying out sending RR intervals on the Heart Rate Measurement service and seeing what happens in nRF Connect. But, something is weird with the way the values are interpreted in the app. The flag for Energy Expended is set to 0, so there should not be any in the packet. But if bytes 2 and 3 of the hrm packet are used to send RR intervals , they are just ignored:

Whatever RR interval is in bytes 2 and 3 is straight up ignored.

Here is another example with putting RR intervals values from byte 4 onward instead of byte 2 onward:

This time, no RR Interval value is ignored!

This is the table from the spec as reference:

Could somebody explain what I am doing wrong ?

Thank you for your help.

Best regards,

[mmnano]

Hello,

Thank you for your time on this.

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

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

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,

[Simonr]

Hi

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

[mmnano]

Hello

Here is a sample (build folder inside also has a .hex for nrf52840dk_nrf52840): Peripheral_RR_Interval_nRF_Connect_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,

[Simonr]

Hi

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

[mmnano]

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.