Falken Avionics in partnership with Aerovie, Hilton Software, and DroidEFB is offering a bounty of $4,000 to the first developer or team of developers who can provide an open source AHRS implementation that can successfully return an accurate and timely orientation based on raw IMU (3 axis accelerometer, magnetometer, and gyroscope) and GPS data. See below for the functional and non-functional requirements.


“Applicant” means the individual or team submitting an entry in the challenge.

“Bounty” means the single cash prize awarded to the selected applicant. The bounty is currently set at $4,000 and may increase if additional sponsors are added.

“Challenge” means the Open Source AHRS Challenge contest sponsored by Falken Avionics and partners.

“Code” means the source and object code provided by the applicant as part of their entry.

“Entry” means all materials submitted by an individual or team.


  1. The bounty will be awarded to the first individual or team to submit an entry that meets the qualifications and passes the verification process outlined in this document.
  2. Entries must be submitted no later than 5:00 PM CDT on June July 15, 2016.
  3. Entries must include the full name(s) and email address(s) of the individual or team members submitting the entry.
  4. Alls entries must be submitted by email to:
  5. Entries will be tested in the order that they are received.
    1. If an individual or team submits multiple entries, only their last entry will be tested
  6. The bounty is provided as a single payment and taxes will not be withheld. It is up to the winning individual or team members to pay any taxes that result from the bounty payment.
  7. Falken Avionics is the sole judge and arbiter of this Challenge. All decisions made by Falken Avionics are final.
  8. Employees of and contractors to any of the following are disqualified and may not participate in the Challenge:
    1. Falken Avionics
    2. Hilton Software
    3. DroidEFB
    4. Aerovie


  1. The submitted Code provided must be integrated with the Stratux open source ADS-B receiver application (gen_gdl90). The actual AHRS implementation may reside in a separate library but the entry must include code to integrate the resulting orientation data into Stratux in such a way that the resulting data is included in the Stratux GDL-90 message stream.
  2. The submitted Code must be written in one of the following languages: C, C++, or Go.
  3. The submitted Code must be clearly written, follow the coding standards for the Stratux project, and must include detailed comments explaining its operation.
  4. All entries must include an archive (either zip or tar) containing the source Code for the entry. Links to repositories will not be accepted as that could allow participants to make changes to the code after submitting their entry.

Required Functions

  1. The submitted code must meet the following requirements:
    1. Accuracy
      1. The Code must provide valid attitude output to within 1° for both pitch and roll axes under static conditions.  (RTCA Category “A5”)
      2. The Code must provide valid attitude output to within 2.5° for both pitch and roll axes under dynamic / flight conditions. (RTCA Category “A5”)
    2. Calibration
      1. The Code must establish an accurate attitude within three (3) minutes of power on in a static configuration.
      2. The Code must be capable of establishing an accurate in-motion alignment. End-user user interaction (such as a “Straight / Level” calibration button) may be used, but automatic calibration is preferred.
    3. Refresh Rate
      1. When in operational mode, the Code must provide an update rate of at least 10 Hz.
      2. The Code must be written such that latency between the reception of raw sensor output and the output of the corresponding calculated attitude is no more than 200 microseconds, not including delay induced by filtering.
    4. Filtering
      1. The Code should filter sensor data such that the resulting display does not suffer from jitter due to sensor noise. Filtering should add no more than 25 milliseconds additional latency to the attitude output.
    5. Attitude Range
      1. The Code must be capable of operating at all attitudes and capable of moving through pitch and roll angles without succumbing to gimbal lock.
    6. Output
      1. The Code must provide attitude data to the Stratux application as pitch and roll Euler angles.
      2. The Code should support additional formats including rotation matrices and quaternions.

Optional Functions

  1. The submitted code may optionally provide magnetic or non-magnetic heading
  2. The submitted code may optionally provide slip / skid indication.
  3. The submitted code may optionally provide rate of turn data.
  4. The submitted code may optionally provide g-force loading data.

Operational Requirements and Limitations

  1. The Code must depend exclusively on the raw output of the IMU and (optionally) an onboard GPS. No additional hardware or IMU-specific firmware may be required.
  2. The Code may run as part of the Stratux (gen_gdl90) process. If you chose to build the implementation as a separate application you must include bridge code that runs in the gen_gdl90 application and provides the attitude updates in accordance with the Refresh Rate and Filtering requirements.
  3. The Code must operate on a Raspberry Pi 2 Model B without causing any degradation to the other functions performed by the Stratux application.
  4. The winning entry will ultimately be used in portable devices (FlightBox, Stratux, etc.) which may be installed or mounted in various configurations. The applicant may stipulate an initial orientation for the device, but any other calibration must be automatic.


  1. The Code must be licensed under the MIT or BSD open source license. This allows anyone to make use of the code for any reason, including commercial applications.
  2. The Code may include or make use of existing open source libraries or source code so long as they are licensed under the BSD or MIT license and you include copyright notices and /or attribution as required.
  3. The Code may use existing algorithms so long as they are not patent encumbered or proprietary.

Reference Hardware

  1. Each entry will be tested using sensor packages based on the InvenSense MPU line of integrated IMUs. Reference hardware includes:
    1. RY835AI GPS + AHRS
    2. RY836AI GPS + AHRS
    3. IMU board sold by community member “Lithuanianamerican”
  2. Note that while the sensor packages may include a magnetometer, the unmanaged environment in which the system operates makes reliance on the accuracy of the magnetometer questionable. Entries may not require location of the hardware in a magnetically isolated location.

Reference Software

  1. The Code should operate with the latest released version of Stratux as of the date of submission.
  2. The Code must operate with the latest released version of the Stratux application used on FlightBox as of the date of submission.
  3. The Code must successfully interoperate with the attitude and synthetic vision features (if available) of the following applications:
    1. Aerovie
    2. DroidEFB
    3. WingX Pro 7


Each entry will be tested to determine if it in fact provides a valid attitude solution at any actual orientation, including unusual attitudes and acrobatic attitudes.

To verify that an entry successfully provides attitude we will test fly a Stratux system outfitted with the reference hardware and running the code supplied with the entry. The output of the system will be displayed on several of the reference EFB applications.

To qualify, the test system must meet the performance requirements outlined above. Testing shall be conducted using the methods provided in RTCA DO-334 as applies to category A5 AHRS systems.


The following documents / sites may include some information that will get you moving in the right direction.

RTCA DO-334, Minimum Operational Performance Standards (MOPS) for Strapdown Attitude and Heading Reference Systems (AHRS) – Available from ($175 fee for non-members)

The Camel Software blog –