We are working specifically with Ubiquiti nodes. We have identified several locations to mount them including atop the second largest building in Tucson, AZ.

When the routers are flashed, they default to using channel 1. Why not use channel -1 or channel 0 which takes them out of the shared band space for commercial routers.

Thanks.

Ok this hasn't been discussed in depth lately and new information has come to dev team information since the initial release and its the 2nd time this week this question has come up as well so I'll jump in with another technical analysis

1) Their is no proof that all the supported radios can even go down this far at the moment. 

We have recently discovered on Ubiquiti (actually applies to all Atheros based radios) something called the Calibration Tables that controls the power cal data to be sure the devices stay linear (high linearity is required for WIFI -- same reason you can't really find AMPS that work good in the <$500 price range).

There was a hardware mod for Linksys some time back but it made you 100% incompatible with other mesh users (shifting the device reference frequency down.) No such hardware mod exists for Ubiquiti and it had a lot of negative pitfalls under Linksys as well (timing was corrupted, which btw timing is important for WIFI )

To our knowledge no seller calibrates the radios below channel 1 at the factory at this time.

2) To do this proper would need to be a software only method, the Linux Operating system we use currently does not support the non standard channels. 0 and -1 are not channels in the distribution and will require a re-write of some code, IF the devices are even capable of doing this without hardware mods as this part of the code is linked to the Cal Data, without it this doesn't happen either.

3) Channel 0 and -1 would not actually get you out of the noise of Part 15 wifi.  WIFI is ~20-22mhz wide (g vs b).  Channel spacing on 2.4 is every 5 mhz.   To actually get clear of Channel 1 noise you would need to go as far down as 2392 mhz center (Channel -3)  and then you have the issue that 20mhz wide you spill out of the HAM band on the LOW side so above this is would also need to support smaller channel bandwidths as well to be useable. This calculation also doesn't take in any Guard Band between HAM and Part 15 WIFI either to reduce possible error rates from noise.

4) The main goal of the project currently seems to be getting hardware to work where its suppose to before going out and trying to do things the hardware isn't meant for.  We have added 5.8ghz already by doing this, were looking at the other bands,  were looking at more Ubiquiti hardware, etc  Chanels 0 and -1 are NOT in band and will take a significant dev effort to acomplish (if at all possible)  We welcome other devs who may have the capability (3ghz spectrum analyzer and Linux Kernel programming skill ) to work the issues involved. Its just not something in core we can focus a lot of effort on at the moment.

tag: channel 0

You can always roll your own firmware by starting with OpenWRT and adding in olsrd. Selecting channel 0 appears pretty simple in OpenWRT:

http://kb9mwr.blogspot.com/2012/10/nw-mesh.html

Is that the standard Luci GUI ?

I've tried setting negative channels in 12.09 in core openwrt (but not Luci) are you sure it's actually operating on a negative channel?  Everything I've seen so far says kernel won't permit it, regulatory domain control wouldn't permit it etc.

If so, I'll fire up a stock OpenWRT and investigate to see what I have been missing.

Standard GUI.

You are correct, I did some further tests and it doesn't appear to be actually on the negative channel.

That or there is some sort of incompatibility in the AirOS / Open WRT channels.

What a pain. I just found out the hard way after specifically ordering the world wide Ubiquiti hardware that if you upgrade the AirOS firmware past 5.5.6 you lose the compliance test mode. I'll keep messing around with OpenWRT and let you know if I stumble into anything.

True there isn't a whole lot to gain with 2.4 GHz, but if it can be figured out there are 10 non overlapping channels on 5.5 Ghz that could be used exclusive to hams, not mention whatever applies with 3 GHz devices.

I don't think it's a Ubiquti only item as the items I've seen apply to ALL Atheros radios.

Each Atheros device registers a channel list (in kernel dricers for ath9k. The ath9k module  looks up calibration data (as noted above) that is programmed at the FACTORY only to make sure it stays linear and doesn't fry and components. In addition a calibration routine based on temapture runs periodically (a relative term meaning in the sense of data it's infrequent but from a human time it's very frequent) 

Here is the article I read that got me started on knowing these issues.

https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg06790.html

ath9k/init.c among other various kernel field are relevant as well as changes to the iw program.

We also know the 3.6ghz devices use very heavy frontend filtering(we tried to bring it to 3.4 ham, it failed), the same could be true of the 2.4 and 5gh devices (we don't know for sure on that) as yet another limitation.

Any information you find would always be appreciated as it can only helps us to better understand the situation and the chances of success.  

We know dd-wrt claims to do it (using a closed source driver) but we don't know if they are paying attention to this data or caring about any filtering, etc.

A bit of both actually.

We have the Regulatory Domain controls and we have the offset that is not known to the operating system.

These are the items we are putting into the BBHN system to make it more user friendly for HAM's.

I have been wondering about this: Channel Power vs Frequency for Ubiquiti devices

http://interline.pl/Tests-and-comparisons/Channel-Power-vs-Frequency-Ubiquiti-devices

Also interesting, and a bit over my head presently, but may be of interest to developers: Using WiFi Atheros chips in hamradio bands:

http://yo3iiu.ro/blog/?p=1301

I concur with Joe.  Looks like as we expect that the power is split between the two ports.  On 2.4ghz it shows a roll off one could expect of a 2.4ghz wifi amp that as you get out of band it falls off. It also shows that calibration data likely isn't used on the test out of band as it's allowed to excite higher.

Re: the link on code: yep that is what I thought it would take (it's nice to have the confirmation) the page in question doesn't on first look to have taken into account cal data so without a spectrum analyzer specced to deal with wifi we wouldn't know if it's stable.  I don't have access to one above 1ghz so I'm out on that regard. In the post it looks like what was done was to repurpose an existing RF channel's cal data without any knowledge as to how accurate it is.  This may work in the same room but over 5 miles may fail. Not sure what those graphs were generated from, if it was a proper spec analyzer then it does overall look good but I suspect it was made from a wifi device which means we can't really trust it reliable to show the actual signal quality.

I can't look at the zip though to be sure that is actually what they did from my phone so will have to check later.

Good catch on the link, it never came up when I was looking so is news to me.

Maybe I'm a bit paranoid, but if I am going to put a commit in to the base I have to feel comfortable we are not going to get anyone in trouble or break any hardware.  As noted if someone's got the gear we can test it with and the dev skill to run with it (I got a dozen other tickets open at the moment ) I'm all for it eventually making it into the build.