A stable antenna feed
The Radarcape provides data at about 10 Hz and the antenna system also expects a 10 Hz feed. Retransmission logic maintains the required fixed-rate supply when incoming updates do not align exactly with that cadence.
Systems engineering · legacy modernisation · operational tooling
Airspace
Visibility
A decoupled Python suite that replaced the LabVIEW tool used to track a flight-test telemetry antenna. It turns live ADS-B positions into the fixed-rate aircraft-position feed expected by the antenna controller, while independent operator, coverage and recording tools remain outside the critical tracking path.
Operationalproduction flight-test tool
2 sitesin operational use
10 Hzposition feed to the antenna system
0.1 Hzbackground Recorder sampling
01 — The operational need
Keep a directional telemetry antenna supplied with the aircraft position.
During flight tests, a directional ground antenna receives engineering telemetry from the helicopter. Maintaining that link requires the antenna to follow the aircraft automatically; manual guidance is possible, but substantially harder because the instrumentation engineer must interpret orientation from north and estimate where the helicopter is.
The operational chain is: helicopter ADS-B broadcast → Radarcape ADS-B receiver → Python software suite → antenna controller → physical antenna movement.
The software supplies the aircraft position. The antenna-control system knows its own location and performs the calculations required to orient the antenna physically; this application neither controls the motors directly nor computes motor commands.
02 — Why replace the legacy tool
Windows 11 triggered the work; maintainability made it a modernisation.
My manager assigned me to replace the existing LabVIEW tracking tool and provided an initial Jira list, mostly short requirement statements and checkboxes. The immediate trigger was the move to Windows 11.
The LabVIEW application might still have run in compatibility mode, so this was not an absolute technical blocker. It was, however, ageing, difficult to maintain and tied to a licensed environment with limited internal control.
Moving to Python removed the LabVIEW dependency, created a maintainable codebase the team could own, and made it possible to add capabilities users had requested for years. The result was therefore a functional modernisation, not a one-for-one port.
03 — Requirements engineering
Short Jira requirements became testable system behaviour.
I knew the legacy workflow but was not the primary domain expert. The real process was iterative: initial Jira requirements → development → first tests → user feedback → clarification → additional requirements → further implementation.
Configurable prototypes
Operators select a prototype from a drop-down. Callsign and ICAO address are held in configuration, so additional internal prototypes can be added without changing the core software.
Visible validity
ADS-B validity states distinguish usable data from missing or invalid data, including absences that can be consistent with an aircraft on the ground. Affected indicators turn red when attention is required.
Physical antenna behaviour
Near the antenna, a configurable zone deliberately adjusts the altitude supplied to obtain the appropriate acquisition behaviour during hover, landing and take-off profiles.
A non-critical interface
Tracking must continue if the Dash interface is closed or fails. Visualisation is useful to the operator but cannot be a dependency of the antenna feed.
Sites are configuration
Antenna position, prototype definitions and prepared terrain coverage are site assets. Adding a location should not require major changes to the core software.
Helicopter ADS-B
Identity · position · altitude
Radarcape
Receives aircraft broadcasts
Acquisition & distribution
Makes validated aircraft state available
Tracking & antenna feed
Selects prototype · supplies position at 10 Hz
Antenna controller
Calculates orientation · moves antenna
Recorder
Persistent prototype position history
Dash dashboard
Map · trail · status · cross-check
Offline terrain workflow
Swisstopo terrain tiles→GIS / command-line processing→Altitude coverage layers→Interactive map
04 — Resilient architecture
Independent components keep visualisation off the tracking path.
The Python suite is deliberately decoupled rather than monolithic. Each component has a clear operational responsibility and can be maintained or restarted without turning the dashboard into a single point of failure.
Operational tracking path
Acquisition and distribution
Receives aircraft data from the Radarcape, applies the relevant validity handling and makes the state available to the other components.
Tracking and antenna-feed component
Applies the selected prototype and site behaviour, then supplies the aircraft position to the antenna controller at its expected 10 Hz cadence.
Independent operational consumers
Plotly Dash dashboard
Provides prototype selection, an interactive map, recent track, status visibility, coverage and independently calculated theoretical azimuth and elevation. If Dash fails, tracking can continue.
Recorder
Monitors configured prototypes in the background and, while a prototype is detected, in range and valid, records its position every ten seconds in one CSV file per day.
Prepared and deployed around the suite
Terrain-coverage workflow
Downloads and processes the required Swisstopo terrain tiles into coverage layers for a configured antenna location.
Windows packaging and configuration
PyInstaller executables let operators run the tools without maintaining a Python environment; documented configuration separates prototypes and sites from core code.
The dashboard is not on the critical path. Closing or losing the visual interface does not by itself stop the tracking component from continuing to feed the antenna system.
05 — Fixed-rate feed
The 10 Hz requirement is an interface obligation.
Radarcape aircraft data is received at about 10 Hz, while the antenna system expects its position supply at 10 Hz. The arrival timing and the fixed output cadence are not assumed to be perfectly aligned.
Retransmission or upsampling logic therefore supplies the latest valid position at the required cadence. The software does not turn repeated values into new measurements.
No dead reckoning, prediction or advanced interpolation. Validity remains explicit, and the tracking path does not blindly continue using aircraft data once it has become invalid or stopped arriving.
Requirements learned with users
A misunderstood checkbox exposed the physics behind the requirement.
My first implementation of the near-antenna requirement was wrong because the short Jira statement did not explain the antenna’s acquisition and directional modes, or how their gain changes with geometry and height.
Instrumentation users explained why directional tracking can lose signal when the helicopter returns very close to the antenna during some hover, landing and take-off profiles. I corrected the design to use a configurable zone and deliberate altitude adjustment that prompts the appropriate acquisition behaviour.
The resulting behaviour avoids repeated manual mode changes and reduces signal losses in those phases. It is a concrete example of turning user feedback and physical-system understanding into a corrected requirement and implementation, without claiming a measured quantitative gain.
06 — Interactive map and terrain coverage
Altitude-dependent visibility replaces a site-specific static map.
The legacy LabVIEW interface used a fixed map and coverage that was largely specific to one site. The replacement provides an interactive map with zoom, current aircraft position and roughly 120 recent positions — about 120 seconds of track history.
An offline GIS and command-line workflow downloads and processes Swisstopo terrain tiles. It models terrain rather than buildings, which matches the main obstruction in the Alpine operating environment.
For each antenna location, the workflow generates an approximate visibility area over a radius of about 30 km, in 500 ft altitude slices up to about 20,000 ft. The dashboard selects coverage according to the helicopter’s current altitude.
The same process can prepare a new location from the antenna coordinates and the relevant terrain data. That supports multi-site deployment without embedding each site into the core application.
07 — Failure handling and operator cross-checks
Invalid data becomes visible instead of looking plausible.
The architecture is resilient through separation and explicit state handling; it does not claim redundant receivers, automatic failover or high availability.
Aircraft data becomes invalid
The tracked-aircraft state is marked invalid, the relevant indicators turn red and the antenna-feed logic does not continue to trust invalid positions blindly.
An absence is operationally plausible
Validity handling accounts for cases such as an aircraft on the ground, so every missing value is not presented as the same failure.
The dashboard fails
The tracking and antenna-feed component can continue because Dash is an independent consumer, not a step in the critical path.
Manual guidance is needed
The dashboard independently calculates theoretical azimuth and elevation from the known antenna and aircraft positions to support an operational cross-check.
No direct antenna feedback is claimed. A commanded-versus-actual comparison was considered but abandoned because the available antenna interface was not reliable or maintainable enough for a clean integration.
08 — Progressive operational validation
Repeatable simulation first, then real hardware and live flights.
Validation moved deliberately from controlled inputs to the complete operational chain. Simulation was a starting point, not a substitute for hardware and flight evidence.
- 01
CSV fake mode
Recorded positions can be replayed in a loop, creating a repeatable aircraft trajectory for checking selection, tracking behaviour and the antenna-feed chain.
- 02
Live Radarcape and real traffic
The software was connected to the installed receiver and exercised with current ADS-B traffic at an active airfield.
- 03
Real aircraft circuits
Aircraft flying circuits were used to verify visually that the physical antenna followed their trajectory.
- 04
Risk-limited helicopter flight
A real helicopter flight was selected to limit operational risk while checking antenna behaviour, aircraft tracking and actual telemetry reception.
- 05
Operational flights
Several subsequent flight tests completed successfully with the Python suite as the antenna-tracking tool.
09 — Current status
Operational on two flight-test sites.
- Production use
- The system is complete and used during flight tests. The LabVIEW tool is no longer the primary tracking system, and no development is currently required on the core suite.
- Deployment model
- The software is packaged as Windows executables with PyInstaller. Part of the suite runs on a server operating continuously, including background monitoring and recording; users access or launch the dashboard from their workstation.
- Recorder history
- Configured prototypes are logged independently of active telemetry sessions at 0.1 Hz when detected, in range and valid. Daily CSV files are retained over the long term, providing a last available position and trajectory history if an unexpected event occurs.
- Operational handover
- Wiki pages, README, user and configuration guides, development context, troubleshooting material and operator cheat sheets document how to start, configure and diagnose the system without my direct presence.
- Future sites
- A further site is planned. Adding it primarily means configuration, antenna coordinates, terrain-data preparation, coverage generation and environment deployment — not redevelopment of the core system.
10 — Demonstrated change
The operational capability became maintainable, visible and transferable.
Legacy
Ageing LabVIEW application and licence dependency
Replacement
Windows 11-compatible Python suite packaged for operators
Legacy
Static map and largely single-site coverage
Replacement
Interactive map with altitude-dependent terrain coverage and reusable site generation
Legacy
Tracking and visualisation coupled in one tool
Replacement
Independent tracking, Dash and Recorder components with a protected operational path
Legacy
Prototype and site changes tied closely to the tool
Replacement
Configurable callsigns, ICAO addresses, antenna positions and site assets
Legacy
Manual intervention near the antenna during some profiles
Replacement
Configurable near-antenna behaviour shaped with instrumentation-user feedback
Legacy
Limited operator status and test support
Replacement
Explicit validity indicators, theoretical angle cross-checks, replay mode and first-line troubleshooting material
Legacy
Position history linked mainly to active use
Replacement
Persistent background position logging for configured prototypes, including outside active telemetry sessions
Impact is reported qualitatively. No measured workload saving or tracking-accuracy improvement is claimed. The demonstrated outcome is a maintainable replacement now used operationally, with clearer state, safer separation, broader site support and documented handover.
11 — My role
Sole software developer and end-to-end technical owner.
My manager defined the initial need — replace the existing LabVIEW tracking tool — and supplied the first Jira requirements. I then clarified requirements with users, designed the decoupled architecture and developed the complete software suite as its sole developer.
My scope covered Radarcape integration, the antenna interface, tracking behaviour, the Dash dashboard, terrain and coverage processing, the fake and replay tools, the independent Recorder, operational-validation support, PyInstaller packaging, configuration, documentation and troubleshooting material.
My manager supported parts of the physical deployment, notably installation of the new Radarcape. Users contributed the domain knowledge needed to clarify operational behaviour, and their feedback drove subsequent iterations.
This was technical ownership, not project management. I did not initiate the project, manage a programme or own the antenna hardware. I owned the replacement software and its integration from clarified requirements through operational deployment and handover.
12 — Engineering takeaways
Requirements are learned through use
Short requirements became reliable behaviour only through first tests, user explanations, corrected assumptions and iteration.
Understand the physical system
The near-antenna logic only made sense once acquisition and directional antenna behaviour were understood, not merely the checkbox wording.
Protect the operational path
Keeping Dash and Recorder independent means useful services can fail or be maintained without automatically stopping the antenna feed.
Handover is part of the architecture
Configuration, Windows packaging, troubleshooting states and operator documentation let the system run without its author present.