R10M / LittleMeatball¶

PulseLoop support: ✅ Supported — validated on hardware (R10M FCF4, firmware 2.32)

The R10M is sold as the LittleMeatball smart ring (and unbranded by a long tail of resellers — ORIWHIZ, JTLlink, and others list the same R10M hardware). It pairs with the SmartHealth app and speaks the Yucheng YCBT protocol on a be940 service, the same wire format as the TK5 and the SmartHealth-app Colmi rings.

This is the best-validated YCBT ring PulseLoop drives

Pairing, the handshake, reconnect and day rollover; activity and history sync; HR, SpO₂ and blood pressure both as history and as spot measurements; battery; sleep stages and REM — all confirmed on a physical R10M running firmware 2.32.

The support was ported from the Android app, where that validation was done. The iOS port shares no code with it, but it does share the protocol and the two firmware workarounds below.

Not the only ring that speaks it¶

The R10M is one of three ring families PulseLoop drives over YCBT — the others are the TK5 and Colmi rings that ship with SmartHealth. The protocol is byte-identical, so all three share the whole driver (the device-neutral YCBT* core); each family adds only a coordinator with its advertisement matcher and capability set, plus a small profile for firmware quirks.

It is deliberately not filed under Colmi. The R10M is a different vendor's ring that happens to speak the same protocol. Folding it into the Colmi family would have it inherit Colmi product art and Colmi capability claims, and would put an "is this a QRing or a SmartHealth ring?" question in front of an owner whose ring only ever shipped one firmware.

	R10M	TK5	SmartHealth-Colmi
Advertisement	`R10M <4 hex>` (space or underscore) and the `be940000` service	`TK5 <4 hex>`; service not advertised	a Colmi-line name, which a QRing Colmi can also carry — so PulseLoop asks which app the ring came with
Hardware validation	✅ full session, FW 2.32	❌ none — protocol proven on a sibling	✅ an R99 runs it daily
Chip scheme query (`02 1b`)	❌ suppressed — drops the link	✅ answered	✅ answered
All-day BP monitor (`01 1c`)	❌ not implemented	✅ sent	✅ sent
Dedicated SpO₂ log (`05 1a`)	❌ never queried	✅ queried	✅ queried

A fix to any YCBT* file fixes all three rings; a regression in one breaks all three.

At a glance¶

	Detail
SoC	❓ Unknown
Bluetooth	BLE (version ❓)
PPG sensor	❓ Unknown — green LED for HR, red/IR for SpO₂ (both visible in the ring's exposed PCB)
Accelerometer	Yes (steps and sport buckets decoded; part ❓)
Battery / life	❓ Unknown (resellers claim ~4–5 days)
Waterproof	IP68 per the reseller listings
Weight	~3.6–4.5 g
Sizes	7 (17.3 mm) – 13 (22.2 mm)
Price	~$15–30 depending on seller and finish
Protocol	Yucheng YCBT — variable-length frames, CRC16/CCITT-FALSE, cleartext
App	SmartHealth
Advertised name	`R10M <4 hex>` — e.g. `R10M FCF4`; `R10M_FCF4` also observed
Firmware tested	2.32
Custom firmware	❓ Unknown

Protocol¶

Identical to the TK5's — same service, same framing, same history state machine:

Property	Value
Service	`be940000-7333-be46-b7ae-689e71722bd5` (advertised, unlike the TK5's)
Command char	`be940001` — write and indicate
Stream char	`be940003` — indicate: live vitals and all history data frames
Frame	`[type:1][cmd:1][len:2 LE][payload:N][crc16:2 LE]`, `len` = total frame length
CRC	CRC16/CCITT-FALSE (poly `0x1021`, init `0xFFFF`, no reflection), little-endian
Epoch	Seconds since 2000-01-01, in the ring's local wall-clock (no timezone concept)
History	`05 <key>` query → header → concatenated data frames → `05 80` terminal → mandatory `05 80 {00}` ACK
Encryption	None. No `AE00` / JieLi RCSP service on this ring

Both indication channels must be live before the handshake starts. Command replies — device info, the capability bitmap, every ACK — arrive on be940001, while live and history data arrive on be940003. PulseLoop waits for both, then writes the name read and the clock ahead of everything else. A ring missing either channel fails the connect attempt with a visible error rather than hanging half-connected.

Firmware quirks¶

Two commands are suppressed for this family, and only this family:

Command	Why
`02 1b` GetChipScheme	The R10M closes an otherwise healthy connection with HCI `0x13` when asked. It is purely informational — nothing depends on the answer — so it is simply not sent.
`01 1c` all-day BP monitor	The ring has the blood-pressure sensor but does not implement the all-day monitor. The flag is separate from the capability for exactly this reason.

The TK5 and SmartHealth-Colmi families answer both fine and still send them.

Capabilities¶

Ring-declared vs. baseline. The rows marked 🔓 ring-declared are offered only if this unit's 02 01 capability bitmap sets their bit. Everything else is a baseline promise — claimed unconditionally, and the bitmap can only ever add, never remove.

Firmware 2.32 declares none of the gated bits, so a stock R10M shows its baseline plus blood pressure. They stay listed because "R10M" is a model, not a firmware, and the gate costs a ring that does have them nothing.

Capability	Status	Notes
Heart rate — spot	✅	`03 2f` mode `00` → `06 01` stream
Heart rate — live	✅	`06 01` stream
Heart rate — history	✅	`05 06` query, 6-byte records
SpO₂ — spot	✅	red/IR LED, `03 2f` mode `02`
SpO₂ — history	✅	from the `05 09` combined record only — this ring has no dedicated `05 1a` log, so that query is never issued
Steps / distance / calories	✅	`05 02` history buckets + the live `06 00` counter
Sleep (light / deep / awake)	✅	`05 04` timeline; stage = `tag & 0x0F`
REM sleep	✅	stage tag `3` — a stage inside the timeline `ISHASSLEEP` grants, so no bit names it and it is not gated
Blood pressure — history	🔓	ring-declared (`ISHASBLOOD`, byte 0 bit 0). Dedicated `05 08` log + the combined record
Blood pressure — spot	🔓	ring-declared (`ISHASTESTBLOOD`, byte 15 bit 2). `03 2f` mode `01`; no cuff calibration, so treat as a trend, not a number
HRV	🔓	ring-declared (`ISHASHRV`, byte 1 bit 1). Gated, unlike the TK5 — nobody has seen an R10M produce an HRV figure, and FW 2.32 does not declare the bit
Skin temperature	🔓	ring-declared (`ISHASTEMP`, byte 8 bit 0)
Stress	🔓	ring-declared (`IS_HAS_PRESSURE`, byte 22 bit 6), from the body-data record (`05 33`)
Fatigue	🔓	ring-declared on the same bit as stress — one record, one bit, two fields
Blood sugar	🔓	ring-declared (`ISHASBLOODSUGAR`, byte 17 bit 3)
Respiratory rate	✅	combined record @10
Battery level	✅	in-band: `02 00` reply payload[5], plus the unprompted `06 15` push
Find device	🔓	ring-declared (`ISHASFINDDEVICE`, byte 6 bit 4) — not declared by FW 2.32
Measurement intervals	✅	the `01 xx {enable, interval}` monitors, filtered to the sensors this ring declares; floored at the firmware's 30-min minimum
Periodic re-sync while connected	✅	every 30 min, plus a post-workout vitals pass
Continuous background sync	❌	the ring is only read while connected
FW update via app	❌	not implemented

Known limitations¶

No dedicated SpO₂ history log. All-day SpO₂ comes from the 05 09 combined record instead. This is why spo2History is claimed neither as baseline nor as a gated capability — that is precisely what stops the 05 1a query being issued.
Blood pressure is uncalibrated. There is no cuff reference, so the number is a PPG-derived trend.
~8-day history horizon. History samples, sleep sessions and activity timestamps outside now − 8 days … now + 1 hour are dropped, because a ring's log can hold records stamped under a previous clock and history rows upsert — one misdecoded record would re-persist on every sync.
No background sync while disconnected. The ring keeps logging on its own schedule; PulseLoop reads it on connect, every 30 minutes thereafter, and after a workout.
The ring's log is never deleted. As with every YCBT ring, PulseLoop does not issue the Health-Delete opcodes, so the ring replays its whole log on each sync and deduplication is app-side. See how PulseLoop diverges from SmartHealth.

See the TK5 and the SmartHealth-app Colmi rings that share this driver, or the hardware overview for the cross-manufacturer comparison.