Hi, I should probably do more testing before asking this question, but I thought there might be a simple answer someone with more experience could provide. Here in SW Utah, we are setting up an AREDN data network. We have 3 Mikrotik mANTbox 15 s sector nodes up around the "downtown" area. One on the county EOC building and the other 2 on high ridges that overlook downtown and also see other outlying areas. These nodes form a roughly equilateral triangle about 2.5 miles on a side, fairly close together. One of these radios is in a great location and sees much of the surrounding outlying area. The downtown connections are working well, but when we test connections from this well placed node to more distant outlying locations 6-8 miles away (a Mikrotik LHG dish), we get a reasonable S/N on the chart display (~25dB) but only see the RF ip address of the neighbor and none of the rest of the mesh. Normally you might see the RF IP address at the beginning of a connection but this soon resolves into the "official Node Name" and a connection into the mesh. After 5 minutes of good S/N we still see only the RF IP on the outlying dish. So, we have a good connection that is from the source we want but it seems unusable if you want to reach the mesh. I thought maybe it has to do with packet timing and the short distances seen in town and longer distances to the more remote node. Maybe we need to give it more time to sort the distances out. It was 108 degrees when I was testing out in the bright sun, so 5 min was all I was willing to wait ;-).
Thanks again!!! KF7YRS --Lee
Thanks again!!! KF7YRS --Lee
I did not find a question in your post.
I read 3 nodes in the downtown area and then read 'one on the ... building and 2 on high ridges overlooking downtown'.
I am somewhat baffled as that seems to contradict.
I also do not know if or how these nodes might connect: RF, DtD, internet?
You mention "These nodes form a roughly equilateral triangle about 2.5 miles on a side, fairly close together."
I would assume that each these three antennas are aimed to establish a connection with the other 2, but
later mentioned is "One of these radios is in a great location and sees much of the surrounding outlying area."
Is this one radio aimed at the other 2 or the 'surrounding outlying area'?
Next is mentioned a 'well placed node 6-8 miles away' and 'we get a reasonable S/N on the chart display (~25dB)'.
Is that '~25dB' on the chart from 'All connected stations' or solely the node 'in a great location' or other?
Does this 'well placed node' link with all 3 mANTboxes or is it a 'hidden node' to 1 or 2 of them?
' Normally you might see the RF IP address at the beginning of a connection'.
True, but it would be a good plan to wait until the link has been up for 5 minutes before making measurements.
'After 5 minutes of good S/N we still see only the RF IP on the outlying dish.'
IMHO, SNR is easily misleading. LQ/NLQ is a much better indicator of link quality.
Always strive for 100% LQ/NLQ. If it is not 100%, its function in a network will degrade.
' I thought maybe it has to do with packet timing and the short distances seen in town and longer distances to the more remote node.'
Yes, in PtMP or 'mesh' topology packet timing can be an issue, but a well configured LQM can mitigate the severity.
Generally, 'mesh' topology efficiency will not be as good as PtMP, and PtMP efficiency will not be as good at PtP.
I have often done 'wardriving' with a Mikrotik SXT in the passenger window of my car while stopped at 'well placed' locations, but
I have found that antennas at 4 to 5 feet of elevation to be a very poor indication of performance compared to antennas
at 50 to 125 feet elevation.
73, Chuck
I have not seen this behavior before and my question is: Is this kind of behavior characteristic of some known incorrect setting or the hidden node problem or ??? that more experienced meshers would recognize? Thanks again, I'm going to retry this connection tomorrow.
Thanks again --Lee
+1 with Jim K6CCC's suggestions.
Critical:
It seems LQM settings are not allowing, at least, your LHG to link.
Are W7MHB, K7MSS, and EOC all 100% LQ/NLQ?
73, Chuck
I am gathering that the EOC node is the one closest to the word North. What direction is that sector pointed. From your description, it sounds like the south and east nodes are at least roughly pointed towards the EOC node.
In the long term, you may end up with a separate set of nodes for the linking between the three nodes, and then using the existing nodes as your user nodes and get them onto different channels. That will help a lot with the hidden node problem. You may also end up changing the pointing of the user nodes since they no longer need to point to each other for linking. That will depend on what the coverage requirements are.
As you will see, there is another mANTbox 15s I didn't mention and it is on ch148. "EOC-1" is the ch144 node we have been discussing. "EOC-2" is DtD to EOC-1 and pointing a different direction (E). It is not yet connected to anything. It is much better positioned to reach K7MSS (LOS) and we may switch K7MSS to ch 148 for our future hospital / health dept connections. Enough for now... Thanks --Lee
Do not use channels below 166. No channels are exclusive any more but at least stay out of the traditional wifi trash area. Use 10MHz width for your client sectors.
With LQM turned ON on the sectors, distance values are more of a logical filter than a packet timer so just leave it at default (or set to 20 miles to cover the whole area). If LQM is off for debugging purposes set it to just beyond your farthest user.
Glad to see a new mesh coming up!
Ian:
Hmmmm.
I have serveral very good links among channels 131<>141.
YMMV, eh?
73, Chuck
It's easy to link over medium long distance on another frequency by using a $70 SXT for the link. Put all the sectors on different channels, then add one SXT to the mast on the channel of the distant sector you want to link to. The narrow beam makes it work. Drop the SXT power to the lowest that will keep the link 100/100 and things will speed up dramatically.
From your diagram I'd say you could put all three sectors on different channels, and buy two SXTs for the links and put both on the mast at EOC. Put one of the SXTs on the channel for W7MHB and the other SXT on the channel for K7MSS. The LHG can stay on the channel for W7MHB. Once links are established, explore how much power you can reduce on the SXTs and LHG and still have 100/100 and a good Mbs. New stations will connect to the three sectors.
Ed
I retested the connection that started this discussion thinking that maybe getting all the LQs up to 97-100% on the sectors and moving K7MSS to ch148 might help. It didn't, and today's longer test with the LHG showed reasonable S/N but no connection into the mesh, just like the last test. Today I waited 20 minutes for the problem to resolve, it never did. As you can see, the neighbor status page showed the quality at 96% but the status as idle. The built-in AREDN help defines idle as:
- "idle: the link is usable and would be active but the node routing table does not yet have a route for sending traffic across the link." Any idea what would cause this? My understanding is that the nodes cooperate to build a router table. The link sure didn't look usable to me ;-) I tried this connection with the LQM on and off. S/N was better with it on.
Thanks for all the suggestions, we will implement them as best we can. We are quite familiar with SXTsq nodes and will use them on the shorter connections. --LeeYou've got some good posts each one has different things to consider. One thing right now is that you're changing more than one thing at a time and there are devices you didn't disclose before. You will figure it out no doubt but ... one thing at a time please.
Channels under XXX are ok so long as there is no active interference. You can check that out with the wifi scan or the waterfall package. Same is true of channels ABOVE XXX. Measure and adjust.
LQ Manager settings could be complicating this. Also, the LQ from the neighbors page is pretty much useless, you need to focus on the LQ/NLQ numbers from mesh status. If you're wondering about mesh stability, run MTR or WINMTR and watch to see where things are stable and where they are unstable.
It's hard to troubleshoot from afar. Next post, list every node, it's channel, and the LQ/NLQ reported from mesh status all in the same post. What you did before but also list the total channel listing. Someone smarter than me will spot the issue(s).
Ed
PS ... looking at your map again, I wonder if you really need three sectors all pointing inwards at the same real estate. Just saying ...
Of the RF nodes that are up in the air, there are 4 sectors, the first 3 I described, and EOC-2, which I did not. I did not realize that sector to sector linking was not the best idea, so we were linking 3 of these together EOC-1, W7MHB and K7MSS on ch144. Today we changed that to linking EOC-1 <-ch144-> W7MHB and EOC-2 <-ch148-> K7MSS. The LQs are better this way. I attached the mesh status views from the perspective of the 4 sectors, the only RF nodes in the mesh besides in home hAPs and GL-inets. You can see their connections from the total mesh image. --Lee
Nothing wrong with multiple sectors covering an area as long as they're on different channels. In fact at these frequencies it's highly desirable. There's always a building/tree/rock/bus or something in the way. I'd love to have 3 chances at a connection!
You are right, there is always something in the way...
73, Lee
IMHO, your AREDN network started with multiple, common, poor choices.
Ian, Ed, and I have been offering (hopefully) better choices.
IMHO:
First, avoid 'mesh' topology. :-|
Avoid channels 149 through 161.
Do not use channels that overlap.
Strive for 100% LQ/NLQ.
Strive for 100% Point-to-Point RF paths.
Avoid wide beamwidth antennas ('Sector') for either end of point-to-point links.
'Sector' (90 to 120 degrees) antennas are for 'campus' coverage. i.e. Downlink distances < ~1 kilometer.
'Panel' (20 to 60 degrees) antennas are for PtP or PtMP (downlink - up to ~10 kilometers).
'Dish' antennas are for PtP (up to 70 kilometers) or PtMP (uplink - up to ~10 kilometers).
I hope this helps,
Chuck
Good advice from all!
73,
Lee
kf7yrs
If any one node sees more than 1 other node, the opportunity for hidden nodes exists.
In #4, your LHG is trying to link with W7MHB.
Your LHG is a hidden node to EOC.
EOC is a hidden node to LHG.
If EOC wants to transmit while LHG is transmitting, it will because it thinks the channel is clear.
If LHG wants to transmit while EOC is transmitting, it will because it thinks the channel is clear.
There will be collisions.
When LHG has sent a data packet to W7MHB, it expects an ACK.
If EOC is transmitting, W7MHB will not transmit and the ACK may be delayed long enough
for LHG to think the data packet was lost and retransmit...maybe causing interference
to the data packet from EOC to W7MHB.
LHG and EOC will continue to transmit anytime W7MHB and K7MSS are not
and their packets may collide at W7MHB.
"sector nodes a way to make sure everybody sees everything"
Only when the 4th node can also see W7MHB, K7MSS, and EOC.
:-|
and the 5th node can see the 4th node and W7MHB, K7MSS, and EOC;
and the 6th node...
73, Chuck
I guess there is always a balance between too little and too many signals. Your local knowledge is paramount.
Someone very active in our local mesh here told me that several shorter hops will always perform better than one long hop. I'd say that the real gem of AREDN will start to happen when you stop treating mesh like a repeater on the hilltop system, and start doing more local short hops in the flatland. It's harder to make lots of smaller hops as you want them hardened, but it will work best when not everyone is pointed at the hilltop with the max power they can muster.
Good luck. As I'm writing this, I'm planning to add mesh to a local prominent coms tower. If that does come about, then I will be having this same conversations with myself and all my local hams who are chomping on the bit to get rf. It's not a repeater system, you need a 2D grid. We can't all point at the pretty shiny tower. Step by step ...
Ed