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

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

We'll be using minimum power needed along with gain antennae. Distances will be as much as 21 miles with no obstructions and minimal disturbance within the fresnel zone. Is there any risk of interference to home/business wireless G routers?

Thanks.

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.

Attached is an example of star network we are exploring for San Diego County.  Note the use of sector antennas at the higher-ground nodes and the cross-banding that occurs at each level to off-load data from the RF channel coming from "lower" nodes with data heading toward the "higher" backbone.

Since the higher nodes need to cover wider areas (through the use of sector or vertical antennas) the lower nodes always carry the burden of path budget. Therefore lower nodes will generally always use antennas with greater gain.

Note that this network has not yet been constructed, so I offer it up only as an example in support of Conrad's earlier post... Comments are welcomed.

Andre, K6AH

Attachments
 Node Drawings.jpg [75 KB] ::

Can someone provide an example of how to configure settings for Port Forwarding,DHCP and Services for FTP or IRC using a Linksys Router running the latest firmware 1.1.2?

Thanks.

Ted, WB2LOU

A lot of this will need to come from your own deployment needs to some degree, however in the WISP (Wireless Internet Service Provider) world  Sectors always win out over OMNI's

1) With an omni the central hub can hear 360 but the edge nodes can not hear every other edge node.

What happens is you end up with CSMA Hidden Transmitter Syndrom where node B is your center, and node A cant hear C    A and C both transmit garbeling the packet when it gets to node B (same as in 2m packet hidden transmitter problem)

This can repeat many times depending on how big the sending packets are and the backoff time calculated.

With sectors (especially if each one is on a different set of frequencies) you can actually avoid this by one sector hears Station A and the other can only hear Station C   both transmissions can come in.

2) As you noted noise floor will likely be higher on an omni, even if it is not however, noise floor only tells you part of the equation,   If a wifi device on ANY angle of the omni (say 180 degrees away from the node like in the example above)  its transmissions while not intended for the mesh can garble a weaker node coming from another direction.

Sectors help reduce all this as you only have to deal with 60-120degres (1/6-1/3 the potential) (average depending on sector beamwidth) of the interfering stations on any node

If you do go omni make sure to look for a Horizontal or better yet a Dual Polarity Omni, they are more expensive than a vertically polarized omni but you can gain 30db of noise reduction by being in the Horizontal channel.  Just be preapred you may need to replace it in the future if you have a lot of noise around or start adding more users. 

3) Sectors often have more gain compared to an omni, this can be a good and a bad thing , its good in that stations further away can get in and bad in that it means noise can also get in easier too. The gain should generally be worth having though as a few DB may be the difference between a 1.2 and a 2.0 LQ.

Personally when I look at BBHN (due to my terrain here in California  unlike in Austin where it was first created) I don't look at it so much creating a mesh topology (everyone talking to everyone direct)  I see it  creating a star network with possible redundant paths and the mesh protocol is used to share information about who is around removing the need for a central person to manage everything. So even in a star network it still makes life easier, and if people get enough nodes out  you could connect multiple stars on 2.4 and with considering a 5.8 backbone giving you multiple access routes....

I've been starting with NanoStations for my first few field sites (with a Rocket and  Sector on my first hill)      With 2 NanoStations at each end user I can reach the main node, and can design so that we feed to another user  or  double cover an area for redundancy.   Eventualy with enough nodes  even though I only have 60 degree on each NSM2 of beamwidth I hope we will see multiplerouting paths occur.

I see us trying in our area to make the network take shape as 2.4ghz access layer (few miles or so depending upon coverage), a 5.8 ghz backbone (link the access layer sites together)  on a major hilltop.  so  LARGE HILL--5.8--- small hill --2.4 -- user ---other users meshing 2.4 ---- maybe when the network gets big enough 2.4 merges and if we loose a 5.8  we have a 2nd path --

End of the day ANY NODE is often better than NO NODE  so while an omni may not be 'ideal' for peak performance  its sure better than not having any network at all.

Hey OM Rick;

If you purchased the v1.0 units from the nm-mesh group in the vendor's room, that was from me !

Um, the cameras we were streaming were of two different types, neither of which was a "swann" (? - I am not sure just exactly what a swann camera is off-hand. Guess I should look that up !).

Anyways, for one of the two cameras we used a simple USB camera that was plugged into a throw-down router that was reprogrammed with openwrt to be a server. The application software used was mjpeg-streamer to stream to the ethernet port on the server/router.

The other camera was an IP camera from D-link that while originally meant to be used through d-link's internet web-site for hosting, was able to be configured to stream locally without an external app.

es vy 73 de;

Bob, w9ya

DtDlink is not intended to be run over a wireless backhaul. If packet loss rate exceeds 5% the link will be considered down and be disconnected. DtDlink is only for LOW LOSS DIRECT WIRED connections

"I have also setup PORT Forwarding on Ports:20, 21, 22, 23, 25 ,53, 58, 123, 689, 1978, 2222, 8080 as described in another post."  I'm not sure why you are forwarding these ports on the port forwarding  page, at least 5 of these are ports used by the node and should not be forwarded.

"... is there a way I can force a connection through the dtdlink and not over the RF path."

No, you can not force the connection to always use DtDLINK, the node will choose the link with the LEAST COST (ETX value)

DtDLINK interface have a cost of 0.1 compared to the MINIMUM COST for a wifi link being 1.0. There are still edge scenarios where going over RF will be better than going over dtdlink based on path  but they should be very rare as a single wifi hop costs 10x as much as a DTDLINK if it chooses that  route its because it either has a good enough direct RF shot to it that going direct is better OR the hops on the other side of  the DTDLink are just as bad as the hop it can take direct.

"With the initial setup complete I can direct connect to every node that is directly connected via the Bridge Network over the Ethernet connection.  I can NOT, however connect to another node any other way."

TraceRoute results please.  Also make sure you are running 1.1.2, some bugs existed on NAT mode in 1.1.0/1.1.1

Hello All,

There has been a large interest within our ham community in the MESH project in Ventura County California.  The Ojai Valley area already has an extensive MESH network in operation.  I incorporated a MESH onto my uWave Bridge system via the dtdlink parameters to tie Ojai to the remainder of the County.  This is being done as a way of furthering interest in MESH.  With the initial setup complete I can direct connect to every node that is directly connected via the Bridge Network over the Ethernet connection.  I can NOT, however connect to another node any other way.

Under the Tab MESH STATUS, I can see Current Neighbors both RF and dtdlink connections.  In addition I can under Remote Nodes, I can see many nodes. In either case I cannot connect to these stations.  I understand that the links do not point to an actual address only a descriptor.  So I have the list of RF address that correspond to the listed call signed and still cannot connect to them

Any RF connection is just not happening.  I have tried several setups to no avail;

Setup 1

Basic Setup Tab, LAN parameters:

Lan Mode=Nat

IP Address = 172.27.27.31 (addresses are incremental on each node 32, 33, 34 and so on)

Netmask= 255.255.255.0

DHCP Server= off

Setup 2

Basic Setup Tab, LAN parameters:

Lan Mode=1 host Direct

IP Address = set by 1 host Direct

Netmask= set by 1 host Direct

DHCP Server= off

In both cases I have NOT adjusted the WiFi or WAN parameters.

I have also setup PORT Forwarding on Ports:20, 21, 22, 23, 25 ,53, 58, 123, 689, 1978, 2222, 8080 as described in another post.

I am currently using all Ubiquity equipment.

The Ubiquity backbone is setup in bridge mode.  Nanobridge and Powerbridge.

The Ubiquity PoE switches, I have enables a VLAN2 for all the ports and switches associated with MESH.

The current 2.4GHz access points are Ubiquity Rocket M2 with sector antennas and Ubiquity Picostation 2HP.

One final connection question:

If I have Access points connected via dtdlink, is there a way I can force a connection through the dtdlink and not over the RF path.  Or an EXCLUED RF relay point-to-point table so connections are forced through the dtdlink.

Thank you for your time and hopefully your answers.

Paul

WD6EBY

Attachments
 HelpBlock.jpg [66 KB] ::

I have a version 2 WRT54G and after initially setting the password, I am no longer able to access the setup tab. I know for sure what password I used because I typed it into Notepad before copy/pasting it into the password field. That password does not work and neither does "hsmm". I attempted the 30/30/30 reset with no luck and I attempted to place it in failsafe mode via telnet with no luck.

I wonder if the password that I used (a "correct horse battery staple" format passphrase)  might have exceeded the maximum allowable characters. If that's the case, it could have been truncated or it could have been mangled irretrievably in the hashing process. Any ideas?

The node is ready for use but there is no way for me to change any settings.

Refer to manual "local configuration mode"

Please note, on quick view it looks like this camera is 100% dependent upon having internet access. Without access to the 3rd party swam website the camera does not look like it will function.  This means it will not work over the mesh if no internet is available and may not work over the mesh if it uses HTTPS (encryption). 

Visited Albuquerque during the DUKE CITY Ham Fest and saw a HSMM-MESH setup using the SWANN cameras. Purchased a pair of setup ver 1.0.0 routers

Now back in San Antonio.

I purchased the SWADS-450IPC models at Radio Shack on clearance sale.  To do setup requires a tablet (IPhone or Android) with a SWANN app over internal camera Wi-Fi for setup.

Since I would use Cat 5 cable to the Linksis router in normal application, is there a way to setup and use the camera without going through the tablet and Swann App?

Rick

Hello. I've been experimenting with mesh nodes using Ubiquiti hardware and small EnGenius EAG-2408 8dB collinear antennas, mostly with the goal of introducing the idea to my club, the Ski Country ARC. We have several repeater sites that have good line of site but are somewhat far away from anything, but centrally located. My hope is to get enough interest from the club members to start to build a mesh network and have a few "hub" sites for big hops between towns.

We're all fairly spread out from Vail and Aspen to near Grand Junction CO and many points in-between. There's a lot of potential for building out a good network thanks to the "natural towers" all around us, but a lot of wilderness between the high locations and the actual users too, so high gain antennas will be essential if we want to take advantage of these locations. At the same time it would be preferable to keep the high locations as open as possible, and I think that would lead to omni directional antennas, at least until we know if the network will be used or not.

For example, I see a 15dBi omni that seems like it would work OK, but at the same time I'm sure the noise floor would be much higher when compared to using (for example) 3 or 4 16dB sector antennas, which might end up with an unusable node.

What has been the experience with omni antennas over sectored or highly directional antennas? Do you find that the mesh concept falls apart when long distances enter the picture?

After the download to the mesh-node, you also have to have a chat program on the local computer & the computer you will chat with. I use Chatzilla and Firefox browser. The issue with ngircd is that while the chat server is located on the mesh-node, it will not recall the chatroom link. You have to manually enter it in Chatzilla in its setup from find chatroom (localnode:6667/#mesh) in Chatzilla on computer connected to mesh-node with ngircd. On the second mesh-node you will have to find the proper link to the first mesh-node by adding irc://specific-node-name:6667/#mesh into the Chatzilla set up, instead of localnode:6667/#mesh used on the ngircd loaded mesh.