Live location S+ app

Tieutieu

@Nikolai-Simonov Thanks. I just edited my test report to specify that sending metrics was off and that i had continious gnss ON.
I’ll test again with notifications off, gnss off and additional metrics on

Miroslava

@Nikolai-Simonov

1. I pressed the top button 10 times today until it connected
1. I already understood that it’s in the settings
Motorola edge neo 30 i think android 14
tommorow i go run and try it again

Dimitrios Kanellopoulos

Is the web made with react ?

Francesco Pagano

@Nikolai-Simonov said in Live location S+ app:

Repeated “watch connected” notifications

I can confirm on Android 14 I see repeated notifications “watch connected / watch disconnected”, every 30 seconds or so

Miroslava

@Francesco-Pagano exactly as me

Nikolai Simonov

Hi @Miroslava @Francesco-Pagano
Thanks a lot for helping test and report this!

I was able to reproduce the issue — on some devices, it looks like there’s a conflict with the Suunto App (SA). Roughly once per minute, SA causes the disconnection between Live.t and the S+ app on watch and that’s why you’re seeing repeated connection notifications.

I still need a bit of time to fully investigate what’s going on, but in the meantime:

Good news:
The SuuntoPlus app handles reconnection correctly, so even with these interruptions, tracking should continue to work well.

Temporary workaround:
You can mute notifications from the Live.t app in your phone’s system settings. That should make it less annoying until the fix is ready.

I’ll publish a small hotfix soon to make the connection notification silent by default.

Thanks again for your help in tracking down this weird bug really appreciate it!

Nikolai Simonov

@Dimitrios-Kanellopoulos nope, it’s svelte

Miroslava

@Nikolai-Simonov I’m super glad I helped you catch the mistakes, we’ll see how it goes after the fix, when I try it out

Dušan Ković

@Nikolai-Simonov Would adding different intervals between data pings be beneficial for mobile phone battery life? For example - 1min, 2min, 5min, 10min, 15min, 30min, 1 hour, etc. On a lot of activities you don’t need real-time (1sec pings) tracking

Miroslava

@Nikolai-Simonov today run livetrack worked perfectly

SergioB

Tested today with a 2h bike ride, with Suunto Race and Android 13 on a 3 years old Motorola smartphone.
Everything worked well!
Battery consumption on the smartphone was 7%
After stopping the activity and reopening Suunto App to look at the stats, I noticed the watch was unpaired (and I thought it had disconnected at the beginning of the activity because I didn’t receive any notification during my ride, despite founding them on the smartphone)

Btw for me the app is great!

Nikolai Simonov

@Francesco-Pagano @Miroslava @SergioB

I’ve investigated the issue that, when Suunto App (SA) is running, a Live.τ session on the watch may unexpectedly disconnect and immediately reconnect every 60-90 seconds. also the same issue if SA lost connection with watch.

TL;DR: Unfortunately, this is a limitation we cannot fully solve from the Live.τ side alone.

⸻

The root of the conflict (without diving deep into tech):

The watch can hold only one “live” Bluetooth link to the phone at a time.
When SA wakes up in the background to sync, the watch switches that link over to SA.
Live.τ also needs the same Bluetooth link to stream your track in real time. When SA grabs the link, Live.τ’s session is dropped.
This happens only on Android. On iOS, Suunto App is far more restricted in the background and doesn’t run a permanent service, so the conflict doesn’t appear.

Together, these points explain the periodic disconnect/reconnect behavior you may see.

In practice this shouldn’t break your recording: the S+ app on the watch reconnects in about a second—essentially one event-loop tick—so no data should be lost. Still, the reconnection is a little annoying and does cost a tiny bit of extra battery.

⸻

How can we ease the conflict?

Because Suunto App (SA) and Live.τ vie for the same Bluetooth connection, the real limitation lives inside the watch’s BLE firmware.

Temporarily stopping SA’s background service would prevent the clash, but Android doesn’t allow one app to shut down another; In addition I’ve not found any way to stop this service via SA UI, if somebody know how to do that, please let me know it could be a basic recommendation.
Disabling “Discovery” on the watch probably won’t help: SA already has a bonded connection to the watch, and during an active workout the watch generally doesn’t advertise itself anyway, so SA can still reclaim the link.
Ideally we could cooperate with SA e.g., send it an some kind intent that saying “Live.τ is taking the connection now; please pause sync”, however that would require close collaboration with Suunto’s app team.

⸻

What we’ve done so far

In the latest release, Live.τ now shows silent reconnection notifications so the pop-ups are less distracting. For now that’s all we can do.

panadero

Hi Folks!

Are you was also super excited about this live location feature. How did you manage to install it?

I tried to install it as usual. In the iPhone App shows as installed and loaded in my Suunto Race. However, it doesn’t show up in the SuuntoPlus menu when setting up the activity in the watch.

Of course my watch is not connecting to the new live.T app.

Tried to install/uninstall the LiveLocation (as well as other S+ apps) but doesn’t seem to solve the issue. Did a soft reset already.

Did u experience something similar?

Thx

Antoine

@Nikolai-Simonov said in Live location S+ app:

@Francesco-Pagano @Miroslava @SergioB

I’ve investigated the issue that, when Suunto App (SA) is running, a Live.τ session on the watch may unexpectedly disconnect and immediately reconnect every 60-90 seconds. also the same issue if SA lost connection with watch.

TL;DR: Unfortunately, this is a limitation we cannot fully solve from the Live.τ side alone.

⸻

The root of the conflict (without diving deep into tech):

The watch can hold only one “live” Bluetooth link to the phone at a time.

When SA wakes up in the background to sync, the watch switches that link over to SA.

Live.τ also needs the same Bluetooth link to stream your track in real time. When SA grabs the link, Live.τ’s session is dropped.

This happens only on Android. On iOS, Suunto App is far more restricted in the background and doesn’t run a permanent service, so the conflict doesn’t appear.

Together, these points explain the periodic disconnect/reconnect behavior you may see.

In practice this shouldn’t break your recording: the S+ app on the watch reconnects in about a second—essentially one event-loop tick—so no data should be lost. Still, the reconnection is a little annoying and does cost a tiny bit of extra battery.

⸻

How can we ease the conflict?

Because Suunto App (SA) and Live.τ vie for the same Bluetooth connection, the real limitation lives inside the watch’s BLE firmware.

Temporarily stopping SA’s background service would prevent the clash, but Android doesn’t allow one app to shut down another; In addition I’ve not found any way to stop this service via SA UI, if somebody know how to do that, please let me know it could be a basic recommendation.

Disabling “Discovery” on the watch probably won’t help: SA already has a bonded connection to the watch, and during an active workout the watch generally doesn’t advertise itself anyway, so SA can still reclaim the link.

Ideally we could cooperate with SA e.g., send it an some kind intent that saying “Live.τ is taking the connection now; please pause sync”, however that would require close collaboration with Suunto’s app team.

⸻

What we’ve done so far

In the latest release, Live.τ now shows silent reconnection notifications so the pop-ups are less distracting. For now that’s all we can do.

Hello,
Thanks !
I am wondering if using a Bluetooth device (like a heart rate sensor) might increase disconnections.
How do you update the app? Do we need to download it again? (Not yet available in playstore)

Francesco Pagano

@Nikolai-Simonov said in Live location S+ app:

What we’ve done so far

In the latest release, Live.τ now shows silent reconnection notifications

@Nikolai-Simonov does it mean the app has been updated? I checked PlayStore and didn’t find a new version. After your previous post, I disabled app notifications from the system settings, and now I noticed that the app requires notifications permissions when I launch it, otherwise it won’t move to the home screen
Thanks again for looking into this issue and for the details you’re providing

safari

Hello, the area in the image comes with the results of the training. What is the meaning of this SID code?

duffman19

@Nikolai-Simonov I just used the app for an activity and none of my phone’s notifications came through to the watch. That is, I didn’t see any text or phone calls on the watch. When I stopped the activity, they all came through at once. Is this expected behavior or due to the update you mentioned above attempting to silence the live.t app notifications? Not receiving phone notifications would be less safe and convenient in my case.

(Really appreciate your work, btw.)

Edit: I’m on iOS

Nikolai Simonov

@Antoine

Using external Bluetooth devices like HR monitors, Stryd, or CORE shouldn’t cause any disconnection issues they work independently and don’t interfere with the watch-to-phone connection.

As for updates:
You can still download the latest version as an APK from the website.
Are there no google play version at all? It probably should be live, since yesterday.

The update is currently under review in the Play Store — usually, Google takes a day or two to approve updates.

Nikolai Simonov

@safari

Great question, the SID code isn’t used for anything just yet.

In the future, when we introduce login via Suunto feature, this code will help link the Live.t session with your Suunto workout.

Nikolai Simonov

@duffman19

That’s an interesting observation. I haven’t seen this behavior on iOS before, but I’ll definitely look into it.

Btw, the recent update that silences notifications was only for Android.

It’s possible this is related to how iOS handles background btle connections during an active session, but I’ll do some testing to confirm.