New FAA regulation requires remote ID modules to be installed on drones. Any idea what these modules will look like? Will the be mounted on the drone and plugged into a UART port for GPS data? Will they connect to the radio transmitter?
What are people’s thoughts?
I suppose if you can broadcast the drones location speed and altitude it could be done from the ground right?
And build more sub 250g craft!
Possibly. Although to outfit what I have would require many air radios 
The way I read it it would likely have to be broadcast from the aircraft over “radio frequency (likely Wi-Fi or Bluetooth technology).” They also make allowances for aircraft with builtin RID and a RID broadcast module, so it doesn’t matter if it’s a Pixhawk-builtin thing or a separate module.
My money is on a UART-based setup similar to a telemetry radio…
(It also says “Operational rules take effect 30 months after the effective date of the rule.”)
I read it that the crafts position, altitude and speed have to be broadcast in addition to the pilots position. Doesn’t this summarize it? Where the transmitting device is doesn’t seem to matter.
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.
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.
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.
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
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.
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.
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.