Mesh In The Sky – Part (Mavic) 2

A few months ago, I used a low-end GPS-guided camera quadcopter to see how a micro-mesh node (the GL.iNet USB150) would work at altitude. This time, I experimented with a higher-end model, the DJI Mavic 2 Zoom.

After the field test we did in July 2020, a Ubiquiti NanoStation was temporarily mounted near the point we had tested on WJ0X’s end, and I permanently mounted my Rocket M2 over my garage door. Our two nodes could occasionally contact one another, especially at night, but any kind of inclement weather or daylight hours seemed to cause connectivity issues. Recently, I noticed the link had remained down for an extended period of time. This experiment started off with me trying to fly a similar payload to my last effort, with the intent to bridge our two networks temporarily with a small airborne mesh node to restore connectivity, if only briefly.

The DJI Mavic 2 contains a dizzying array of optical and infrared anti-collision sensors, so strapping things directly to the bottom of the vehicle will trip it up a bit. There are 3rd party accessories that allow for mounting things on the top or sides of the airframe in such a way to avoid blocking any of the sensors there, but I opted to just dangle the payload below the quadcopter with a length of fishing line. To attach it to the vehicle, I used a velcro cable-organizing strap I had laying around, positioned around the body in such a way as to not obstruct any of the sensors on the bottom. If you look closely to the right, you can see the thin, clear 4lb test fishing line coming off of it. This was tied to the center of the strap under the quadcopter.

The first payload was an old Goal Zero Switch 8 USB battery pack, with the same GL.iNet USB150 node plugged into it. I built a stabilizing harness out of zip ties, so that I could attach it to fishing line.

Craning the Mavic 2’s on-board camera downward, I confirmed that I was hovering between my QTH and Jay’s, and that I had a clearing beneath the vehicle so that if it had to land, or if the payload came loose, it would be both easily recoverable and not cause any damage to property. I was around 150 feet off the ground so that I could clear the rooftops of other buildings with line-of-sight between the payload and my Rocket M2 at home.

This is about the time I found out that Jay’s node had been taken offline until it can be permanently mounted on the roof. I guess I should have chatted with him on the morning net before trying this HIHI. I confirmed that the USB150 works just fine more than 1500 feet (450+ meters or almost 1/3 of a mile) away from my Ubiquiti Rocket M2 as long as there aren’t any obstructions. I hovered in this location for about 5 minutes before bringing it back home.

Last time, I said I’d think about flying with the GL.iNet AR150-EXT, a slightly more powerful travel-router, with an external SMA antenna connector, and a better antenna. The quadcopter I used last time would not have been able to hoist the payload easily, but the Mavic 2 seems to be able to lift half a kilogram worth of payload without any problems at all. With Jay’s node still offline, I am not expecting to make contact with another node. As was mentioned in my last “Mesh In The Sky” post, the nearest active nodes are 8 or 9 miles away, the kinds of distances you’d likely need directional antennae for. But I tried anyway. The AR150 and omni-directional antenna were attached to the battery pack so that when it’s lifted, the antenna points straight down.

You can see the approximate distance I put between the vehicle and the payload here. These are still connected to one another with fishing line, which is not easily visible.

I hoisted the payload up to an altitude just below 400 feet, which is the legal limit for most recreational unmanned flights of this nature. Again, I positioned the payload and vehicle somewhere a bit out of the way for the hovering maneuver so that potential damage to life and property is reduced.

While the payload dangled 400 feet in the air, I checked connectivity to the node above, this time with the USB150 plugged into my laptop. The AR150 remained connected to both of my AREDN mesh nodes at home but after hovering for about 8 minutes, never did pick up any of my distant mesh friends.

We continue to make headway, slowly, here in the Kansas City area, with frequent Zoom meetings to coordinate the setup of new nodes and discuss the results of site-surveys. Hopefully by next spring we’ll have some better mesh coverage through a few local hospitals and emergency operations centers.

Western Johnson County Field Test – 2020-07-26

Bill (KA2FNK) has been trying to orchestrate a field test between myself (KD0NRC) and Jay (WJ0X) for a few weeks. Jay and I live in Western Lenexa, KS — about 0.3 miles apart, but we both have antenna restrictions, and there are a number of structures between our homes. Bill’s initial survey tells the story pretty well. It doesn’t look promising.

Still, the distance is close enough, we had to try it just to say we did. Here’s a map also provided by KA2FNK.

Jay had not yet purchased any AREDN-capable mesh equipment yet, but KA2FNK brought along a Ubiquiti NanoStation M2 as well as a NanoStation LOCO M2 — a smaller, less-powerful, lower-cost unit. My initial setup on my end was using some painters’ poles attached together, with my Rocket M2 as high up in my driveway as I could get it. This was about 17 feet up in the air. Yeah, it’s sketchy. The antennae are some “high gain” omnidirectionals that I bought ages ago for wireless penetration testing with high-power Alfa adapters. They’re not optimal for mesh networking, but they’re what I’ve been using for years on this specific mesh node.

On WJOX’s end of the link, we set up a tripod on the upper level of the deck, and pointed the NanoStation M2 toward my place.

We moved it around the deck quite a bit, experimenting with locations and headings while watching the real-time signal graphs. From this end, we would see LQ (Link Quality) values in the 20-30% range, but 0% NLQ (Neighbor Link Quality). What this means is that there’s traffic flowing, but not bi-directionally. The antennae on the Rocket M2 at my place isn’t picking up the transmissions from the other end of the link.

I took KA2FNK’s LOCO M2 back to my place and replaced the Rocket M2 with the LOCO M2. The LOCO has lower power, but the integrated sector-antenna is likely better for longer-distance connections. Within a few minutes, we’d established a link!

I decided to try setting the Rocket M2 up again, but with a yagi-style antenna. This didn’t work very well at all, but when I moved the one omni-directional antennae to a horizontal position to get it out of the way of the yagi, I got a call over the radio that whatever I did helped. I re-attached the other rubber-ducky omni and aligned them parallel to the ground, or “horizontally polarized” if you will. I also moved the Rocket to a location that would be closer to a potentially-permanent mounting point.

The weather-resistant cover is missing here…

At that point, we noticed both LQ and NLQ quality metrics spiked pretty high, in the 70-95% range from both sides. This was better link quality than we got with the LOCO at my location. Parties on both ends of the link were able to browse other remote nodes (for example, I could access the GL.iNet USB150 that KA2FNK had plugged into his laptop, and KA2FNK could see the three nodes on my end, and access the WAN.

Here, I am browsing a remote device at WJ0X’s home, through 3 mesh hops:
my USB150 -> My Rocket M2 -> KA2FNK’s NanoStation 500 meters away -> KA2FNK’s USB150
It’s hard to tell from this angle, but the NanoStation is actually below the level of the structure, without any obstructions, other than the buildings between us.

At this point, we declared the the test a success. WJ0X is going to pick up a NanoStation M2 and we should have a permanent RF mesh link between our homes. The horizontal polarization thing is going to require some further investigation. The NanoStation and LOCO M2 both “look” like they’d have a vertically polarized signal, but evidence suggests they largely rely on horizontal-polarized signals.

Mesh in the sky

I decided to send a mesh node up on one of my quadcopters. This one isn’t all that powerful, but it has GPS guidance so it can stay in one spot while I experiment. I powered the GL.iNet USB150 Microuter with a 3.7v Li-poly pack from one of my smaller quadcopters and zip-tied it to the bottom.

I set up my laptop and Rocket M2 next to the BattleVan™ and made sure everything was connected.

I got the quadcopter up to 110m (360′) above ground level. The Microuter saw no other mesh nodes aside from my Rocket M2 — Not even the AR150 indoors.

The below graph starts at 110m, the signal spike was about 20m up in the air on the way down, not when it landed. After a while, I took off again and got to about 60m up before the low battery return-to-home kicked in. The graph ends with my drone on the ground about 3m from the rocket.

The antenna on-board the Microuter is tiny, and it’s not a very powerful radio to begin with. I may try flying the AR150 up in a similar fashion. It’ll likely involve stripping it out of the plastic case, but there would be a better antenna. I’m not really expecting to find another mesh node, even 400 feet up in the air, since the nearest nodes I know of are 8-10 miles northeast of me and I’m not using a directional antenna between sites.

June 2020 KC Mesh Status Update

It’s been a while! I moved back to the Greater KC Area after a few years in Austin. Interest in an amateur radio mesh is growing, and we have a group of about 20 active participants. While I was away, Tom K0JPR, Bill KA2FNK seemed to lead the charge.


We’ve all agreed to run AREDN-approved platforms and rely on the latest stable version of AREDN. As of today, that’s aredn- We’ve also agreed on frequency and channel width standards for the 2GHz band. We’re waiting to explore the use of 3GHz and 5GHz bands for point-to-point links, and we have a plan for building out the backbone. The backbone plan hasn’t changed much since our earlier work years ago, but thanks to the work being done in the past year, the group has a more formal relationship with stakeholders that can help us build the backbone.

The backbone sites are mostly hospitals and emegency management offices. These places are currently very busy and have restricted access for volunteer staff, so most backbone efforts are on hold.

K0JPR started a KCMesh group on He is hosting a map of our local mesh, and is also running an AREDN VPN server for locals to join. Contact him on our page details.

I put together a Getting Started Guide that supplements AREDN documentation, which has become quite comprehensive. My goal was to provide some assistance in choosing a hardware platform, convey my experience setting up a mesh network to experiment with at home, and share guidance on the advanced networking aspect of managing AREDN nodes.

We’ve started holding virtual meetings every few weeks via Zoom. These meetings and their recordings are announced via our forum and mailing list. I encourage folks to join the group and attend the meetings as they can. I know a few folks who are “Zoom averse” – I’d still recommend calling in via phone. Between the current pandemic situation and how spread out the participants are, it’s unlikely we’ll have large, in-person gatherings. We’ll probably have small, local teams working in groups to test the mesh.

While we wait for the ability to make progress on the backbone, we’re focusing on building “mesh islands” — small, neighborhood pockets of mesh nodes linked to the VPN over the Internet. Ideally, we will grow the mesh to the point where reliance on Internet infrastructure will be replaced by point-to-point mesh radio links and more .widespread coverage of the KC metroplex.

Ubiquiti/AREDN tests

Yesterday, KD0HKI and KD0NRC did some testing of the latest AREDN build on two Ubiquiti Rocket M2 radios. Notes from that test (and plans for what’s next) can be found here.

We’re planning another distance test next weekend, likely the morning of Saturday, July 16th.  We’re going to be working out the action items from the notes in the coming days, specifically: borrowing better antennae and identifying several pairs of locations to test at.

Updated links and a KM3SH Map

We have added a few more links to our first post. The KC HSMM Google Group remains the most official of the discussion spots, however, plenty of interesting and relevant conversations happen elsewhere on the Internet.

There is a KM3SH Map that we’re keeping up-to-date with your input. Please join the Google Group and give us your node info if you have set up a permanent mesh node somewhere and would like it added to the map. Yellow dots are current nodes online at residences. Green dots are online at a business establishment. Red pins are planned backbone infrastructure. None of them are online yet, but we expect some will go live in 2016. We’ll update the map with a new designation for backbone nodes that are  online and linked.

Firmware update: BBHN-1.1.0 released

Broadband-Hamnet announced yesterday the release of BBHN-1.1.0, which adds official support for some Ubiquiti 5.8GHz devices, and back-to-back links (e.g. setting up a 5.8GHz mesh backbone with 2.4GHz last-mile links to individual endpoints)

Check out the release notes for full details, but the new firmware does change the SSID yet again, which means upgrading a device will separate it from an existing mesh with older HSMM-MESH or BroadbandHamnet-v1 SSIDs.

Currently, all known KM3SH affiliated nodes are running BBHN-1.0.0 or a compatible build. We are still designing the deployment details, and will likely ask everyone to upgrade to 1.1.0 once we’ve tested it.

KM3SH: Meshing Kansas City!

KCMARC is a group of amateur radio operators interested in high-speed mesh networks in the ham bands. Specifically, we’re focusing on a wide-spread implementation of Broadband-Hamnet/HSMM
in the greater Kansas City area starting with the I-35 corridor.

Below are some relevant links:

(Updated links on 2016-03-12)

Near-term club goals

Three serious club goals loom, in order from most important to least:
1. Design the specifications for a basic mesh infrastructure, including long-haul links between towers and rooftops, as well as concentrators for endpoints (likely consumer grade hardware) in the field.  This should include a parts list of everything needed for major infrastructure sites.
2. Brainstorming and creation of useful applications that can run alone on the mesh without any additional Internet connectivity, preferably the kind that facilitate easy, minimal-configuration ways for users at different endpoints to communicate with one another be it via text, audio or video.
3. Get basic infrastructure coverage of the I-35 corridor from Olathe or Gardner up to Downtown KCMO. We already have a few possible locations for backbone-style nodes near I-35, and several folks from KCHEART are interested, which may result in backbone nodes and concentrators on several area hospitals, both near and well outside the I-35 corridor.