Greetings! 

I am a new Ham (general class) and a new mesher with a nanobridge M2 all the way down in Stephenville, TX.  I am curious about the advertised 18 mi range of the M2 and whether the BBHN firmware boosts this range any significant amount for Hams of different licenses. 

According to the google map, the closest (registered) node to me is about 60 mi away outside of weatherford.  Does that map include all mesh nodes or just the mesh nodes that have manually registered their presence on the map?  Am I basically SOL to connect to any broader mesh until I can figure out how to move to civilization?

Thanks!

I'm having trouble with the IRC server on my WRT54G.
I followed the instructions and installed ngircd 20.2 on a WRT54Gv.3 running the 1.1.2 version of the firmware. I got the "Installing ngircd (20.2) ..." message and ngircd 20.2 shows up in black print under Remove Package.
I rebooted the router as a precaution and tried to connect to the IRC server.
This is where I ran into trouble, I'm confused as to how to connect to the server. I've tried irc://w6jwp-104:6667/mesh on my browser (Firefox) when I hit enter a window opens allowing me to select my IRC client (Hirc). Hirc opens but doesn't do anything until I click "connect". The Hirc Status window shows that it's trying to connect but it times out with no connection.
I've tried connecting directly from Hirc using the Lan address but I get "Access denied: Bad password?". I've tried the password that I changed to on the node as well as the old hsmm password with no luck.
I see lot of references to accessing the ngircd.conf but no information on how to get to the file so I have made no changes to it. Any idea what I'm missing?

- Joe W6JWP

I have a IBM computer running Linux, I've installed Asterisk and FreePBX but I can't seem to get the router to show a link for the PBX System.  Do I have to have a raspberryPi to run a VOIP system or do I just have some settings wrong?

Thanks: Zack

Yes. I've done it. Just plug the Asterisk server into the mesh. Assuming you are using X Host Direct, nothing else needs to be done on the Mesh side (except for the possible ticking of Mesh Gateway). Dependent on your PSTN service, you might have to forward ports on your local network to point to the mesh node.

A WAY overpriced one! LOL

I have an Asterisk system that I've been using for years for both home and business.  I have used it over the Internet as well to have (local) access to my phone system while traveling, etc.

I am wanting to perhaps setup some extra lines, and enable our growing mesh here locally to have access through the mesh to mt Asterisk server, and out to the PSTN (and hopefully inbound as well)

Anyone doing this?  Any tips as far as getting the routing to work properly?

Correct, an NSM5.....we recently go permission from the county to put sites on their 10 comm towers to create a mesh.  

There is a small group of us working on the 5GHz band.  The county has an event going early October and we are looking to set something up from the site to the EOC.  Probably going to work the 2.4GHz at the site and use the 5GHz to reach back to the EOC for the event.   Going to try and work a "roving" IP can to test out the local mesh at the site/event.  We are looking to get on the hangar and put a temp antenna up to get some elevation and reach back to the county EOC.

This is an M5 device I assume unlike the M2 of the OP correct ? (I haven't seen XW outside the M5 line if they are I would like to know)

Yes the XW is not yet supported but it is being worked on in BBHN->ticket:43 

5.5.9 and I believe I have the XW versions...which I don't think is supported.  

I was able to flash two AirGrid M5s with no issues.....

What version of AirOS is currently installed?

Well  if they actually did calibrate them out of the USA band and they only made a tagging change between the USA and INTL version to signal the permmited band then that is some good news I didn't know about, and then yes this could open up some more channels.

If you want to test it  OpenWRT describes how to change RF channels, and our code for the UI is in the repo to review.

I will note that the channels in question will NOT be contention free.  ISM is not the same thing as Part 15.   ISM band may stop at 5725 but Part 15 use of 802.11 is permitted below 5725 in the USA (U-NII 2C band) This is also the RADAR band. 

You will need to be careful to check with local government in this band before usage (I'm all for opening it up though if we have people without government using it and hardware supports it) 

Details:

The U-NII-2C band is allocated on a primary basis to the Radiolocation Service for Federal operation. The sub-band at 5.47-5.65 GHz band is allocated on a primary basis to the
Radiolocation Service for non-Federal operation, and on a primary basis to the Maritime Radionavigation
Service for both Federal and non-Federal operations. The 5.47-5.570 GHz band segment is allocated on a primary basis to the Earth Exploration-Satellite (active) and Space Research (active) Services for Federal operation and on the secondary basis for non-Federal operation. The 5.6-5.65 GHz band segment is allocated on a primary basis to the Meteorological Aids Service for both Federal and non-Federal operations. The band segment at 5.65-5.725 GHz is allocated on a secondary basis to the Amateur Radio Service for non-Federal operation.

Again that said though, if the hardware supports it I wouldn't personally mind seeing the channels to be listed,  they just still come with a STRONG warning about checking for local radar facilities, this band is known to be actively used for government radar in this subband.

I don't have time to test lab them myself at this time as I'm working bigger tickets right now your welcome to test away.  Make sure to do long distance tests to be sure they actually work in the field.

Scalability is highly dependent upon your network layout.

How many nodes can see each other? 

How many nodes can see a shared common master point (MPR selection)

How many frequencies are you using? Do any of them overlap?

How controlled is your deployment to avoid hidden transmitter syndrome.

Are you using Omni's or Sectors?

What is the average signal quality for your nodes (RF Level not LQ level)

All of this and more comes into play to determine how well a network will scale and will depend then on number of nodes in each condition so it is not possible to give you a simple "it will scale to this number" you will have to evaluate your deployment and make changes as needed to maintain peak performance.

Wifi Scan would be more useful for Site Surveys if,... (PDF copy available)

1. Add Wifi Scan GUI selection to allow user to control sample rate (e.g., 1-300 seconds since last scan); leave current setting as the default (and/or minimum value on the allowable range).

a. For example, if sample rate is set to 10, then the Wifi scan is re-sampled if it has been 10 (or more) seconds since last update.

b. NOTE: the "or more" reference is only intended to cover for the case where the display refresh (or some other Node activity) caused the actual sample period to exceed the indicated selection.

2. Add Wifi Scan GUI selection for sample duration (e.g., 1-300 seconds); leave current setting as the default.

a. For example, if sample duration is set to 5; then data is collected for 5 seconds before it is displayed.

b. NOTE: If only one-of "sample rate" and "sample duration" selections can be added to code; then sample duration is more important, with sample rate defaulted to best reasonable recovery time between samples.

3. Add Wifi Scan to allow user control for data persistence (e.g., 0-86400 seconds); leave current setting (i.e., which is presumed to be "0", where "0" flushes previous data at each new WiFi scan) as default.

a. For example, if data persistence is set to 60 seconds, then an entry is removed from display if it hasn't been seen for more than 60 seconds.

b. NOTE: of all the features requested, this is perceived to be the most important.

c. NOTE: if memory space is a concern, then maximum value may be reduced; but hopefully no smaller than 4000 seconds.

4. Add Data Age field to Wifi Scan output display.

a. For example, if a particular Ch/SSID/MAC entry was last seen 30 seconds ago, then the Data Age value would be set to 30. Obviously, this particular example would assume that data persistence was set higher than 30 seconds.

5. Allow Wifi Scan data to be sorted by either Sig, Chan, or SSID fields (ascending or descending); leaving current setting set as default (i.e., assumed to be Sig, ascending).

a. For example, if Sort-by selection was set to Chan, ascending; then all Channel-1 data would be presented before Channel-2 data, and so forth.

6. Allow Wifi Scan data to be filtered by user string (for SSID and/or Chan fields).

a. For example, if SSID filter string is "broadband", and Chan filter string is set to "1"; then only Channel-1 data with "broadband" (or some superset of it, case insensitive) in the SSID are captured/displayed.

b. NOTE: This selection may be required to allow larger values of data persistence to be practical.

Thank-you for your consideration.

Wifi Scan would be more useful for Site Surveys if the controls for the following were added to GUI.

1. sample rate (control)
2. sample duration (control)
3. data persistence (control)  <== MOST IMPORTANT/USEFUL
4. data age (output)  <== Third-most useful (supporting data persistence)
5. sort-by (control)
6. filter-by (control)  <== Second-most important/useful

I can send a more detailed document if desired (unable to attach).  I included more details, as a follow-on to this topic (via cut-paste, post-edit).

Thank-you.

de Vern (W6NCT)

Has any data been collected with respect to the scalability of the HamNet Mesh by...

1. number of nodes?
2. bandwidth loading?

I'm sorry if this information is already available somewhere; I did a quick search and didn't see anything.  If it is available, please provide URL.

Thank-you.

de Vern (W6NCT)

I don't believe the response concerning the design frequency range is completely accurate. The spec sheet states the frequency range is 5170 to 5825 Mhz with a footnote that the states 5725 to 5825 Mhz is supported in the United States.  Consequently the frequency limitation exists only in firmware, not in the hardware, as has been confirmed in my conversations with Ubiquity tech support. There is no limitation to the use of 802.11 protocol pursuant to Part 97 rules, except that encryption would not be permitted. 

In my communications with Ubiquity they didn't assert that the devices would not operate across the specified band, but only that as a matter of policy they were not marketing equipment capable of operating outside the ISM band in the U.S. and applied the limitation in firmware.   

If we can modify the firmware to allow operation within the Part 97 band, we would have access to a commercial site so long as we use channels outside the ISM band, i.e, Part 97 spectrum that would allow four 20 Mhz wide channels.  How much better it would be to operate in spectrum without contention from unlicensed ISM band users and still be within the design range of the product,and without the ERP limitations application to the ISM spectrum. 

Does anyone know how to modify the WRT portion of the firmware to allow the extended frequency range?  Of it anyone has a conclusion different than I've expressed, I would appreciate other viewpoints. 

Paul,

I feel your pain.   If you will email your phone number to my callsign at arrl dot net, I'll give you a call tomorrow to discuss the features you require and find a release you can use in the interim.

The root cause of the current problem is not in our code and as a result the solution is more complex than if it were. 

I commit to you we'll find a workaround for you. 

Andre,  K6AH