Overview

By U.S. Dept. of Transportation, Federal Aviation Administration, - Aeronautical Information Manual, https://www.faa.gov/air_traffic/publications/media/AIM_Basic_dtd_10-12-17.pdf, Public Domain, https://commons.wikimedia.org/w/index.php?curid=73512575

Wikipedia states the following about Instrument Landing Systems: “In aviation, the instrument landing system (ILS) is a radio navigation system that provides short-range guidance to aircraft to allow them to approach a runway at night or in bad weather. In its original form, it allows an aircraft to approach until it is 200 feet (61 m) over the ground, within a 1⁄2 mile (800 m) of the runway. At that point the runway should be visible to the pilot; if it is not, they perform a missed approach. Bringing the aircraft this close to the runway dramatically improves the weather conditions in which a safe landing can be made. Later versions of the system, or “categories”, have further reduced the minimum altitudes.

ILS uses two directional radio signals, the localizer (108 to 112 MHz frequency), which provides horizontal guidance, and the glideslope (329.15 to 335 MHz frequency) for vertical. The relationship between the aircraft’s position and these signals is displayed on an aircraft instrument, often additional pointers in the attitude indicator. The pilot attempts to maneuver the aircraft to keep these indicators centered while they approach the runway to the decision height. Optional markers provide distance information as the approach proceeds, including the middle marker placed close to the position of the decision height. ILS may also include high-intensity lighting at the end of the runways.”

Our design aims to measure the signal strength of the target frequencies and transmit the data from the edge device to a cloud dashboard IoT monitoring system.  We will use readily available commodity hardware along with open-source software to build a low-cost sensor.  The intent is to perform an extended proof of concept and system test at a nearby regional airport prior to scaling the system across 15 airports for the initial production deployment.  The goal is to expand this service after demonstrating robust monitoring and alerting of the fully developed system.

JungleSTEM has partnered with the client, Aeronav Services LLC, to research, develop, prototype, test, and eventually manage the entire system as a turnkey service.  Spare preconfigured edge sensors will be available to swap equipment in the event of hardware failure of the device.  The client expects to expand its airport management services and demonstrate value added capabilities using the designed system.  A future joint partnership is hoped for that will take the aggregate ILS status information to provide data feeds into other services, potentially integration with mobile pilot electronic flight bag apps and/or Notice to Airmen (NOTAM) bulletins.  Use of this data both in the real-time monitoring system and in other applications will improve pilot safety and awareness while also enhancing pre-flight primary and alternate airport planning.

This project opportunity is the catalyst which led to JungleSTEM moving from a business concept to standing up the LLC and website, putting thoughts into action.  As a result, this project will be uniquely special and distinct from other future opportunities.

Approach

General prerequisites and assumptions: A laptop using the current version of Ubuntu MATE (a lightweight desktop version of Linux) will be configured with the Python/RTL-SDR (software defined radio) libraries with the expectation of the operating system, software libraries, and program code can all be successfully ported without modification to the target Raspberry Pi (or similar x86 or ARM compatible SOC hardware).  This will enable moving quickly from the development and testing environment to proof of concept and edge device production phases.  Further, the edge device will be limited to raw data collection and transmission – in this case we are measuring and uploading signal strength snapshots across the two desired frequency bands.  The tuning frequencies, signal and noise parameters, and alarm/notification conditions will all be handled in the cloud dashboard.  This reduces iterative development cycles on the edge hardware and ongoing system improvements can be implemented in the cloud system.  The edge Raspberry Pi will simply need an appropriate antenna to connect to the SDR USB dongle and a wired LAN connection using DHCP and Internet access.

  • Milestone 1: Test SDR hardware and antenna. Adjust equipment until we are able to accurately measure desired frequencies.
  • Milestone 2: Setup the development environment with required software to build the app. Verify software library dependency availability/compatibility on RPi.
  • Milestone 3: Build basic app to import configurations from text file, loop through frequencies, output status based on measured dB of signals.
  • Milestone 4: Add capability to take status output and push to email and/or online portal. Desirable to have online/offline conditions.
  • Milestone 5: Add capability to monitor up/down status of the monitor itself and push to email and/or online portal.
  • Milestone 6: Port system to Raspberry Pi and streamline software package for efficient deployment on additional monitors.

Initial testing resulted in quick wins and a validation of the general approach.  The first iteration of the system will focus on tuning the sampling rate and transmit intervals to provide a higher resolution than the minimum expected parameters for generating offline alert conditions.  The tradeoff between providing enough data and creating too much chatter is being considered.

The dashboard testing is using basic “temperature gauge” widgets, but later enhancements will include green/red (online/offline) status pins with drilldowns on a Georgia state map view.  We start out by anticipating the following time loops in the process:

  • Sensor polling of frequencies – every 5 minutes
  • Push signal strength data to dashboard – same as #1
  • Assess telemetry data for alert conditions – every 15 minutes
  • Notify when alerts remain uncleared – 30 minutes

This means data would be sent from the edge device to the cloud dashboard on 5-minute intervals, alarms triggered within 15 minutes, and uncleared alarm conditions will send SMS and email notifications at 3o minutes.

Below are some sample pictures of the target hardware.  Note the substitution of an “Orange Pi” board in lieu of the targeted Raspberry Pi – this is due to current supply-chain issues, but this adaptation of hardware is a prime example of why using commodity off the shelf (COTS) components is a benefit over a highly specialized niche hardware board which could remain unavailable for extended periods of time in the current economic climate.  I’m sure there is a quote from Sun Tzu to be had in this flexibility.  The last-minute addition of the Embrava Blynclight will address our client’s “nice to have” request for a visual indication in the airport office of system status in addition to the more detailed information in the cloud dashboard.  It remains to be seen what extra “flair” might be built into the LED light to indicate different conditions, at a minimum this will signal ILS down, but could also show Internet down, etc.  I can already envision using the little light in future projects.

       

Update: Python script written automating data feeds from SDR dongle to dashboard.  This is set to run at system boot so the sensor can be plugged in and the software will start reporting signal data.  embrava Blynclight is now integrated showing the following status indicators: Green – RTL-SDR hardware detected, telemetry data sending to dashboard, ILS signal within range.  Yellow – RTL-SDR hardware not detected or telemetry data not sending to dashboard.  Red – ILS signal below range.

Telemetry data being sent: ILS Locator frequency and signal strength, ILS Glidescope frequency and signal strength, hardware status code.

Testing various conditions and failures by unplugging SDR dongle, removing antenna, changing antenna types and size to assess affect on reception.  Next steps are to finalize dashboard design, including Lat/Long pin location of sensors with drill downs plus varying sensor/dashboard views depending on client access.

Results

Nothing like a real cliffhanger, huh?  Well stay tuned to this same Bat channel for upcoming updates.  We have plans soon to test the system at a local airport.  Until now, The Creek 100.9 FM has unwittingly provided frequency fodder for our tests since this band is adjacent to the reserved ILS frequencies.  And we love you guys and the great music you spin!

Conclusion

Copyright @2023 jungleSTEM, LLC. All Rights Reserved. Contact us by emailing hey at junglestem dot com.