ANT Forum

Going by the device profile for heart rate monitors the msb of the first byte means: Transmitter must toggle this bit every 4 messages. Receiver may not interpret bytes 0-3 until it has seen this bit set to both a 0 and a 1.

That implies if you want to measure HRV and so the message period is set to 8070 then bytes 0-3 should only be read every 8th message .While that makes sense for page 0, 2, 3 and maybe 1 it seems as though bytes 2-3 are important in page 4 to check every time a page 4 is received. (this appears to be the main page transmitted from a garmin soft HR strap) Is this a bug in the spec or am I missing something?

Also I'm not sure I understand the point of page 4. Is it just in case there are dropped packets, the heart rate is too fast or not wanting to have to store any data about the previous packet? Seems like you can just have a variable that holds the beat count and beat event time and when a received packet has an incremented beat count just compare the beat event time in the received packet to the stored time to get HRV. Or is it so you can still poll at a lower rate and so get a sampling of HRV instead of a full measurement?

I'm a newbie at this so trying to understand and guessing I'm missing some things. Thanks      

Hi enki,

Thanks for taking the time to read the device profile before asking .

The heart rate profile is one of our oldest profiles and has a few features that you won't see in newer profiles, such as the page toggle bit. The toggle bit is used because the original profile did not use paged data, and so the original receivers would not expect different pages to be sent. Similarly the oldest heart rate straps would only send page 0 and not toggle the top bit. In addition the values sent in bytes 0-3 were unspecified (but constant) values.

As device profiles remain backwards compatible with existing devices, the toggle bit was introduced when bits 0-3 were defined and page numbers were introduced. The purpose of the toggle bit is to distinguish newer devices that use page numbers, from older devices that have undefined values in bits 0-3.

So, as a display, you need to see the top bit toggle between zero and one before you interpret bytes 0-3, but you only need to see this happen once for a particular HR device. After that you can interpret pages as normal because you know you are working with a device that uses page numbers.

Page 4 is very similar to page 0, and you are correct it used to protect against packet loss, which would become more important at high heart beat counts. This is generally a good idea because, there are likely to be some missed packets if a heart rate strap is worn by a runner (for example), because for part of each stride, the runner's wrist is likely to be behind their body, and so the signal is blocked for that time.

Hope that makes it all clear,

Kat      

Guess its hard to see how many dropped packets there are in reality when sitting next to my laptop wearing a heart rate strap. (seems like it would be easy to have a half wavelength flexible antenna in the cloth part of the heart rate strap but maybe not worth it)

So does this mean that if the first bit toggles (guessing the ever 4 messages allows for dropped packets and slower receive polling) then I can assume its a newer device that supports paging and if it doesn't toggle then its an old device with only page 0? So this could be determined while pairing the strap and saved as a flag with the other data needed for pairing?

So if the device doesn't support paging then only page 0 is sent every 8070/32768 a second.

If a device does support paging then every 8070/32768 a second then page 0 or page 4 is sent with every 65th message replaced with either page 1,2, or 3 as background data? But that bring up two questions: If you're sampling at 32280 counts then it would seem like it would be very easy to miss the background page. If background pages 2 and 3 are required but a singular background page is sent every 65th message then how are the background pages supposed to be spread out?

So if I want to record r-r intervals then I think 5.3.6.3 should have an else block to the if statement where it would check if the current page is page 4 and then use the data inside that page to calculate the r-r interval. (Wonder if its better to ignore the interval data that got lost or average the before and after intervals to insert in its place, but guess I can figure that out later)

Thanks for taking the time and clarifying my assumptions.      

Hi!

Yes, you could save the toggle info when pairing with a device.

Yes, for non-paged devices, only page 0 would be sent.

If pages 1, 2, and 3, are being sent then it the pattern would be: send 64 main pages, send page 1, send 64 main pages, send page 2, send 64 main pages, send page 3, send 64 main pages, send page 1 etc.

If pages 2, and 3, are being sent then it the pattern would be: send 64 main pages, send page 2, send 64 main pages, send page 3, send 64 main pages, send page 2, send 64 main pages, send page 3 etc.

Note that these patterns are device profile specific so this only applies to HR.

Yes, this would make it likely that you would miss some of the background pages if receiving at a lower rate. However as the manufacturer info does not change between messages this may be deemed an acceptable trade off for the lower power consumption by the display. If you did want to pick this information up more quickly then you could receive at 4Hz until all the background pages had been seen before switching to a slower receive rate.

The code is a simple example only, and you are welcome to create a more robust version.

You're welcome. Hope your project goes well.