TicWatch3 can only track one of HRV or SpO2

Detailed description of the problem:
Only one of HRV or SpO2 seems to come through from the Ticwatch Pro 3 event though both are supported. The fact that they seem to be mutually exclusive is best illustrated by this sleep graph where one stops and the other starts.

Peter is also aware of this problem and commented on it here [DONE] SP02 and Ticwatch 3 Pro

Steps to reproduce:

Track sleep using Ticwatch Pro 3, which supports both hear rate with HRV, and oximeter. Only one or the other will populate with data.

Version of Sleep as Android:
20210423 (22358) Premium

1 Like

Hello Ben, I’m also on TicWatch Pro 3 and can confirm the issue. It seems TicWatch implemented the SPO2 and SDNN sensors mutually exclusive. I do not know why , but this is how it works on my TicWatch device… What we do now is if you enable the Oximeter option in Settings > Wearables we register for SDNN and SPO2, if you diable it we register for SDNN only.

On my watch registering both SDNN and SPO2 deterministically leads to just SPO2 data all night… the reason we register both is there si a good chance that this will work well on other Wear OS watches and we could get both data on other devices…


BTW I see the rating star view is somehow off… do you see this on every graph detail screen?

Ah OK thanks that is good to confirm, I wondered if it was something like that.

Yes, as of a few weeks ago the stars have looked like that.

One other bug I haven’t got around to filing it that I need to scan the QR code twice every time to disable an alarm

Hello folks, I have tested SPO2 some more on my TicWatch 3 Pro after the firmware update, and I think something changed in the sensors and I’m no longer getting SPO2 data at all… can you confirm this?

To mitigate the issue with clashing sensors I have implemented in Wear OS sleep tracking that we always only register either SDNN or SPO2… but during testing this I have realized that even registering fro SPO2 TicWatch stopped to sending SPO2 to third parties probably…

I’m now experimenting with this and it seems I’m able to get SPO2 data from TW3 Pro when I completely disable HR sensors… So I will test this few nights and see if it is working deterministically and than prepare this for a release later probably next week…

Same problem here, I can either get:
hr and hrv all night, (NO spo2)
hr all night and hrv for maybe 1 hour then spo2 takes over rest of night… (like OP)

Can I ask though which options I’m supposed to use? There are 2 options for each function, I’m guessing to use the wear os option for both…?

And does it matter what options are set on the watch? Does it matter if I turn on/off 24 hour heart rate or spo2 tracking?

Also please let me know if/how I can help troubleshoot :slight_smile:

1 Like

I am still able to get SpO2 and heart rate, as recently as 2 days ago. Ticwatch pro 3 is on Android wear 2.27, build number PMRB.210407.001, and system claims to be up to date.

Hello guys, I have tested this intensively yesterday and I think the behavior has changed after the recent TW3 Pro firmware update… I trying different sequences of sensor initialization and I’m able to get SPO2 data for a short moment, but over night tests usually end with no SPO2 tracked… I will keep trying…

I do not know yet. I did not manage to test all the combinations. So any feedback appreciated…

I’m going to get a TWP3 in a few days, so I’ll be able to help troubleshooting the issue. Does Mobvoi provide no info on how to initialize and access sensor data? If they are not doing it the standard way (which is a very bad thing), they should at least document it somehow.

Hello, yesterday I tied to disable HR altogether in Settings > Wearables and only leave the Oximeter setting on and I did get all SPO2 data on that night… this needs more testing, but to me it seems like after the firmware update the sensor is even more sensitive on the use of any HR sensor and does not work in this case… So I’m affraid it will be either HR and HRV or SPO2 on the TicWatch 3 Pro…

Hello, anyone any observations? Today I’m trying to re-register the sensor listener every time an error is returned from the sensor… so hopefully this will help…

Google at I/O has announced major changes to how apps can access sensor data in the next version of Wear OS (wow! big changes finally!) here, in the Devs insights video. Maybe this can help?

[kind of OT side note]: since in the same video they have announced a collaboration with Sleep Cycle for Wear OS, would you consider a standalone Wear OS app? I think it would be a great addidion, given the great revamp and changes given to the platform.

1 Like

Also, in regards to this particular way: if it works, then it’s great - but wouldn’t constantly re-registering the sensor drain more battery?

@mind-overflow was watching the video in the morning. Definitely great news for the platform which is now after Pebble is gone my favorite. Unfortunately I did not yet find any documentation for the new Health Services API so hard to say if this would really be something of a use for Sleep as Android…

Regrading battery when reregistering sensor… my theory is that after the update, when the SPO2 sensor misreads data - for instance you are laying on the hand or similar… it just reports error and stops sending data. I expects this happens only few times during the night so expected battery impact is negligible IMHO…

1 Like

That sounds like an absolutely plausible explanation to why the sensor stops sending data. I was expecting it to be more of a random thing that happens every few minutes.

If this is the case, then, i think the “fix” of re-registering it would be great, given that the app doesn’t insist on that if the sensor keeps reporting errors (eg: retry only 5 times in a row, then give up for the rest of the tracking, or even for X minutes). It would be sad to wake up in the morning with a discharged watch because the CPU was busy all night trying to access the sensor.

By the way, I don’t know what kind of certainty you have on this theory, but if you want to be more sure, a simple test of manually starting tracking and removing the watch should make it evident (given that you obviously can see logs and print stuff to the logs too).

Is this fix already implemented in the latest version? If so, I could help testing or giving feedback if you need it in any way!

Thank you for your commitment :slight_smile:

Hi guys,

Nothing really to add to the discussion - just wanted to jump on and let you all know I’m happy to test fixes for this issue.


Many thanks. I will prepare some version for testing hopefully next week…

Hi, just chiming in to say I have the same observations. Discussion and thoughts for solution seems like good ideas. Looking forward to results :blush: