uAvionix Release Remote Identification White Paper

uavionix

Makers of the popular brand of MAVLINK and DJI compatible drone ADS-B, uAvionix, have released a Remote Identification white paper. Expect ADS-B and surrounding technology to be a hot topic in the next 18 months. Whilst opening the recent FAA UAS Symposium, FAA Administrator Michael Huerta announced a new Aviation Rulemaking Committee (ARC) on Remote Identification.

A look at uAvionix product offerings show that they are moving into the general aviation arena with products designed to make the FAA 2020 ADS-B mandate less of a shock for private pilots.

It’s very pleasing that the OpenSource autopilot project, Ardupilot, was ADS-B enabled several years ago, the Ping receiver from uAvionix is plug and play.

There is less resistance to ADS-B from the drone world, I don’t think it is all of the solution but offers better situational awareness for drone operators.

By Christian RamseyPresident – uAvionix

We engaged our colleagues at Airmap and Harris for their inputs on the solutions as well, and give them due credit for their contributions. When putting it together, we spent some time on what we thought were the appropriate set of requirements for such a system. We go through this in the white paper, but in this forum, I’d like to share the list of assumptions regarding the requirements (since none were given).

1. The primary purpose of the RID solution is for law enforcement or security personnel to remotely identify the sUAS aircraft and operator through a number of key parameters to be transmitted from an RID transmitter on board the sUAS and received by receivers which may be handheld, permanently mounted, on board other aircraft, or anywhere within range of the RID transmitter.

2. Other functions beyond the primary purpose stated may serve to increase the utility of the RID system, but benefits of additional functions must be weighed against additional cost or time to feasible widespread deployment. For example, an RID solution may aid in surveillance or Detect and Avoid (DAA) applications, but any such specific requirements may delay implementation of RID.

3. Data items transmitted from the sUAS RID would include at a minimum the FAA UAS registration number and sUAS position. This concept is not unlike a license plate on a vehicle or an N-Number on an aircraft which can be used by an eyewitness of a dangerous event to provide information to law enforcement for further investigation.

4. Considerations for spectrum congestion must be considered. With the potential for very high-density sUAS traffic in the future, efficient use of spectrum is required to not adversely affect system performance. Means for mitigating spectrum use include, but are not limited to low-power transmissions, minimal transmission payload, transmission intervals, frequency modulation, and transmission only as a result of interrogation.

5. Size, Weight, and Power Consumption (SWaP) of any RID airborne devices should be consistent with sUAS platforms. The smallest aircraft should be targeted to support the maximum number of sUAS possible. This includes popular consumer models which are being used for professional purposes.

6. Considerations for anti-spoofing or source verification should be included.

7. The cost/price of RID devices should support regulatory mandates which would require compliant RID devices on a significant quantity of sUAS – possible quantities for consideration include:

RID devices on all sUAS over 0.55lbs (consistent with Part 107 registration requirements)
RID devices on all sUAS registered to licensed Part 107 operators or organisations

8. Installation options should range from solutions which are an integrated part of the sUAS “out of the box” as delivered by the sUAS OEM to those that are purchased and installed as “add-on” or “aftermarket” units.

9. The ground-based component should offer a range of options which include receivers which are portable in nature, those which can be permanently installed, and those which work with and without LTE or internet coverage areas.

To see how we envision addressing these requirements, please download and read our white paper.