The 56ff jring firmware only stages sleep inside two time windows stored on the ring: one nap window and one night window. PulseLoop currently never writes those windows, so each ring keeps whatever values were factory-flashed or last written by the vendor app. As a result, daytime naps outside the stored window are not recorded and cannot appear in PulseLoop after sync.
PulseLoop should initialize deterministic sleep windows on connect, alongside the existing 0x19 background-monitoring push. A proposed wider configuration is:
- Nap: 12:00–18:00
- Night: 21:00–12:00
Protocol details
The command is a fixed 20-byte write with no checksum and no enable flag. It carries both windows in one frame, nap first and night second:
[0] 0x09
[1] nap start hour
[2] nap start minute
[3] nap end hour
[4] nap end minute
[5] night start hour
[6] night start minute
[7] night end hour
[8] night end minute
[9..19] 0x00
For the proposed windows, the frame is:
09 0c 00 12 00 15 00 0c 00 00 00 00 00 00 00 00 00 00 00 00
Vendor defaults are 13:00–14:00 for naps and 21:00–08:00 for night sleep. The vendor app only sends 0x09 when the user presses Sync on its sleep screen, not automatically on connection, so many rings may never have received a known configuration.
The layout was recovered from com.jaga.ibraceletplus.jyring 1.9.84: com.sxr.sdk.ble.keepfit.service.BluetoothLeService.setSleepTime(IIIIIIII) in classes2.dex. Argument order was confirmed at SleepActivity.OnClickivSync, which passes alarmNoon before alarmNight. The command builder was cross-checked against setAutoHeartMode2, whose 0x19 frame matches PulseLoop's existing encoder byte for byte.
An Android fork already sends this command on connect beside 0x19; its unit tests pass and it builds successfully. Hardware validation is still pending, so the implementation should remain explicit about that caveat and should include encoder/startup-sequence tests.
Steps to reproduce
- Connect a generic
SMART_RING / 56ff jring whose sleep windows have not been initialized by PulseLoop.
- Take a daytime nap outside the ring's factory or previously stored nap window.
- Sync sleep data in PulseLoop.
- Observe that the nap is missing.
Expected: PulseLoop writes suitable nap and night windows to the ring so sleep occurring within those documented windows is staged and returned during sync.
Actual: PulseLoop never sends 0x09, leaving unknown on-ring windows in effect, and sleep outside them is not recorded.
Which ring are you using?
jring (generic SMART_RING / 56ff)
iOS version
N/A: reported against the Android port; the missing jring protocol command also applies to the current iOS source.
iPhone model
Not provided
PulseLoop version / commit
main @ 21ff3232fae6a412d7dd95c4d226d915d361ff91
Which area is affected?
Data sync / decoding
Logs / screenshots
No logs or screenshots. Protocol source and proposed frame are documented above.
Before submitting
The 56ff jring firmware only stages sleep inside two time windows stored on the ring: one nap window and one night window. PulseLoop currently never writes those windows, so each ring keeps whatever values were factory-flashed or last written by the vendor app. As a result, daytime naps outside the stored window are not recorded and cannot appear in PulseLoop after sync.
PulseLoop should initialize deterministic sleep windows on connect, alongside the existing
0x19background-monitoring push. A proposed wider configuration is:Protocol details
The command is a fixed 20-byte write with no checksum and no enable flag. It carries both windows in one frame, nap first and night second:
For the proposed windows, the frame is:
Vendor defaults are 13:00–14:00 for naps and 21:00–08:00 for night sleep. The vendor app only sends
0x09when the user presses Sync on its sleep screen, not automatically on connection, so many rings may never have received a known configuration.The layout was recovered from
com.jaga.ibraceletplus.jyring1.9.84:com.sxr.sdk.ble.keepfit.service.BluetoothLeService.setSleepTime(IIIIIIII)inclasses2.dex. Argument order was confirmed atSleepActivity.OnClickivSync, which passesalarmNoonbeforealarmNight. The command builder was cross-checked againstsetAutoHeartMode2, whose0x19frame matches PulseLoop's existing encoder byte for byte.An Android fork already sends this command on connect beside
0x19; its unit tests pass and it builds successfully. Hardware validation is still pending, so the implementation should remain explicit about that caveat and should include encoder/startup-sequence tests.Steps to reproduce
SMART_RING/ 56ff jring whose sleep windows have not been initialized by PulseLoop.Expected: PulseLoop writes suitable nap and night windows to the ring so sleep occurring within those documented windows is staged and returned during sync.
Actual: PulseLoop never sends
0x09, leaving unknown on-ring windows in effect, and sleep outside them is not recorded.Which ring are you using?
jring (generic SMART_RING / 56ff)
iOS version
N/A: reported against the Android port; the missing jring protocol command also applies to the current iOS source.
iPhone model
Not provided
PulseLoop version / commit
main@21ff3232fae6a412d7dd95c4d226d915d361ff91Which area is affected?
Data sync / decoding
Logs / screenshots
No logs or screenshots. Protocol source and proposed frame are documented above.Before submitting