[Discussion] Share your projects

[Łukasz Szmigiel]

@AYamshanov how do you interface with the Vertical 2 via USB?

[Ze Stuart]

@AYamshanov this is great. Nice work! Same for @syncbypass. I’m not convinced Suunto will approve of this work, but having control over my own hardware is really interesting.

[AYamshanov]

@Łukasz-Szmigiel The interface with the Suunto Vertical via USB is a multi-layered process where the SDSApplicationServer (a closed-source native binary) acts as a bridge. High-level clients, such as the VS Code extension, communicate with this server via WebSockets on port 9002 using a JSON-based REST API. The server then translates these JSON requests into an opaque, proprietary TLV binary protocol that is transmitted to the watch over USB HID.

Since the low-level protocol is undocumented, interfacing with the device requires a “blackbox” reverse-engineering approach. By mapping the open-source JavaScript logic from the VS Code extension and capturing the resulting USB traffic via Wireshark, one can correlate JSON inputs with binary outputs. While this is a complex task, leveraging AI significantly accelerates the process of identifying patterns in the hex dumps and automating the decoding of the protocol.

[guderaber]

@Łukasz-Szmigiel I tested it on my race s and it worked although i had to make some adjustments to prevent crashing. But it definitely needs more testing and optimisation

[Łukasz Szmigiel]

@guderaber yeah I’ve learned it’s the hardest part as Suunto doesn’t document the actual hardware limits and it can’t be tested reliably in the simulator.

[Łukasz Szmigiel]

@AYamshanov this is super interesting! Happy hacking!

[Ze Stuart]

@AYamshanov are you getting into Ghidra yet?

[AYamshanov]

@Ze-Stuart Great question! It actually reminds me of how my deep dive into the Suunto ecosystem began. For me, these watches aren’t just sports gear; they are a technological puzzle - kind of like Sudoku, but with more hex code.

After OpenSuuntoPlus launched, I was desperate for app examples to help me write my own. I decided to dig into the firmware, hoping to find the “real” apps hidden inside. I found several files, including a filesystem snapshot, but it wasn’t just a simple sequence of bytes. Instead, it was a massive pile of small blocks scrambled in a seemingly random order.

To better understand the algorithm, I decided to learn what Ghidra was all about (having never used it before). I naively thought watch firmware would be small, simple, and easy to analyze. I was… overconfident, to say the least!

However, it was incredibly productive. I spent time forming hypotheses, checking memory chip specs, and diving into SDKs for embedded OS memory management. I even managed to “de-fragment” a working disk image from those scattered blocks, though I’m pretty sure a few bugs are still lurking in there.

Around that time, I realized the role SDSApplicationServer plays in the system. I shifted my focus to the JSON-based REST API it uses. I figured if the VS Code extension could manipulate watch data through it, I could too. Ultimately, using the server was a much faster way to get data off the watch, and it largely confirmed what I’d spent days piecing together from raw blocks.

So, back to your question: Now that I have a better grasp of the architecture, I’ve been exploring how to communicate with the watch directly via the browser. Remembering my experience with Ghidra - and noting that the firmware is tiny compared to the SDSApplicationServer binary (which is dozens of megabytes!) - I haven’t quite summoned the courage to go back to this approach!

Analyzing serial interface dumps feels more manageable; control commands are usually just dozens of bytes. The more you work with them, moving from simple to complex, the clearer it gets. There are still plenty of mysteries left, but that’s exactly why I enjoy this “Sudoku” - it keeps things interesting!

[Ze Stuart]

@AYamshanov ah this is great: we share a mindset and a hobby! Making sense of compiled firmware is is challenging, to say the least, I’m not shy at sending Claude with a headless Ghidra session when I’m short on time.

[DonTomGot]

First of - thanks to Suunto for opening up the possibility to enrich the marvelous watch lines with features that many users has been missing! It is always amazing to see where the combination of ingenuity and a development platform takes us.

Being a road-runner with some sort of ambition to optimize races I have been missing a race pacer that allows for freely defining pace segments. The races in have participated in (Gothenburg area, Sweden) are most often pretty hilly and I have found that I waste energy in the wrong places and therefore needed an app that could help. The requirements were pretty close to “RaceWarden Pacer” - but I was still missing the possibility to define the distance for the various segments of the race. And. With age comes poor eyesight, so I needed BIG (and clear) numbers to control the pace.

The logic/thinking:
You define you pacing strategy based on profile of the race and potentially other factors - this is all done outside of the app. Example from “Göteborgsvarvet”:

The pacing strategy is pushed to the app through user defined app settings:

Segment Distances (km or mile): 2.45 1.79 1.36 1.36 6.59 7.8
Segment paces (min/km or min/mile): 5:18 5:03 5:37 4:55 5:12 5:14

(Is it possible to have two input fields in app settings?)

With the user input the total race length is calculated by adding the Segment Distances (21,35km) and overall race target time (1:51:26) as well as target pace (general) is also calculated.

Then comes the tricky part. What is really needed / what can be displayed to help pacing (remember: poor eyesight)? I removed heart rate as I have found it does not work (for me) during races, and landed in the following configuration:

• Segment Target Pace: Derived from user input and displayed once a segment is recognized/completed
• Segment Pace: Calculated. Similar to Lap Pace but utilizes the user defined Segment Distances/Segment paces
• Total Seconds ahead/behind Race Plan: Defined as the deviation between race plan and completed distance/time
• Needed Pace: Based on initial user input finishing time and total race length are calculated. This is the pace needed for the remaining part of the race to reach the target

What would you see as missing?

The remaining challenges:

• I would like to have (I believe) at least some indication on heart rate - but I am not able to get the standard zone gauge to work and lack the skills to create one by myself with the canvas mysteries
• Compatibility - I believe maximizing fonts will be problematic for smaller watches but have not really had the energy to investigate what/how to make sure it works also for smaller displays
• Contrast - to me it seems yellow offers the best contrast, but is it just my eyes or a more common phenomenon?

All input welcome! (unfortunately it seems my application for the partner development has got lost in the mail, as I applied many weeks ago)

Also - I used the app (very successfully) during a recent race!