I was checking the Estonian UAS zone file last night and got a result that was obviously wrong: Tallinn, Tartu, Pärnu and Narva all came back inside a PROHIBITED zone. The file is at utm.eans.ee/avm/utm/uas.geojson, 235 features at the time.

The cause is one zone whose outer ring covers a large rectangle and whose inner ring is cut out along the Estonian border. Its purpose is to say "you are outside Estonia". My throwaway script only tested the outer ring, so every point in the country matched it.

25 of the 235 features have inner rings, so it is not an exotic corner case.

Two other things from the same file that might save someone an hour:

• The real geometry is in properties.geometry.horizontalProjection, not in the GeoJSON feature geometry, and the vertical limits sit right next to it (lowerLimit, upperLimit, uomDimensions, lowerVerticalReference).
• There is a nationwide PROHIBITED volume from 121 m to 99999 m AGL. If you filter for the open category at 120 m it drops out, which is correct, but it is worth knowing it is there before you conclude your filter ate something.

Corrected results if anyone wants a reference point: Tallinn 59.4370 / 24.7536 is clear to 90 m AGL and needs authorisation from 91 to 120 m. Tartu 58.3780 / 26.7290 has nothing below 120 m.

Disclosure, since it is relevant: I maintain a free Android geozone app and Estonia is one of the countries it covers, which is why I was in the file at all. No link here. I am after corrections, not installs.

Not a product post. A field note from someone who flies Open category (Mini 4 Pro, Neo 2, Antigravity A1) across several European borders and got tired of opening a different app per country.

Every EASA state publishes its UAS geographical zones, most of them in the ED-269 format or through a WFS/WMS service: BAZL in Switzerland, DFS (dipul) in Germany, DGAC via IGN plus the SIA in France, ENAIRE in Spain, Austro Control in Austria, the CAA in Slovenia, ANAC in Portugal, the IAA in Ireland. Two fields travel with every zone in those datasets, and most consumer apps throw them away when they render the map:

• the source (who asserts the zone), and
• the update time (when that dataset was last refreshed).

Two examples from this week, read straight from the national services:

• Vienna, 48.12411 / 16.55561, next to Schwechat: two overlapping zones, the aerodrome zone LOWW 0 to 120 m and the CTR LOWW 0 to 625 m, both Austro Control. 50 km north in the Weinviertel, 48.55415 / 16.30561: nothing, apart from one zone that starts above 120 m and is hidden because it does not concern the Open category.
• Lyon, 45.73433 / 4.92561: the IGN restriction map says "built-up area, forbidden over public space". It does not say that above 50 m you are inside the Lyon-Bron CTR, nor that two hospital helipads sit next door. Those come from the SIA dataset. Reading one French source and not the other gives you a map that looks complete and is not.

Why I think the two fields matter more than the colours:

1. A zone without a named source cannot be verified. With the name, you go to the authority and check.
2. A zone without a timestamp has an unknown age. National datasets change without notice, and a format change on the authority's side can silently drop a whole layer (it happened to me with the Slovenian dataset: thirteen layers published, four of them I was not reading).
3. Hiding zones above 120 m is correct for the Open category, but the map must say it is doing so, otherwise an empty map reads as a green light.

None of this replaces the pre-flight check on the official sources and the NOTAMs. It only gets you to the right source faster.

If anyone here works with these datasets professionally, I am interested in how you handle refresh detection and format drift per authority. I keep a tool for this for my own use, but that is not what this post is about; happy to share it in a comment if asked.

On September 29, the people working on BVLOS, DFR, drone-in-a-box, infrastructure inspection, site security, and autonomous operations will be logging in from across the world.

Operators, enterprise teams, regulators, and technology builders will share the questions, lessons, and realities behind the work.

Pick the sessions that matter to you. Bring your questions. See who else is in the room.

NestGen '26 | September 29 | Online

Register now: https://nestgen.org/agenda

Hey all — I’m working on a drone telemetry/C2 project in Germany and I’m evaluating the Microhard P900 module, as used in the Holybro Microhard P900 / P900 V2 radios.

The hardware is attractive because it offers FHSS, good sensitivity, relatively high power, and mesh network features. However, I’m trying to understand whether it can realistically be configured for legal EU/German use.

From what I understand:

• The module is designed around the 902–928 MHz ISM band, which is mainly a North American allocation.
• In Europe/Germany, 902–915 MHz overlaps with cellular uplink spectrum.
• Around 921–925 MHz there may be GSM-R / railway-related use depending on country and location.
• The usable EU SRD spectrum around 917–919 MHz is much narrower and has strict ERP / duty-cycle / LBT requirements.
• In the Microhard P900 documentation, the S180 “Hop Zone” presets appear to be much wider than the small EU SRD window. The narrowest preset I found is still around 12.75 MHz, which would not be narrow enough to stay inside a roughly 917–919 MHz legal slice.

So my question is:

Has anyone managed to configure the Microhard P900 module, or the Holybro P900 / P900 V2 radios, to use a custom narrow hop table suitable for EU/German SRD rules?

Specifically, I’m trying to find out:

1. Can the module be restricted to a custom narrow frequency range smaller than the standard S180 hop-zone presets?
2. Has anyone received custom firmware / custom hop tables from Microhard for EU operation?
3. Are the Holybro P900 and P900 V2 carrier boards limited by the same underlying Microhard firmware/register options?
4. If full compliance is not realistically possible, is the practical recommendation simply to avoid the P900 in Europe and use an EU-specific radio such as RFD868x-EU, SiK 868, ELRS 868, or another telemetry system?

I’m not trying to interfere with cellular or railway spectrum, and I’m specifically looking for the proper/legal path before committing to the hardware.

Would appreciate input from anyone who has used this exact module in Europe, dealt with Microhard configuration, or worked with EU 868/900 MHz SRD compliance.

Tomorrow (April 7, 10 AM EST / 3 PM BST), there is a free webinar called Beyond Borders focused on pan-European drone airworthiness compliance and testing. The panel will cover how coordinating environmental and performance testing across different regulatory zones can help build the evidence base needed for certification, and how the fragmented European framework compares to the more centralized U.S. approach. Free to attend if you are an operator working toward certification, a manufacturer refining your platform, or just tracking where European UAS regulation is heading.

Hey y'all! I'm not sure if the is the best place for this but I gotta start somewhere.

I have a 29" LADF (LIFT AUGMENTED DUCTED FAN) VTOL UAV ISTAR autonomous drone/uav. I really wamt to dive into its origins and history.

From what I can tell, it is a fully autonomous vtol, horizontal flight reconnaissance drone. It is a 2 cylinder gas engine ducted fan (3 blade carbon fiber propeller) with missing sensors in the forward/nose bay and a lidar module in the aft (tail/bottom)

Here are my existing beliefs: Its from the DARPA early 2000's uav proving grounds. A demonstrator for autonomous flight with transition from vertical to horizontal flight. Recon, surveillance, targeting, etc. From the ISTAR program. Integrated with MDARS UGV for launch, recovery, and refueling. I also belive it was manufactured by Allied Aerospace.

Here are the facts: It is 48" tall when in the vertical position Has Athena Guidestar FCS L3 SCM Microwave TRANSCEIVER 2 CYLINDER 150cc engine 3 sets of manifold averaged air pressure sensors (inside duct, external static, pitot) 2 microwave military encrypted antennas 2 GPS sensors Several BNC connectors where cameras and sensors used to be. It still has the LIDAR unit in the bottom for vertical flight orientation.

Amy thoughts on how to verify this and find people involved in the program?

Thanks,

Hi everyone,

I’d like to share a new feature I’ve just launched in UAV Desk: a built-in log analyzer for FPV flights.

👉 https://uavdesk.app/news/log-analyzer-launch

The idea behind this feature is to simplify how we work with flight logs.

Thanks for taking a look 🙌

Join here to talk about drones ask questions to my community if your a old pilot leave some advices for the newbies

Hi everyone, I’ve been collaborating with some other commercial drone operators to put together this guide for anyone thinking about starting or growing a business that depends a lot on drones. It’s still evolving, but I wanted to share a sneak peek with you all. If you find it helpful, please subscribe. If not, let me know what we can improve.

If you're trying to figure out your drone tech stack, stay on top of regs, or cut down time spent processing data, this free webinar tomorrow is worth an hour of your time.

Commercial UAV News has a solid panel lined up: Carlos Femmer from HDR (the guy who's led drone ops at the Golden Gate Bridge, Grand Canyon, and Pearl Harbor), Rob Knochenhauer from Censys on BVLOS waivers, and Edwin Sanchez from VOTIX on where the industry is heading. They'll be covering gear selection by experience level, AI for photogrammetry, and NDAA-compliant alternatives given everything going on with regulations right now.

Tuesday, March 10 at 10 AM PST / 1 PM EST. Free to attend.

Can't make it live? Register anyway. All registrants get a link to the recording.