Repository navigation
fix(luckring): omit HRV for the TK18 family (#112) - #122
Merged
Merged
Conversation
The ring sends one HRV byte per reading (types 45 live / 42 history), decoded exactly as the vendor SDK's K6_HeartStruct does, but nothing shows it is HRV in milliseconds: the TK18 in #112 sent 107-168 in one evening, masking the top bit didn't help, and no packet carries beat intervals to compute HRV from. The official LuckRing app (1.6.3) stores the byte and never shows it; every HRV screen displays AppUtils.getRomHrv(), a random value from the user's age band. - LuckRingCoordinator no longer declares HRV / MANUAL_HRV, so the HRV card and everything keyed on the capability stay hidden. Capabilities are re-stamped on every connect, so existing TK18 users pick this up on their next connection. - The history pass no longer requests type 42. - LuckRingDriver drops any HRV event the ring pushes on its own; the frame is still ACKed and still shows in the raw-packet feed. HRV rows already stored are kept, not deleted.
# Conflicts: # docs/ios-sync.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #112. The LuckRing family (the TK18 is its only model) no longer reads, stores or shows HRV.
Why
45live and42history), and we decode it the same way the vendor SDK'sK6_HeartStructdoes. But nothing shows it is HRV in milliseconds:AppUtils.getRomHrv(), a random number from the user's age band.Changes
LuckRingCoordinator: dropsHRVandMANUAL_HRV, so the HRV card and everything keyed on that capability stay hidden. The doc comment records why. Capabilities are re-stamped on every connect (RingBLEClientDeviceIdentified), so existing TK18 users get the change on their next connection with no migration.LuckRingHistorySync: no longer requests history type42. That also makes each sync one step shorter.LuckRingDriver: drops any HRV event the ring pushes on its own. The frame is still ACKed and still appears in the raw-packet feed. The decoder is unchanged, so turning HRV back on later is a small change if someone works out what the byte means.docs/ios-sync.md: records this as a deliberate divergence. iOS still declares.hrv, .manualHrv, so it's an upstream candidate.Not changed
52/53) still shows. It's the ring's own stress value, not derived from the HRV byte.Tests
./gradlew :app:testDebugUnitTest: all tests pass. NewLuckRingDriverTestcases cover two things: HRV frames on both data types are ACKed but produce no HRV events, and the coordinator declares no HRV capability. TheLuckRingHistorySyncTestcatalog check is updated.Not checked on a device.
🤖 Generated with Claude Code