You are here

Mountaintop to Mountaintop backbone frequency

6 posts / 0 new
Last post
KD7VEA
Mountaintop to Mountaintop backbone frequency
so Here in Utah, I am just about setup with 2 mountain top nodes connecting the valley areas below with channel -2 at 10 MHz bandwidth.  we will have close to line of sight between the two nodes, close enough that 2.4 should work, but 5 GHz would be close.  The Mountain top locations are clear of any 2.4 GHz wifi signals, but there are a few 5GHz systems on both hills. I always hear that you run 2.4 into the  road coverage area, and 5GHz backbone to link the Mountain sites.  Why is this, is there an issue with running 2.4  for the whole system.  What I was thinking about was running something like ch 4 20MHz wide on the 2.4GHz band.  this would give us High data rate from site to site, and off of the frequencies that are being transmitted into the valleys below.  what are your thoughts on this?
Jake
KD7VEA
kg9dw
kg9dw's picture
More channels = more better....
There isn't any technical reason why what you proposed won't work. I like using 5GHz for the backbone because I have more available channels for the point to point backbone links. I also have two nodes that are 5GHz for the end points as well, again because of more available channels. I'm planning on leaving 2.4GHz for that last mile situation where 5 won't work (like where I need a small amount of obstacle penetration). 

The other thing to keep in mind is you may want some space between channels at sites where you are running multiple radios. If at a single mountaintop you have one radio pointing east and one pointing west, you won't want to put one on -2 and one on -1. It might work, but I'd prefer to have some space between the two. 
K6AH
K6AH's picture
I use 2 "guard" channels

My experience suggests that collocated nodes need at least 2 "guard" channels between the RF spectrum they consume.  So if one is on say, 5.8 GHz channel 168 and it's 10 MHz wide, then the closest adjacent channel I would use would be channel 172 (since each channel is 5 MHz in width).

To summarize:

5 MHz, add 3 to the select the next adjacent channel number
10 MHz, add 4 to the select the next adjacent channel number
20 MHz, add 6 to the select the next adjacent channel number

Some will undoubtedly say this is too conservative, and reduce these numbers to only one guard channel.  Your experience will ultimately be the judge.

Andre

Revision: It would be interesting and valuable to get empirical data on throughput vs. channel adjacency.  It might be tough to do on 2.4 GHz, but 3.4 or 5.9 (166 and above) would be ideal places to run these tests.  I suppose concurrent iperf tests on adjacent channels... repeating the same test after shrinking the guard channel  from 2 to 1, to none.   Who has testable links and wants to play?  
 

N8NQH
N8NQH's picture
5.8 still utilized

in my local area, the move to 2.4 channel -2 was a tremendous help.  Solving sooo many issues we had that  we thought that we  wouldn't need 5.8 anymore, as our initial foray into 5.8  was solely to escape consumer wifi interference on the 2.4 band (which no longer was a concern with channel -2 operation).  But then realized the channel minus two on  2.4  was being utilized at 10mhz (reduced) bandwidth... and its impact on high volume links.

So now we have a renewed interest in 5.8; no longer sought after to escape interference on the 2.4 band.... but due the 20mhz bandwidth of 5.8 -  it  helps with throughput .  For longer distance hops (community - to - community) we are still using 5.8 directional;  with 2.4 omni for neighborhood coverage.



My four node 5.8 "array" has each of the 4 Nanostations on a different channel.  When approaching Ubiquiti on this setup, they warned me to place the nodes on different channels... and that the spacing between channels be at least 25mhz.  And, they also suggested vertical spacing between the nodes.  Instead of the vertical spacing, I utilized rf shields on the back of  each unit.

this worked out very well.  Right now, the nodes connecting to this array are narrow beam AirGrids.  Aiming was easy... as only the one end  (AirGrid end) required precise pointing.

If I were to do this again, I'd use Rockets and  90 degree width panel antennas.

K5DLQ
K5DLQ's picture
why not Rockets with 120
why not Rockets with 120 degree sectors?  that way you only need 3 devices (3 channels) for 360 degree coverage.
 
N8NQH
N8NQH's picture
Rockets would work; but

Rockets would be better; but back then it was a couple of things:

* no one in our area had any hands-on experience with the Rocket
* uncertainty that this "array" idea would  work at all.
* the co$t incurred if this experiment failed

I didn't want to throw a lot of money into it.   I already had two 5.8 Nanostations, and bought two more (used). This fit well within the "experimental" budget.  and if it didn't work out... I wasn't out much.  I also have a 5.8 AirGrid on rotator; was ready to use that on the backside if needed.

If I were to set up another 5.8  "array"... I would consider using four 120 degree Rockets, allowing some coverage overlap.  But, I still shake my head  in disbelief sometimes, about how well the NanoStations worked in this specific.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer