You likely just ran into a link stability increase caused by other factors.

The channel width setting only takes effect upon a combination that includes a save (officially this means save and reboot) not upon an apply.

Also the SSID Changes as well to ensure this can't happen (even if the hardware some how fails and starts leaking the data across as was reported at one time in the Linux Kernel archives)

As usual, thanks!

In some very basic testing, I changed only one side of a link to 10mHz and left the distant side at 20mHz. The link stayed up and the quality went up by 15 to 20%. This would indicate that either tx and rx channel width can be independent or some accommodation is going on.  Any thoughts?

BTW, I just "Apply"ed the change. I did not do a save and reboot.

The science behind decreasing the signal width is one primarily of power density, that is, you are putting out 600mw of power across 20MHz it is 600/20=30mw/MHz density, while 600/6=120mw/MHz density. 

The increased density in theory should do two things 1) Increase the power as seen on the receive side as the power is spread out over less space its being more focused (similar to a high gain antenna that focuses the energy into a couple of degrees instead of an Omni pattern)  and 2) By decreasing the width of the signal the overall noise should (in theory) get smaller as you do not have to let as much noise into the system to get the whole signal (5MHz of white noise vs 20MHz of white noise.)  Both of these should cause the SNR to increase over the entire chain. 

Now the trick for this is ALL nodes have to run the same channel width, a 5MHz node can not talk to a 20MHz node,  as they are not receiving the signals the same way.  You can use DTDLink to jump between networks links that are different widths (one node runs one way another runs the other) but no single node can run on both at once.

We are establishing a net in fairly dense suburban area. The terrain has several shallow valleys and ridges (old creek routes) and a large number of trees. Average distance between nodes is between 1 and 4km. We are operating on Channel 1 with a 20mHz channel width.  We have been trying a variety of radios and antennas and seem to have reached a point that we cannot improve beyond in the current configuration.

I have been thinking about two areas where we might get improvement and would like to know if others in our situation have tried these changes, and what the results were.

#1. Switch to a smaller channel width? A little testing here seems to suggest lowering channel width does improve LQ (with a commensurate loss of throughput). Is there any "science" to this? Are there issues in asymmetric operation in which two sides to a link operate at different channel width settings?

#2. Observations with Wi-Fi scans from various locations indicate channel 6 is less crowded than channel 1. Have any group tried switching to channel 6 in an area like ours? Did the expected improvement actually materialize?

Thanks

Richard - wb6tae

The tunnel add-on would be a help, in that, it will give you experience in deploying and managing your mesh and letting you determine what your mesh can DO, while you are getting the RF links up in the air.

I do not have ANY nodes up yet. There is no activity on Broadband-Hamnet in this area yet. There is a group of us that are working on planning a network up. All the hills and mountains don't help.

73,

KK4TGV

Around -96dbm for Ubiquiti receiver (the other 10dbm gain of the link budget is from the higher transmitter power)

Thanks!

What sort of sensitivity am I looking at in the Ubiquiti devices?

Linksys has to my knowledge never said officially (unlike Ubiquiti which has it in the data sheets) the rough number tends to be around -86dbm however again never officially defined.

If you are plotting new sites very much recommend looking at the Ubiquiti gear instead, you can end up with a ~20dbm link budget increase (depending on local factors) just by switching to a Ubiquiti device, in addition the receivers just seem to perform better overall even in locations where the noise floor negates that sensitivity advantage.

My dad seems to think that it will only do 79mw with the manufacture  installed firmware, but will do more with something like DD-WRT installed. I don't really know. I guess the only sure way is to get the test equipment to test power output.

73,

KK4TGV

Linksys own data sheet says 18dbm EIRP on their website.  I'm more likely to trust the manufacture on this one and believe its 18dbm (79mw)

Hello all,

How much power will the WRT54GL put out on Mesh nodes? I know that we have a WRT54GL with DD-WRT installed and it will do 251mw. However, I keep hearing about 79mw. What is the deal here? Can somebody explain please?

Thanks!

73,KK4TGV

Hi all,

I am wondering, is it possible to receive traffic being sent by mesh nodes on a router without Broadband-Hamnet firmware installed?

Thanks!

73,

KK4TGV

Hi all,

I am wondering what the RX sensitivity is for Linksys routers in μV. I need this for plotting patterns with RM online.

Thanks!

73,

KK4TGV

Thanks Conrad, I suspect you are right. The html on my status page is ~2700 bytes.  That, plus TCP/IP overhead, would, as you note, require two packets. Plus, since it's TCP, each packet must be ACKed.  So, I can see that over a weak radio link one small packet would be more likely to succeed than 1 full and one mostly full packet.

My first out on a limb guess would be page size on a lossy link would have something to do with it (I've see  it once or twice myself)

The first page is a mere 549 bytes.  That's ~1/3 of a max frame size so you don't need as long of a clear opening in RF to get it out (549bytes over 1mlillion bits = very rough time it takes to send the packet in seconds) while the main page is larger (I don't have generated size off hand but I know for sure it is larger) this creates two issues 1) a larger packet is more likely to get interrupted than a short packet 2) There may be more packets to get lost.

I'm going out on a limb here after so much discussion relative to adding a NTP server to the mesh for field operations (http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-4-applications/topic-1151-ntp-server.html) but I've been working on it for a few weeks and have had partial success. By partial, I mean that I've constructed a DNS server that connects to a LAN node and responds only to NTP queries from attached mesh nodes with an advertised NTP server address. The NTP server does not seem to respond (or isn't being queried) afterwards however.

This entire venture has been a learning experience for me as I'm not a certified Microsoft Software Engineer (lol) and have had to read an awful lot of DNS and NTP standards as well as try to understand the typical network process that takes place. The code is written in C++ on an Arduino Uno (with an Ethernet shield) and was responding to the hosting mesh node but the node wasn't reflecting any time change from those responses. The DNS Server is built on a separate Arduino for the time being.

It occurs to me that the reason for problems might be (very well) that I don't have things configured properly on the mesh itself so I've attached a printout showing the DNS response packet and the Arduino sketch code for the NTP server along with the mesh node configuration screens. Hopefully someone here is more familiar with typical network protocol and can point me to the solution. Being so close and yet falling short is driving me crazy!

Attachments
 DNS response packets.png [109 KB] ::
 Screenshot 1.png [17 KB] ::
 Screenshot 2.png [16 KB] ::

When working with nodes with low quality links, I have frequently seen a case where I can connect to a (distant) node in a browser using a URL of the form http://nodename:8080/ (Eg. a link from the mesh status page)

I then receive the default re-direction response from /www/index.html - - so, I know I have an TCP (http) connection to the distant node. But, after that, the redirection target url (the status page) never opens and the connection times out.

Any ideas as to why the connection to the default static landing page succeeds and the connection to /cgi-bin/status does not?

The Yuma Hamfest is this weekend (http://www.yumahamfest.org/) and I'll be giving an updated presentation at 9 AM on Saturday on BBHN and what the Development team has been up to.  

Later the same day... arrangements have been made for a deeper dive session at 3:40 to 4:40 PM.  Bring your questions or issues and we'll work through them together.

Looking forward to seeing you all there.

Andre, K6AH 

Boy, you guys have gotten long-winded ;-)

I see three types of mesh users:

• Those who are toying with it and perhaps build it to do cool things with.  We see a lot of guys building neighborhood networks to do fun things with.  They attract others to the hobby because it affords them the ability to participate.  These are the guys who use primarily Linksys devices because they're cheap and well suited for their purposes.
• Those who weren't looking for it, but have found it and are now applying it to fill a particular need.   These are the Field Day loggers, the Ultra Run support crews, the remote surveillance cameras, the guy who extends Internet-access to his ham shack, etc.
• Those who have longed for this technology... see it as a game-changer in their particular space and are now exploiting it for that purpose.  This includes the Emcomm guys that are purposefully building a mesh infrastructure network with backbone and mid-mile nodes. 

All three are legitimate and justified in the adoption of this technology.  But obviously not all have the same motivation.  So depending on which group you are in, you will have different opinions on what's important, different requests for features, and different support needs.  Most of us in the BBHNDev group are in the third category... including myself.

We can all agree though, that mesh is just a network.  You need to put services on it for it to become fun or useful. And you need to use those services routinely if you expect them to be there when you want or need them.

Enough of this philosophy... now turning control back over to my left brain.

Andre, K6AH