In surveying local 2.4gHz activity I did a WiFi Scan with the radio (Rocket-M2) configured for channel 1. The result shows stations spread across the channels but the majority are on channel 1. Then, I set the Rocket to channel 6, re-booted and did another WiFi Scan. This time there was the same spread, but the majority of stations were now on channel 6. Switching to channel 11 produced similar results.

So, my question... Is there a bias to the way the scan is conducted (iwinfo) that favors the currently selected channel? If so, is there a way to get an unbiased scan?

I can see how that might be interpreted that way. Perhaps we can make it a little more clear in a future build. It is only suppose to be the settings in the "Active Settings" subbox that the apply button applies too.

That makes sense. Perhaps someone with the right knowledge might revise the Setup Help page to clarify which changes can be "applied" and which require a save and reboot. The current wording implies that all changes in the Wi-Fi box can be applied.

Richard - wb6tae

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] ::