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: import recordings from SD cards, USB drives, or directly from the device over a serial connection, parse them into structured data, and surface everything through filterable reports, time-series charts, and composed PDF exports with an in-app preview before saving.
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. It had to be fast, reliable, and self-explanatory. Charts downsample large datasets automatically so the interface stays responsive regardless of file size. It ships as native installers on Windows and macOS, 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 older machines, required understanding where the conflict originated and separating the rendering step from the export pipeline entirely using offscreen rendering techniques.
Infrastructure to procure. No server, no accounts, no connectivity.
Of journey data stays on the machine it was imported on.
Install to go from raw device dump to analysis. The runtime ships inside it.
Every review ends in a document a reviewer can file, share, and act on.
This is a private project, but I'm happy to talk through the engineering.
Ask me about it© 2026 Tanish Nahata