[Discussion] Share your projects
-
@guderaber your app seems pretty complex on the processing side. Did you test it on the watch alongside other S+ apps? Does it crash other apps?
-
@SyncBypass Great stuff! Your project actually got me thinking about different ways to interface with the device, and I’ve been experimenting with a web-based approach. The idea was to see if I could use the browser to access the watch directly for quick tasks without any setup.
As a small experiment, I’ve managed to get a basic filesystem viewer working to explore the internal folders: https://wfhub.net/flasher

My long-term goal is to see if it’s possible to build a simple generator for custom watch faces that could be uploaded right from the browser. It’s still very much a “work in progress” and a bit of a research project for me at the moment.
I’m curious to see where your project goes, and I’m still trying to figure out if there’s enough community interest in these kinds of DIY tools to keep pushing further. Anyway, thanks for sharing your progress!
-
@AYamshanov how do you interface with the Vertical 2 via USB?
-
@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.
-
@Ł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.
-
@Ł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
-
@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.
-
@AYamshanov this is super interesting! Happy hacking!

-
@AYamshanov are you getting into Ghidra yet?
-
@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!