FAA remote ID requirement

Yes, that does summarize, but:

“Broadcasts remote ID messages directly from the UA via radio frequency broadcast” (under option 1)

and

“Broadcast Module may be a separate device that is attached to an unmanned aircraft, or a feature built into the aircraft.” (under option 2)

Option 3 is flying in a designated RID-free area, so a nonissue there.

So my take is a module onboard the craft

Yes, the module definitely needs to be on the aircraft

§ 89.115 Alternative remote identification. A person operating an unmanned aircraft that is not a standard remote identification unmanned aircraft may comply with the remote identification requirement of § 89.105 by meeting all of the requirements of either paragraph (a) or paragraph (b) of this section. (a) Remote identification broadcast modules. Unless otherwise authorized by the Administrator, a person may operate an unmanned aircraft that is not a standard remote identification unmanned aircraft if all of the following conditions are met:
(1) Equipage. (i) The unmanned aircraft used in the operation must be equipped with a remote identification broadcast module that meets the requirements of § 89.320 and the serial number of the remote identification broadcast module must be listed on an FAA-accepted declaration of compliance.

And the other requirements are:

§ 89.320 Minimum performance requirements for remote identification broadcast modules. Remote identification broadcast modules must meet the following minimum performance requirements:
(a) Take-off location. The remote identification broadcast module must be capable of determining the take-off location of the unmanned aircraft.
(b) Time mark. The time mark message element must be synchronized with all other remote identification message elements.
© Self-Testing and monitoring. (1) Prior to take-off, the remote identification broadcast module must automatically test the remote identification functionality and notify the person manipulating the flight controls of the unmanned aircraft system of the result of the test. (2) The remote identification broadcast module must continuously monitor the remote identification functionality from takeoff to shutdown and must provide notification of malfunction or failure to the person manipulating the flight controls of the unmanned aircraft system.
(d) Tamper resistance. The remote identification broadcast module must be designed and produced in a way that reduces the ability of a person to tamper with the remote identification functionality.
(e) Error correction. The remote identification broadcast module must incorporate error correction in the broadcast of the message elements in § 89.315.
(f) Interference considerations. The remote identification broadcast module must not interfere with other systems or equipment installed on compatible unmanned aircraft, and other systems or equipment installed on compatible unmanned aircraft must not interfere with the remote identification equipment.
(g) Message broadcast. (1) The remote identification broadcast module must be capable of broadcasting the message elements in § 89.315 using a non-proprietary broadcast specification and using radio frequency spectrum compatible with personal wireless devices in accordance with part 15 of title 47, Code of Federal Regulations, where operations may occur without an FCC individual license.

Wow, so the rid module must know the take off location. So even a certified adsb transponder doesn’t store or thansmit that data, just the position, altitude etc at the time of the ping.

@khancyr maybe you could explain what have been done in France ?

It won’t be hard to adapt what I have done here with an ESP32 : Open Source French Drone Identification . You will have wifi broadcasting, it will need a new vendor specific number. The takeoff position is set to the first good GPS fix. Simple. No need to be super accurate.

The only pain will be to have the UA to check the RID is active… So mostly use a GPIO to check if it is ok will be the simpler solution. No, need for complex protocol.

4 Likes

I like the solution khancyr proposes - I had concerns that allowing devices to connect to an access point (wifi-specific, I have similar concerns about bluetooth) would raise significant cybersecurity concerns. However the system will require access to aircraft lat/lon/alt in real time… adding another GPS antenna could be expensive. What about a transmit-only serial system from one of the Pixhawk’s serial ports? It could send MAVLink data, and with nothing being transferred from the RID module to the Pixhawk there’s much less likelihood of opening another attack vector.

Am i reading this correctly?

The broadcasted information will basically just need to be takeoff location, location and serial number. The FAA’s also said that they’ve eliminated the “over the internet” idea, and that ADSB out is out as well as to not oversaturate the ADSB frequency for manned aircraft.

I’m not seeing anything so far that requests a centralized network, is this basically just UAV specific ADS-B?

It seems like that to me as well. I haven’t yet seen anything regarding rebroadcasting requirements, although the actual ruling is a long read at best. Also disclaimer: I am not a lawyer, nor even a 107-certified pilot. Just a random interested guy.

[EDIT] It seems there is an option to use a centralized network for better privacy. The unique ID of the aircraft that will be broadcast may be replaced with a session ID. This session ID would be issued by a “Remote ID USS”… not too sure who that is, but it is a form of centralization. It does seem like that’s not something that would have to be fetched by software over internet or something, though.

@apache405 can likely shed a lot of light on this.

1 Like

What bothers me about this rule making is there is only a requirement to broadcast the required data but there is no outline of how one must broadcast that data. The idea of broadcasting would mean that anyone would have to be able to receive those messages, so I think it would need to be on a dedicated radio. (Similar to Khancyr’s work in France with ESP32). Technically that would satisfy the requirements of this rulemaking, but how does anyone make use of this data?
This would be great if everyone was using one method and you could in theory broadcast from your aircraft and then receive messages from other aircraft to know their location and deconflict. But if they are using a different solution that your new onboard RID radio doesn’t understand you don’t end up receiving their RID broadcast.
I guess what I was hoping for/expecting was a more USS/ internet connection focused RID solution

2 Likes

agree with this. it’s surface level reading so far but honestly it seems like it’s half baked idea that they didn’t really finish. I wonder if they’re hoping for industry to form a solution to this that they’ll like, in which case I’m going to try to bake some prototype up with dronekit and a raspberry pi.

I was more hoping for UAV’s to be introduced to the ADS-B network but I can understand the fears over oversaturation, especially if we’re thinking 5-10 years down the line with drones flying over cities being a norm. I’m all for decentralization of this data as it’ll most likely make it easier/cheaper for newcomers to enter and keeps in line with open source.

My guess would be that https://www.astm.org/Standards/F3411.htm will be used as the basis for the technical requirements (I wouldn’t go and buy that standard unless you’re intending to design hardware). Jeff / @apache405 was part of the team who developed that standard. Courtesy of Intel, the required message set has been implemented in mavlink. When the landscape gets a bit clearer I don’t imagine it will take long for a means of compliance to get to market.

1 Like

I made the stand alone version public but you can find on the thread other work with ESP8266, mavlink version, MSP version etc ! That is very simple to work with ESP serie with Arduino Framework.

1 Like

I am not convinced that the FAA is trying to kill off small time operators with this regulation. It’s way too short on implementation details, including frequencies, power levels, and packet formats. Error correction needs to be included? Where? Does the receiver need an app? Who provides that? There’s no “there” there.

I admit I had that gut reaction initially as well, but it seems they’ve made some decent allowances for home-built UA to be exempted from the rules. I tried to summarize these over on the CubePilot forums; I’ll save re-typing the same information.

I do also agree that they don’t detail implementation at all. However, they do seem to have given a not unreasonable amount of paths to investigate:

Since the frequency must be accessible by most consumer electronics, that leaves WiFi, Bluetooth, or NFC, or cellular. I think we can rule out NFC for obvious reasons :stuck_out_tongue: , and cellular since most laptops don’t have that. Personally, I’d be surprised if the solution winds up being Bluetooth… at “high” power levels, my bluetooth devices lose connection after about 50 feet, whereas WiFi can easily go a few hundred with a decent tx (all of this would be directly line-of-sight). That pretty much narrows it to 2.4GHz or 5Ghz, and again for range reasons I’d bet on 2.4. Power levels would be dictated by FCC regs; they stated they don’t make a range requirement because of implementation differences.

Everything else though… \shrug.

1 Like

The FAA “partners” that were announced back in May are as follows: Airbus, AirMap, Amazon, Intel, One Sky, Skyward, T-Mobile, and Wing.

The FAA is going to “allow” technologies that they find “acceptable” for use.

I wonder whether my home brewed Android app is going to pass muster?

Yeah I think they have good intentions here, just that they’re glossing over hobbyists way too much/pretending they dont exist. For small companies and researchers, being able to integrate drones into the national airspace means easy flight waivers and a more efficient bureaucratic future. I know they said over people and night flights but I hope this trickles to easy BVLOS flight waivers as well. Their partner list just bothers me.

Not too well versed in RF but I hope WiFi doesnt interfere with our 2.4ghz transmitters or video.

I’m using everything EXCEPT 2.4, because 2.4 is so noisy already. Now I’m going to add a 2.4 emitter to an airframe that’s already at 30dBm on 433, 915, and either 1.3 or 5.8GHz. It’ll be like a brass band going overhead.

1 Like

Your vehicle is emitting at 30 dbm on three bands?

Wow! Is it large?