Live location S+ app

Nikolai Simonov

Today I continue teaser the 1.0.18 features, and tell about feature that I personally use really frequently!

Personally I’m used to planing workouts by visual cues and landmark.
Instead of running 400m high tempo 200m rest etc etc… I’m planing my workout like

warm-up from home to embankment around 10 min
on embankment from start to the first crossroad - tempo run
rest till the court,
then tempo till the fish restaurant… etc… etc…

it’s pretty difficult to measure structured workout in exact timing… to real city world…
traffic lights… segment length couldn’t be clearly 400m you can run bit different way…

So in Live.τ i can create x-line trigger checkpoints. It allows me trigger Lap (or send message on watch, or some zapier automation) in exact time when i crossing my visual cue and don’t care to tap lap manually, or trying to fit structured workout.

Here is how it works:

set checkpoint on map and chose cross line type
adjust the line by dragging ends, specify trigger direction
seta an action what to do on crossing line - mark a new lap, send some message to your watch, or even trigger custom zapier/n8n/make automations
when you cross the line, the app automatically triggers an action

there’s a really short video how to set x-lines

https://drive.proton.me/urls/0BMZ1NQWKC#gTFZ0RwegQEB

GiPFELKiND

@Nikolai-Simonov hey Nikolai had many Breaks today with Connection! Last Version and a second bug: i import a route ITS 44km but the live App only shows 23km and ends in top of the Mountains… Whats Up? ![Bild Text](Bild Link )

Nikolai Simonov

Hey @GiPFELKiND !

could you share .gpx of this route?

GiPFELKiND

@Nikolai-Simonov Mittenwald_Trail_ZUT_2025_fa6c0d4010(2).gpx

Nikolai Simonov

@GiPFELKiND said:

Mittenwald_Trail_ZUT_2025_fa6c0d4010(2).gpx

Thanx! I looked this track, found an issue.

TL;DR - it’s a bug in preproccesing tracks, to avoid it you should use gpx with route not a track that bypass preprocessing.

The root cause is here:

gpx format has a two tags for holding routes
<trk> and <rte>

<trk> - represents a saved by device route and usually contains timestamps on points, telemetry extensions etc…

<rte> - represents planed route by some software.

in live.τ we can use both of them, however for <trk> we’re making some preprocessing to reduce amount of points on straight lines, collapse stops etc, it allows us save quite a lot of cpu and memory while navigating, but, you found a bug in this preprocessing, due to this route points in <trk> tag app thinking that it’s a recorded route and should be sanitized, but sanitizing faced up with issue in it’s logic trackpoint without timestamp and gap more than 100m - algorithm decides it looks like a malformed gnss data - no timestamp and speed probably more than 100m/s and cut it out.

so in fix i’ll add euristic if point not contains timestamps probably it might be proceed like a route not a track…

but anyway i suggest use gpx followed standarts.

And thank you for bug report

GiPFELKiND

@Nikolai-Simonov okay thank you! Thats the official route from UTMB Homepage from the Zugspitz Ultra Trail in 1 Week. The UTMB share this official route!

Nikolai Simonov

@GiPFELKiND yep, it could. it created via outdoor active as i see in the metadata. but frankly, not every software follows standards, so, neither good nor bad just a fact.

GiPFELKiND

@Nikolai-Simonov what about the fact with the Break while run a Activity? I never had a complete track…suddenly the watch says Error… And did not track again. Yesterday 28km Trailrunning! Lost 3 times the Connection? End the Activity at suunto watch, start again…

Nikolai Simonov

@GiPFELKiND

What phone model? and what error?

also on lates android build, knowing issue if you app swiped out from activity list, you probably could lost connection, fixed but not released yet.

in general race for BTLE connection between suunto app and live.τ app still exist, but observation said that it’s not a big deal, and connection works in general well. personally i usually lost connection in some difficult areas near military objects, or radio polluted regions… not sure if it’s your case.

you can try to the latest apk build here - https://artifact.fra1.cdn.digitaloceanspaces.com/live-t/apk/1.0.18/live-t.apk

or if you use google play join internal builds here - https://play.google.com/apps/internaltest/4701596347369604163

Tamon Yanagimoto

Just purchased a Race 2. Updated to newest firmware. I installed LiveT on my phone (iOS) and on watch. I activated it in the run activity and was able to connect to my phone. The watch and the phone connect. Unfortunately after that my watch freezes then reboots. After watch reboot when go back to the run activity the watch freezes again. My watch looped on the “The device is being restored to a safe state” then it did a hard reset. I’m also trying to do a structured interval plan I created. Are there any know conflicts with that?

Nikolai Simonov

Hey @Tamon-Yanagimoto!
nope, never heard this behavior, is it happens if you try use Live.τ + structured workout?

Adrian.S

This year, I’ve already run 3 ultra races, each about 60-65 km (6-7 hours). Every time, I share my location via LiveT (Android, Pixel 8).

I ran the last one on Saturday.

On every run, after a few hours, my location stops being shared - it disconnects from the watch or something else happens. I don’t have time to figure this out while I’m running fast, so I just ignore it, but this is a major flaw for Suunto.

I use the Vertical 1.

I thought maybe it was because Android was killing the app in the background… So, as a last run, I made sure that battery saver mode was turned OFF and that the app could run in the background without any restrictions.

It didn’t help.

When I noticed that my location was no longer being shared, I opened the LiveT app on my phone and saw that the button was turned OFF.

I tapped the ON/OFF button to turn it ON, but it couldn’t connect to the watch anymore.

I think you’ll need logs from the watch or the app, but if you’re not a developer, it’ll be hard to fix this.