Hello AREDN folks,
I have two nodes connected near the beach (Marina Del Rey, CA) running parallel to the beach about 4 miles apart. I'm using Ubiquity Nanostation M5's. Successfully running.
On my first try, I tried to connect to Mt. Wilson in Los Angeles on just the standard Nanostation (no dish), if I point it NE just right, it may show up. But it comes and goes. It says LQ of 100% but NLQ is 0. OK I figure it is too far at 27 miles and I may need a dish.
So I continued with stage 2 of the deployment plan which is to connect local nodes. This is where I realized that these devices have directional antennas and they can't really receive/transmit from more than a narrow beam.
If the intent is to connect many stations in a pod and then connect that pod to Mt Wilson it introduces many practical unanswered problems that make this more complicated. It almost seems to me to that to support a pod, there would have to be be several chained NSM5's at a central point all pointed at different directions and then one with a dish pointed at Mt Wilson?
So this becomes an expensive proposition once you really think about actual deployment even of a few stations. I'm guessing to support 180% you'd need at least 3 NSM5's?
Some other issues. When I'm pointing the NSM5 at Mt Wilson, there's a station in the middle that's always showing up. It's an Adhoc private network. There is no way to blacklist this to remove it from the list since it doesn't appear to be in support of AREDN. It's unidentified. I realize this is on the to-do list (the blacklist), but this this station in the middle of my connection between me and Mt Wilson affecting my reception of Mt Wilson? or will both appear?
And a final thought. Given that each station could be running 5GHZ, 2.4GHZ, and different bandwidths and channels, and it only connects to one that matches, what is the overall plan for bridging these islands when the internet is down? What would happen in a real emergency? I presume these islands are tunneled right now?
73
Rob KN6BSS
You are here
Deployment to Larger Network - The Big Picture
Tue, 06/11/2019 - 01:24
#1
Deployment to Larger Network - The Big Picture
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Let me try to tackle your questions:
“It says LQ of 100% but NLQ is 0.” We see this from time to time. In fact, another user in Long Beach is having a similar issue, so it could be a problem on the Mt. Wilson end. However, it could also be reflections within the Fresnel zone on you link.
“Too far at 27 miles and I may need a dish.” In my experience, Nanostations are reliable to about 14-15 miles. There are notable exceptions that seem to work farther, but I wouldn’t use them in a design any farther
“These devices have directional antennas and they can't really receive/transmit from more than a narrow beam.” Beamwidth is a design criteria. Manufacturers offer a variety of devices with beamwidths from a 3-4° (high-gain dish antennas) to 360° as in an omnidirectional vertical. You need to design your solution (a pod, as you call it, but generally referred to as a node cluster) to cover the area you desire. Nanostations beamwidths vary based on band but range from 45-55°.
“To support a pod, there would have to be several chained NSM5's at a central point all pointed at different directions and then one with a dish pointed at Mt Wilson?” Yes, no question the central node clusters are more expensive. The good news is that the typical ham who deploys to support a disaster will only need a $65-$75 device to connect to the network. Yes, your image of the cluster, comprised of multiple nodes fanning out across the desired coverage area is correct.
“So this becomes an expensive proposition once you really think about actual deployment even of a few stations.” You’ll certainly need to consider your financial resources when deciding to become a backbone implementer. Clubs can be good groups to deploy these mid-mile clusters... building to cover their membership area. Perhaps just build a go-kit and let others with greater resources build out the backbone and mid-mile layers of the network.
There's a station in the middle that's always showing up… no way to blacklist this to remove it from the list since it doesn't appear to be in support of AREDN.” The protocol is designed to accommodate other things going on, on the channel. Don’t worry about them. The “blacklist” that’s on the new-feature list refers to other AREDN nodes, not other wifi nodes, so it would do nothing to eliminate this guy.
“Given that each station could be running 5GHZ, 2.4GHZ, what is the overall plan for bridging these islands.” AREDN devices are designed to be connected back-to-back with Ethernet cables. It’s generally done through an EtherSwitch, but a simple cable between two nodes also works. This allows any traffic between nodes to occur over wire rather than RF. This technique also is used to inter-connect 2 GHz meshes with 5 GHz meshes, etc.
Andre, K6AH
Is there a list of IP addresses and the matching call sign just to find out where these stations are?
I'm in an area that is definitely a hole in the AREDN network. There's no backbone here. I can possibly get a Yacht Club in the Marina to support a backbone. There are 150 Hams in the membership. I'm going to push for it and I can build it for them. And there's an existing antenna tower.
If the idea is to wire different network islands together, then just like backbones, there would have to be a large presence of these multi-channel bridges right? Looking at the maps, they mostly connect via internet tunnels.
I would recommend that the deployment section of the documentation explain this a little. There should a clear explanation that someone may have to provide a backbone if one doesn't exist and how the backbone would have to be constructed.
Thanks for the giving me answers and I expect to be promoting AREDN!
73
Rob KN6BSS
“Does the OLSR protocol pick them over Mt. Wilson? Or the protocol can handle multiple? AND Is there a list of IP addresses and the matching call sign just to find out where these stations are?” The 802.11 protocol handles them. OLSR will pick them up if they are AREDN… and they would be identified by the callsign in the device name. If they are in the ham band and don’t have their callsign in the device name, then they are out of compliance with Part 97.
“If the idea is to wire different network islands together, then just like backbones, there would have to be a large presence of these multi-channel bridges right? Looking at the maps, they mostly connect via internet tunnels.” Actually, most are connected back to back (DtD is what we call it… see the docs for an explanation). You will notice these in the Current Neighbors section with “(dtd)” after their device name. Every backbone cluster and every mid-mile cluster have at least one of these DtD connections.
“I would recommend that the deployment section of the documentation explain this a little. There should a clear explanation that someone may have to provide a backbone if one doesn't exist and how the backbone would have to be constructed.” There are numerous articles on how this is done. My QST article from June 2017 would be a good place to start.
Andre, K6AH
I guess more people will need to volunteer to provide some DtD services :).
I realize that some of the explanations are spread all over this forum. I was just thinking that as someone that just started that it would be neat if this kind of basic explanation of DtD, backbones and such were part of the deployment section of the documentation at least to introduce terms to search for. I would not have learned of it if I didn't ask.
BTW, the "rogue" stations I see between me and Mt Wilson only show an IP address with no node name at all. They do use AREDN-V3-10 on the same channel. Maybe they're part of some future backbone that's not completed yet (since they're pointed away from the Mt Wilson backbone). I presume my router is needlessly wasting bandwidth pinging these dead end nodes. So a blacklist would certainly be welcome whenever that's accomplished.
Rob KN6BSS
Hi, Rob:
"I don't see these DtD's in my area (West LA). Is there some other map I'm neglecting to see?"
Andre said "in the Current Neighbors section".
You said "in my area" and 'some other map".
I suggest that you look "in the Current Neighbors section" on your node's web page:
http://localnode:8080/cgi-bin/mesh
while/when it links with 'Mt. Wilson'.
"BTW, the "rogue" stations I see between me and Mt Wilson only show an IP address with no node name at all."
This is common for nodes that have not yet 'linked' and shared 'networking' information.
This is between your node and that node.
When your link shows LQ >0 and NLQ > 0, the 'Node Name' may display.
Until then, you will only see an IP address.
"(since they're pointed away from the Mt Wilson backbone)"
Rhetorically...? How do you know which way they are pointed? :-|
" I presume my router is needlessly wasting bandwidth pinging these dead end nodes"
I do not presume that. Until the nodes establish a link, it is likely that they are only listening
for other's broadcasts.
I hope this helps, Chuck
Hi Chuck,
"I suggest that you look "in the Current Neighbors section" on your node's web page:..."
Apparently I will need a dish to connect to Mt. Wilson more strongly. I get 100% LQ 0% NLQ on the occasional connection with Mt Wilson. But I was just wondering what the extent of the DtD infrasttructure was in my area (vs. Internet tunnels). The main map on the website doesn't seem to show DtD's in West LA but does show tunnels. I was interested more in the area infrastructure rather than my own specific neighbors (which are very few). I'm in a hole here.
"When your link shows LQ >0 and NLQ > 0, the 'Node Name' may display."
I do have this connection with this rogue or unlinked neighbor station. LQ > 0. NLQ > 0. I read that the absence of a node name may also be a bug that requires it to reboot? Well it is linked. Linked to me only. So I will assume it's a bug.
"Rhetorically...? How do you know which way they are pointed? :-"
My assumption...Since Mt. Wilson is pointed straight ahead from my router and the middle station is showing up as a neighbor, it would have to be pointed within 30 degrees of my direction assuming it's a Nanostation M5 or similar.
I've established from testing and a look at the Polars for the device that it is very directional. Based on my topology, (there's an obstruction), the only way for me to see this station is that it has to be on a rise nearer to Mt Wilson. I'm blocked from seeing nearby stations in that direction. So I'm inferring that it is not likely to be a unit equipped with a shorter range omni antenna.
Thanks for the input Chuck.
73.
Rob
"wondering what the extent of the DtD infrasttructure was in my area"
Hi, Rob:
A typical 'DtD' (Device to Device) connection is an ethernet cable connecting 2 or more 'nodes'.
So, 'DtD'ed nodes are likely within 100 meters of each other.
Two nodes may be 'DtD'ed with a single cable. However there is nowhere to add a computer, camera, or whatever.
A 'managed' switch allows 'DtD'ing more than 2 nodes and allows multiple LAN clients and services.
To 'see' the 'extent of the DtD infrastructure was in my area' you will need to link with a node in that network.
You could go 'war driving'. My car has a 110VAC outlet in the back seating area. I have
'rolled up' a nanostation in a rear passenger window and driven around the neighborhood
of a mesh node site. With a laptop to view the localnode:8080 pages, I can browse network connections.
Uh, browsing while parked. ;-)
HTH, Chuck
The Southern California mesh, extending from the Santa Barbara area to the Mexican border, and east past Palm Springs, is comprised of primarily RF links. While various groups do support Internet tunnel connections for areas being built out or for Amateurs with "challenged" locations, most of us view this as "experimental" or "educational", since Internet links will likely not be available during an emcomm situation (such as a major earthquake).
Most of the local mesh groups do make extensive use of device-to-device (DTD) linking of co-located nodes. For example, all of the nodes on Mt. Wilson are dtd-linked, as are the nodes at Huntington Hospital in Pasadena. This provides for seamless connection of nodes operating on different bands, and also handles your concern regarding "pods" pointing in different directions being linked.
There are quite a few active nodes between your generic location in Marina del Rey and the Mt. Wilson southwest 5 GHz sector. There is an active cluster in Culver City, and several in the Los Feliz/Silver Lake area. All with solid links to Wilson. One of these nodes may be what you are seeing.
Keep in mind that even directional devices exhibit back and side lobes. You may also be seeing signals being reflected off a building or other obstruction.
You, and anyone in the Southern California area, is always welcome to join us at our fourth Saturday "Activity Day" each month at Huntington Hospital, West Tower Conference Rooms (adjacent to the Cafeteria). We will be having Activity Day on June 22 at 9 a.m., before Field Day (due to construction at the Hospital we are not conducting our own Field Day this year).
While our Activity Day meetings are not exclusively mesh-related, AREDN is always discussed, and quite a few mesh users (and their gear) are always in attendance. So its a good opportunity to meet the local mesh community and share information.
Gary S. Wong
W6GSW
KA6ECT Trustee
Pasadena-San Gabriel Valley Emcomm Mesh
District Emergency Coordinator
Northeast District, Los Angeles Section
Amateur Radio Emergency Service
I am aware of the Culver City cluster but my base station is not able to see them (blocked by a hill). I can see Redondo but apparently no nodes there are pointed my way. So the only way to the backbone from my base station is to Mt Wilson (over a hill). With a single node in Marina del Rey, I cannot cover my base station and still reach Culver city. Looks like the only solution is to add a DtD node.
And thanks for confirming what I already assumed to be the case with the SoCal setup. I'm excited nevertheless. I can perhaps coordinate creating a backbone in MDR if I can get enough people interested.
And glad to meet someone from the SoCal community!
Rob
The reason for the question is not the pollute the Mesh but thinking about practical uses of VOIP. At the moment, I'm imagining the value of VOIP from my two nodes and I'm realizing that another ham operator has to answer the other end. Which doesn't allow me to test since there's only one Ham operator in my household.
Or would bridging this (from Ham to Non-Ham and possibly only one way) through some other network be necessary? A lot of legal potholes here...
Or perhaps there's some interpretation I haven't seen yet.
Rob KN6BSS