Desktop analytics platform for the Indian Railway Speed and Energy Monitoring System.
Monitoring devices on locomotives record detailed journey data—speed, energy, events—that engineers need to analyse and report on. The raw output from these devices is binary and completely unusable without software built specifically to decode it. I built the application that bridges that gap: load recordings from SD cards or USB, parse them into structured data, and surface everything through filterable reports, time-series charts, and composed PDF exports ready for operational review.
A core constraint shaped the architecture from the start: the application needs to work in environments where internet access cannot be assumed. These devices operate in remote areas, depots, and fieldwork settings—connectivity is unreliable or simply not there. Running everything locally with no server dependency wasn't a simplification, it was a requirement. Data stays on the machine, analysis happens offline, and the tool is usable anywhere the device is.
The people using this daily are operations engineers, not software engineers—so it had to be fast, reliable, and self-explanatory across Windows and macOS. It ships as a signed installer on both platforms, produced from a single CI pipeline, with no manual packaging steps required.
The devices produce binary output in multiple formats, each with its own structure, field layout, and edge cases. Parsing binary data correctly means handling byte alignment, distinguishing between valid records and noise, and gracefully dealing with corruption—partial writes, truncated files, and malformed records that occur naturally in field conditions. The parser had to be defensive enough to recover from bad data without silently producing wrong results.
I had no designer, no senior to review my decisions, and no existing pattern to follow for this kind of tool. The filter system spans multiple tabs, each needing independent state but sharing the same UI panel—a non-trivial UX problem I had to reason through on my own. A lot of the design work happened in cycles of building, using it myself, noticing what felt wrong, and iterating. That process taught me more about interface design than any resource I've read.
Embedding charts in PDFs required rendering them as images during generation—but the UI framework and the PDF pipeline have conflicting threading requirements. The rendering process needs to happen on the UI thread, while PDF generation runs in the background. Getting these two to cooperate without deadlocking, particularly on macOS, required understanding where the conflict originated and separating the rendering step from the export pipeline entirely using offscreen rendering techniques.
Independent filter contexts across tabs
Deadlocks in PDF generation after offscreen fix
Signed installers shipped from one CI pipeline
Records processable — SQLite, local, no server
This is a private project — but I'm happy to talk through the engineering.
Ask me about it