SR08 / JRing: sleep history missing because day-offset 0 is never requested

[srinikandala]

Problem

On an SR08 using the JRing/56ff driver, steps and other readings sync but Sleep remains empty even after overnight wear. The ring's own display and JYouPro both show sleep for that night.

The evidence points to the history request's second byte being a day offset, not a number of days to fetch. PulseLoop requests 0x10/03 on the first pass and 0x10/01 on later passes, but never explicitly requests today with 0x10/00.

Environment

• Ring: SR08; reported firmware 0001004CV206
• Driver: JRING / 56ff
• Phone: Samsung SM-S928U1, Android 16
• Working companion: JYouPro 3.39.18 (638), package com.jaga.ibraceletplus.aigoband (not J Ring)
• Reproduced on a locally built PulseLoop baseline 9723bdb563d6d40b5b4475e8e5e6e8faa61fd825, with a separate debug identity
• The same request logic remains in upstream main at ae2224138719aa02a634f7a79c40ec9cd3a88716; the complete latest-main app was not hardware-tested

Reproduction

1. Wear SR08 overnight and confirm sleep exists on its display/companion app.
2. Close the companion app to release its connection.
3. Connect in PulseLoop using JRing and sync.
4. Activity/HR arrive, but no sleep appears.

Expected: retrieve the current day's sleep history, with older days fetched separately when backfilling.

Code and vendor evidence

• JringDriver startup requests use historyDaysForThisPass() (3 initially, 1 later).
• RingEncoder describes byte 1 as a count.
• Inspecting the installed JYouPro APK: FragmentMain.autoSync computes an offset from the last sync date and permits 0 for today. DupMainActivity.onGetMultipleSportData decrements P_SYNC_HISTORY_DAY and calls getDataByDay(1, offset) for each remaining day through zero.
• SDK BluetoothLeService.a(int, int), reached via getDataByDay, emits 0x10, offset for activity/sleep and 0x16, offset for HR.

There is also a sequencing difference: JYouPro resets a 2000 ms idle timer on each 0x10/0x11 reply and requests HR after that stream becomes quiet. PulseLoop initially sent HR roughly 30 ms after starting activity/sleep history.

Device test results

• Original behavior: repeated history requests, activity/HR replies, no 0x11 sleep replies.
• Timing-only prototype: delayed HR by about two seconds, but sleep was still missing.
• Next prototype: explicitly requested offsets 0, 1, 2 separately, preserving the sequential activity/sleep → HR flow. The capture then showed 27 0x11 sleep-timeline entries after 0x10/00, and sleep appeared in the app. The owner confirmed it worked.

This supports fixing the day selection, not simply increasing a presumed history count. The prototype fetched today first; the vendor backfill counts down to today. Validation is limited to this SR08.

A separate duration discrepancy on the older baseline was traced to counting a gap as sleep. Latest upstream already uses asleepMinutes/spanMinutes and has a duration repair, so that is not proposed as another change here.

Raw health diagnostics, device identifiers, and the vendor APK are not attached. The useful control bytes and findings are summarized above. No PR has been opened; this report is for a maintainer-led fix.

[foureight84]

@srinikandala — this is fixed in a test build: v2.9.1+54-rc1 (PR #75). It's a prerelease, so the in-app updater won't push it to anyone else — install the universal APK over your current build.

Your diagnosis was right, and thank you for doing the work to prove it rather than just reporting the symptom. I checked it against the vendor SDK before changing anything — BluetoothLeService.a(int, int) writes the type into bArr[0] (1 → 16 = 0x10, 2 → 22 = 0x16) and then the day argument straight into bArr[1], one day per call, exactly as you said. DupMainActivity.onGetMultipleSportData counting P_SYNC_HISTORY_DAY down to zero confirms the loop.

So 0x10/03 was asking for the day before last and 0x10/01 for yesterday, and today was never requested by any pass. Since 0x10 is the only source of sleep, last night could not arrive however long the app ran.

The fix follows your prototype: each day is its own request, today first, plus the rest of the backfill window once per connection. One deliberate difference from both your prototype and the vendor — the vendor is reply-driven, asking for the next day only when the previous day's stream ends, and counts down to today. We enqueue the window in one pass with today leading, because nothing here decodes a per-day sync-end to chain from. If your capture shows a day's stream getting truncated when the next request lands, that's the thing to tell me, and the vendor's chain is the fix.

Worth knowing: the wrong reading came in with a citation to Gadgetbridge's triggerActivityReportByDays(), an identifier that appears nowhere in the vendor SDK. iOS was never affected — it hardcodes offset 0 and simply never backfilled.

What would confirm it:

• Sleep appears for last night after a sync, which is the whole issue.
• The first connection after installing pulls three days rather than one — that's the backfill finally working, and it means noticeably more packets on that first sync. Say so if it feels slow or stalls.
• Every later sync (including the ~30-minute background one) asks only for today, so it should not re-pull the window every half hour.

I did not change the timing behaviour you noted — that we send the HR request ~30 ms after starting activity/sleep where JYouPro waits about 2 s for the stream to go quiet. Your own timing-only prototype didn't fix sleep, so it isn't the bug, and I'd rather not change two things at once. If sleep still arrives incompletely on this build, that's the next thing to look at and your capture would settle it.

[srinikandala]

Tested the requested v2.9.1+54-rc1 universal APK on the SR08. Sleep is still incomplete: 45 minutes displayed instead of the expected 6 hours 30 minutes. Please keep #73 open and revisit sequencing in #75.

The diagnostics confirm version=2.9.1, versionCode=54, buildType=release, applicationId=com.pulseloop. This is the RC1 test, not the earlier build 53 test.

What the unredacted capture shows

All times below for the command/notification sequence are UTC on 2026-09-16:

Time	Direction	Command / notification
16:39:13.623	TX	10 00 — today's activity/sleep
16:39:13.653	TX	10 01 — yesterday, only 30 ms later
16:39:13.738	RX	11 — today's first 15-minute sleep packet
16:39:13.740	TX	10 02 — next day request while sleep is arriving
16:39:13.753	RX	11 — today's second 15-minute sleep packet
16:39:13.756	RX	11 — today's third 15-minute sleep packet
16:39:13.797	RX	11 — one packet from the previous day
16:39:13.799	TX	16 00 — heart-rate history

The three day requests and HR request are sent within 176 ms. There are only four sleep notifications in this capture. Decoding the little-endian timestamp and the fifteen one-minute stage bytes in each packet gives these ring wall-clock intervals:

Date	Interval	Stage	Duration
Sept 16	01:15–01:30	Light (0x28)	15 min
Sept 16	01:30–01:45	Light (0x28)	15 min
Sept 16	01:45–02:00	Deep (0x63)	15 min
Sept 15	01:00–01:15	Light (0x28)	15 min

The three distinct, consecutive packets for Sept 16 account for the displayed 45 minutes exactly. The fourth is from the previous day, not a duplicate or another 15 minutes for this night. The capture therefore contains only a partial night; a duration-display calculation alone cannot recover the missing sleep.

Comparison with the working prototype

The local build that waits between transfers continues to work on this SR08. Its successful hardware validation included both explicit day offsets and sequencing; it did not validate enqueueing 10/00, 10/01, 10/02, and 16/00 together.

The working implementation requests one day's activity/sleep, resets a 2-second inactivity timer on complete 0x10/0x11 packets, then requests that day's HR history. It advances to the next day after HR completion (with timeout/error fallbacks).

This supports the truncation/overlap concern described in your comment. The capture alone cannot prove which subsequent command interrupts the ring, but the day-offset fix by itself has not resolved sleep retrieval. Please serialize the history transfers using a reliable completion signal or the tested inactivity-based sequencing, and add a test that subsequent history requests are held while the current stream is active. A timing-only fix failing before offset 0 was requested does not rule out needing both fixes.

Raw diagnostics are intentionally not attached because they contain personal health/device data; the relevant decoded evidence is included above.