What problem does this solve?
The YCBT body-data record (05 33) carries a full HRV panel alongside the single HRV scalar. YCBTHealthRecords.bodyData documents every offset in its doc comment — sdnn:u16@14, pnn50@17, rmssd:u16@18, lf:u16@20, hf:u16@22 — and then walks straight past them, because there is no MeasurementKind to put them in:
Load index, sympathetic tone, SDNN, pNN50, RMSSD and LF/HF have no MeasurementKind; they are left on the floor rather than force-fitted into one.
Neither Oura nor Ultrahuman surfaces this breakdown — both show one HRV figure. On a YCBT ring this is a straight win over a $349 device, using bytes already arriving.
Proposed solution
Add the six kinds, range-gate them in RingEventBridge, and surface them behind a new .hrvDetail capability.
The capability should ride IS_HAS_PRESSURE (byte 22, bit 6) — the bit the vendor SDK gates the whole 05 33 query on, and therefore the same bit .stress and .fatigue already ride. Not ISHASHRV: that governs the scalar, which arrives from 05 09 and the 06 03 live stream, so a ring can have HRV and still have nothing to break it down.
LF/HF should be computed from the two powers, not read from @24. That byte is a single value standing in for a ratio whose real range is ~0.5–3, so it carries an implicit scale the SDK never states; whatever common scale LF and HF share cancels in the quotient.
Keep it off Today and Vitals — six more dashboard tiles would bury the metrics people open the app for. Two taps in from the HRV detail screen is the right depth.
Area
Data / decoding / sync
What problem does this solve?
The YCBT body-data record (
05 33) carries a full HRV panel alongside the single HRV scalar.YCBTHealthRecords.bodyDatadocuments every offset in its doc comment —sdnn:u16@14,pnn50@17,rmssd:u16@18,lf:u16@20,hf:u16@22— and then walks straight past them, because there is noMeasurementKindto put them in:Neither Oura nor Ultrahuman surfaces this breakdown — both show one HRV figure. On a YCBT ring this is a straight win over a $349 device, using bytes already arriving.
Proposed solution
Add the six kinds, range-gate them in
RingEventBridge, and surface them behind a new.hrvDetailcapability.The capability should ride
IS_HAS_PRESSURE(byte 22, bit 6) — the bit the vendor SDK gates the whole05 33query on, and therefore the same bit.stressand.fatiguealready ride. NotISHASHRV: that governs the scalar, which arrives from05 09and the06 03live stream, so a ring can have HRV and still have nothing to break it down.LF/HF should be computed from the two powers, not read from
@24. That byte is a single value standing in for a ratio whose real range is ~0.5–3, so it carries an implicit scale the SDK never states; whatever common scale LF and HF share cancels in the quotient.Keep it off Today and Vitals — six more dashboard tiles would bury the metrics people open the app for. Two taps in from the HRV detail screen is the right depth.
Area
Data / decoding / sync