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.
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.
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.
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.
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 ^.^
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?
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?
, 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.
So to sum up, there are only 3 things that are hidden behind all those thousands and thousands of words: