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,

[Simonr]

Hi

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

[mmnano]

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

[Simonr]

Hi

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

[mmnano]

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,

[Simonr]

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.

HRS_SPEC_V10.pdf

Best regards,

Simon