@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 
, 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?
It is simple! They DO NOT CARE about YOUR safety or ANYONE’s safety. They DO NOT CARE about security and privacy. What THEY are saying is what business lobby is saying - small/non-commercial drones will increase costs of development of the commercial UAV/drones, because development of each and every safety subsystem costs huge pile of money, so it is cheaper to avoid even that needs. At least for now 
So to sum up, there are only 3 things that are hidden behind all those thousands and thousands of words:
- Your drone has to broadcast its position so that commercial ones will be able to make an avoidance maneuver by using algorithms from the 19th century - costs reduction;
- You have to register your position so that the business can sue you in case if their 19th’s century avoidance will not work - costs recovery;
- You have to ask businesses (FAA and similars are for a quite a long time office of lobists) if you can fly in random places so that they can even prevent the use of a 19th-century algorithm for avoiding collisions because of no collisions at all - business risk reduction.
Don’t read it as hate (yes, it is, but not in the current context). Having this in mind you can clearly understand the new legislation, its intention, and its purpose; and what is more important how properly implement it on your custom UAV.
1 Like
During the NPRM, I commented that RID could easily be done using off-the-shelf components (ESP32) broadcasting the aircraft’s location and ID over LORAWan. And if there is no LORAWan node in your operating area, then publish the data online from a receiver at the control point.
Total cost in production quantities would be around $15 each.
1 Like
Remote ID isn’t about business, it’s about law enforcement- i.e. that any law enforcement officer anywhere can point his or her phone at any flying SUAS and know who is flying it and where they are located.
As DJI has already demonstrated previously (via a wifi enabled phone app), and how was likely demonstrated by the FAA to law enforcement agencies just a few weeks ago.
All we need is a carrier service to take our telemetry data (such as yaapy) and broadcast to the UTM. I believe AirMap and other similar companies are already providing this service.
Remote ID isn’t about business, it’s about law enforcement- i.e. that any law enforcement officer anywhere can point his or her phone at any flying SUAS and know who is flying it and where they are located.
The question is why they should do that? Is there any statistically proven risk from hobbyists drones? No. Can this prevent terrorist attack? No. Who can be tracked this way? Law abiding, regular hobbyists, who, for sure, have no evil intentions or thoughts and so it is pointless to use that “possibility”. And if hobbyist would like to be evil and make some kind of crime, it will disable such a subsystem, so again this possibility is useless.
So who can be benefit from that? Business - because they can call for police and ask them to shutdown the drone and penalize owner because this hobby drone increases a risk their shitty software to crash ^.^
3 Likes
Hi,
while getting into the topic of A2 license in EU I read class C2 needs a “remote id” as well. I’m not really sure if there is an agreed solution yet, what the timelines are and so on but I like the idea of using an ESP32.
So my question is: are there any plans to add that as feature to Ardupilot / MissionPlanner?
Thanks,
Axel
Some work is being put here: Open drone ID
Also, here an example of a transmitter implementation with an ESP32: https://github.com/sxjack/uav_electronic_ids
I am not very deep into the subject but also interested to see how it evolves and its compatibility with Ardupilot.
Anyone on this forum from @TBS Crossfire?
Why we cannot use existing hardware such as TBS telemetry that contains Lat/Long, Speed, Alt, heading status from the FC and it is capable of connecting with laptop or Android devices via Bluetooth/Wifi? Once you have the basic telemetry data from the FC receiving on the GS it can be broadcasted to the internet real-time. No new hardware required.
So what part of the Remote ID compliance is missing from the above suggestion?
For remote ID in the USA it’s the model itself that is supposed to broadcast the signal in a standard format. It doesn’t go on the internet.