[Feature Request] R100 support: works ~90% using Colmi R11 profile, but SpO₂/stress need additional protocol support

[scufitarosie]

Hi,

I've been testing my R100 smart ring with PulseLoop by selecting the Colmi R11 ring profile. Surprisingly, the R100 works very well with this profile and roughly 90% of the functionality appears to work. I wanted to provide the diagnostic log because the R100 appears to use a closely related/proprietary BLE protocol, and perhaps the remaining functionality can be added with an R100-specific implementation or extensions to the existing Colmi R11 support.

Device

Ring: R100
Firmware: MOY-R2E3-2.2.1
Android device: Motorola Edge 70
Android: 16
PulseLoop: 2.7.0 (build 40)

The diagnostic reports the wearable type as CRP and identifies the device as R100. Its reported capabilities include:
heartRate, spo2, steps, battery, stress, hrv, temperature, manualHeartRate, manualSpo2, realtimeHeartRate, realtimeSteps, findDevice, factoryReset

BLE services

The R100 exposes the following services:

• 180F Battery Service
• 180D Heart Rate Service
• FDDA Proprietary service
• FDD7 Proprietary service

PulseLoop successfully discovers all four services. The diagnostics show notifications being enabled on:

• 2A37 Heart Rate Measurement
• FDD1
• FDD3
• FDD6

and writes being performed through:

• FDD2

The connection and service discovery complete successfully with status 0.

What currently works

Using the Colmi R11 profile, I can successfully use most of the ring functionality, including:

• Heart rate
• Steps
• Battery
• Sleep
• Historical data synchronisation
• Other functionality exposed by the existing profile

The diagnostics show the R100 returning historical measurement data and sleep timeline data over the proprietary FDDA protocol. For example, the app is receiving history_measurement and sleep_timeline frames during synchronization.

The ring also returns its firmware revision over the same protocol:MOY-R2E3-2.2.1

This is visible in multiple synchronisation sessions.

Problems

There are two main limitations I've noticed:

1. SpO₂

• SpO₂ works when I trigger a manual/on-demand measurement, but it does not appear to be synchronized as historical/continuous data in the same way as the other measurements.

The diagnostic metadata explicitly reports both:

• spo2
• manualSpo2
  as supported capabilities, so the ring clearly advertises SpO₂ support.

I suspect the existing R11 implementation does not yet handle the R100's SpO₂-specific command/data format correctly.

2. Stress

• Stress does not currently work.

Interestingly, the diagnostic capability list explicitly reports:

• stress
  along with HRV and temperature.

So this appears to be a protocol/decoder/support issue rather than the ring simply lacking the feature.

Interesting protocol observations

The R100 is clearly communicating using the FDDA proprietary protocol.

The diagnostics contain repeated frames such as:

• fdda1007020e03
• fdda1007020e04
• fdda1007020e06

which PulseLoop currently reports as unknown.

There are also corresponding sleep_timeline frames around these responses.

The application is successfully exchanging commands such as:

• fdda1008020f0001
• fdda100802110001
• fdda100802100001
  and receiving historical/timing data in response.

There are also several other commands being sent during initialization/synchronization, including:

• fdda10060206
• fdda10060207
• fdda10060208
• fdda10060215
• fdda10060225
• fdda1006022d
• fdda10060303
  ...

followed by successful responses from the ring.

Request

Would it be possible to investigate adding native R100 support, or at least extending the existing Colmi R11 implementation to cover the R100's additional protocol/features?

In particular, I'd be very interested in seeing/testing:

• Historical SpO₂ synchronisation
• Stress measurements

The fact that the R100 already works so well using the R11 profile makes me think the underlying protocol is sufficiently compatible that full support may be relatively straightforward.

Thanks for the excellent work on PulseLoop!

pulseloop-diagnostics-2026-08-31T06-53-02.671003Z.json

[foureight84]

Nice! Can you send me a link to the Colmi R100? I don't think I've seen this ring (is it new)?

[scufitarosie]

Bought it locally, but I believe it's this one: https://m.tvcmall.com/details/r100-multifunction-smart-ring-health-monitoring-blood-oxygen-heart-rate-sleep-tracker-with-charging-case-gold-size-9-sku6899003809h.html?srsltid=AfmBOor64GOeDD5TvgKXGS2ryLF8JLFDLXr45yWKxCCGaqs7L8HoUaMP&c=EUR

[foureight84]

What app is listed in the ring's manual?

[scufitarosie]

Da rings. Sorry for not mentioning it from the start

[foureight84]

A pre-release build is coming in the next few minutes for you to test.

[foureight84]

@scufitarosie — I went through the diagnostics you attached frame by frame. Test build with the results: v2.8.0+41-rc1 (PR #62). It's a prerelease, so the in-app updater won't offer it to anyone else; install the universal APK over your current build.

Your instinct that the R100 is "sufficiently compatible" was right, and your capture turned out to be worth more than the specific things you asked about.

The unexpected find: temperature history

Your report is the first non-empty temperature reply anyone has sent us. The layout had been sitting in our code marked unconfirmed for months because every capture from the R11 came back empty. Yours isn't:

day 0, frame 0: 0,0,0,0,363,0,0,0,0,0,0,0,0,0,358,0,0,0,0,362,…
                          36.3°C          35.8°C      36.2°C

That matches the official app's own parser exactly, so temperature history now decodes. And it was costing more than the samples: because those frames weren't decoded, the sync never advanced past the first frame of the day — so everything after roughly 18:00 was never even requested, on every CRP ring, not just yours.

Your two asks

SpO₂ — the sync is working; your ring just has almost nothing stored. I matched each reply to the query that caused it. Heart rate returned 21 frames carrying data against 22 empty ones, HRV 30 against 54 — but SpO₂ returned 2 with data against 44 empty. So the ring is answering, and the decode is fine; it simply records very little all-day SpO₂. Its own SpO₂ monitor-state read-back says the monitor is enabled on a 5-minute interval, so it isn't switched off either. Nothing to fix on our side that I can see — but if the Da Rings app shows you a full day of SpO₂ that PulseLoop doesn't, that would be a real contradiction and worth reopening.

Stress — your ring never answers. Across 22 sync passes, we sent both the stress history query and the stress monitor-state query 22 times each and got zero replies to either, while every other state query answered normally (HR, HRV, SpO₂ and temperature all replied). That's a silent ring, not a decode gap.

One thing worth correcting, because you reasonably read it as evidence: the stress in the capability list your diagnostics showed is a static per-family constant in PulseLoop — it's what we assume for any CRP ring, not something your R100 confirmed. So it isn't proof the hardware supports it. If stress does appear in the Da Rings app on your ring, then it uses an opcode we don't know about, and a Bluetooth capture of that app talking to your ring would show which one. Without that I'd only be guessing.

Also in this build

• The R100 has its own pairing card now, so you shouldn't have to know to pick the Colmi R11 one.
• Diagnostics reports got more useful. A masked health frame used to keep only its first byte, which threw away the part identifying which vital it was — that's why your report couldn't tell an all-day SpO₂ reply from an HRV one without cross-referencing. It now keeps the routing header. (It also quietly fixed the reverse problem: your temperature values were being exported unmasked, precisely because we couldn't decode those frames.)

What would help

• Does the R100 show up as its own card when pairing?
• Does a temperature chart populate — particularly after ~18:00, which is the part that was unreachable?
• If you're willing, a fresh diagnostics export after a sync on this build. With the masking fix it will say considerably more than the first one could.

Thanks for a genuinely useful report — the temperature decode is in for every CRP ring because of it.

[scufitarosie]

@foureight84 , I've attached the latest diagnostic report.
The Da Rings app does show a consistent stress reading, though it might be calculated by the app rather than pulled directly from the ring itself. Couldn't find a way to export t
The ring is showing up correctly in its dedicated R100 card, which is a nice touch.
Everything appears to be working well now, including temperature readings past 6pm.
Let me know if there's anything else I can test or help with!

PulseLoop_R100_Diagnostics.JSON

[foureight84]

@scufitarosie — thank you, that's everything I needed. Your new export confirms all three fixes from the ring's own traffic, not just from the screenshots:

• The frame walk is working. Temperature is now requested as frames 0, 1, 2 and 3 — five of each. In your first report it was frame 0, fifteen times, and nothing else. That's why everything past ~18:00 was missing.
• The decode boundary is visible in your capture. Every temperature reply from 03:23:07 onward decodes properly; everything before that is from the old build still sitting in the packet buffer. That timestamp is you installing rc1.
• The masking fix is doing its job — which is how I could tell those two groups apart at all.

Good to hear the R100 card shows up and temperature past 6pm looks right.

On stress

Your reading of it is almost certainly correct. In this capture we asked your ring for stress 15 times and got zero replies, plus zero replies to both the stress-settings query and the SpO₂-type query — while HR, HRV, SpO₂ and temperature all answered normally. So Da Rings showing you a consistent stress number while the ring itself says nothing points at the app computing it rather than reading it.

That's actually the more useful outcome. Stress is conventionally derived from heart-rate variability, and your ring returns plenty of HRV — so this becomes something PulseLoop could compute too, for your R100 and for every other ring with HRV but no stress sensor. That's a different (and much easier) piece of work than a protocol gap, and I'll open it separately rather than hold this up.

No need to hunt for an export from Da Rings — you've already given me the answer.

Nothing further to test on this issue as far as I'm concerned; it'll close when the PR merges. If you ever do see a vital that Da Rings shows and PulseLoop doesn't, that's always worth reopening for — your first report turned into a temperature-history fix for every ring in this family, so these are worth sending.

[foureight84]

@scufitarosie — one more test build before this merges: v2.8.0+43-rc3 (prerelease, install the universal APK over rc1).

Nothing in it targets the R100 — the changes are on the spot-measurement side for the other reporter's ring — but a couple touch code every ring runs through (how spot readings are stored, and the diagnostics masking), so I'd rather have your ring confirm nothing regressed than assume it.

If you can: install, let it sync, and check that the R100 card, the temperature chart past 18:00, and SpO₂ history all still look as they did on rc1. A quick "still fine" is all that's needed. Thanks again for the export — it's already confirmed everything on your side.

[scufitarosie]

@foureight84 tested and everything looks good!

[foureight84]

@scufitarosie — one more, v2.8.0+46-rc6, before this merges. Nothing in it targets the R100, but two changes touch every ring: how a night's sleep duration is computed (time asleep rather than start-to-end; stored nights are restated once on first launch) and how a spot reading is stored. A quick "still fine" on the R100 card, the temperature chart, and the sleep card is all that's needed. Thanks again.

[scufitarosie]

@foureight84 installed the update, re-paired the ring and everything looks fine: r100 card loads and ring is correctly identified, temperature card reports history correctly, so does the sleep card. I'll keep an eye on everything over the next 24 hours and report back if I spot any issues 🫡