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

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,