S
SUT1 Replay Server
archived
Academic
Real-time telemetry decoder (Swinburne capstone, HD 90/100).
Cohort lead engineer2025Multi-cohort handoverSwinburne (industry-client capstone)Real-time systems / networking
On this page
Overview
A real-time bridge between sailboat simulators and browser dashboards. It takes in binary UDP and TCP telemetry, decodes it, and streams it to web clients over WebSockets. I inherited a stalled multi-cohort codebase and shipped it to the industry client's requirements.
Tech stack
Python
FastAPI
asyncio
WebSockets
Responsibilities
- Turned a stalled, multi-cohort codebase into a delivered and documented product for an industry client, graded High Distinction at 90 out of 100.
- Built the TCP decoding layer for a binary, struct-aligned telemetry protocol, along with a mock simulator that enabled development and testing without the physical hardware.
- Supported many concurrent browser dashboards by replacing a fragile address-based session key with a stable hash and introducing batched WebSocket distribution.
- Prevented active streams from being dropped by implementing a graceful, session-safe shutdown procedure.
- Enabled the following cohort to continue cleanly by building the frontend dashboards and authoring the project documentation.
I led the codebase through a multi-cohort handover and did the bulk of the shipped work: the TCP layer, session identity, graceful shutdown, the frontend, and the docs. The original UDP scaffold and base protocol decoders came from a prior cohort.
Showcase
How it works
1
Simulator
Binary UDP and TCP packets
2
Decoder
Struct-aligned byte parsing
3
Session manager
One stream per session hash
4
WebSocket fan-out
Batched to dashboards
Engineering challenges
01Picking up a stalled codebase from earlier cohorts
Problem. I joined a project several student cohorts had already touched. There were multiple half-finished branches, abandoned attempts, and no clear working version, with an industry client still expecting something.
Approach. I took ownership properly: pulled the scattered branches together, then made decisions I could defend and undo. Where earlier work didn't fit the requirements I reverted it with a written reason instead of quietly deleting it. I got the main path working first and hardened it after, and at the end I wrote a proper docs folder and kept the old readme around so the next person wasn't stuck where I had been.
Outcome. The project reached a working, documented state and the next cohort member picked it up cleanly, which to me was the real proof it worked. It was graded HD, 90 out of 100.
02Decoding a binary protocol with no hardware to test on
Problem. The telemetry came as raw binary packets laid out to match a C++ struct, and I didn't have the actual simulator to test against.
Approach. I built the TCP side of the decoding and extended the packet formats, parsing with byte-for-byte struct layouts, padding included, and added a small safety net that cleans NaN and infinity values out of malformed packets. To test without the real simulator, I wrote a mock that packs the exact same byte layout, plus an offline decoder to replay captured logs.
Outcome. I could build and check the whole decode path without the physical simulator, and it held up against messy real packets.
03Streaming to many browsers without melting
Problem. Lots of browser clients subscribing to live, high-frequency telemetry, with sessions whose network address keeps changing, and a server that has to shut down cleanly without cutting off active sessions.
Approach. I built the TCP client and manager layer and wired it into the existing UDP and WebSocket flow, sending updates to browsers in small batches instead of one message at a time. I swapped the shaky address-based session key for a stable hash, and made shutdown wait for a second interrupt while sessions were live so it wouldn't yank the rug out.
Outcome. Steady multi-session streaming under load, with clean start-up and shutdown.
What I'd do differently
- The decoders are pinned to fixed binary struct layouts, so a protocol or firmware change means hand-editing byte offsets. I'd add explicit format versioning so a mismatch is caught loudly instead of being silently misread.
- Sessions live in memory, so a restart wipes them. I'd persist session state if this needed to survive restarts.
External links
Interested in this kind of work? Get in touch