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

Gentlemen,

I see on the home web page that you are aware of the, as you state "Periodic Crashes".  I tell you that Periodic is NOT the case here in Ventura County.  I do not know about the Linksys systems but I can report that any and all of the Ubiquity systems that we have operational here are CRASHING sometimes several times a day.  Going to the mountain top to do a power reset because the node is NOT responding is getting pretty old.

We have been touting the technology and our Government official are asking for demonstrations.  We are reluctant to do this for fear of system crashes and we end up with looking bad.  At this point the system is so unreliable that we can NOT depend upon it for any meaning full communications.

Look, I know you people are all doing this as volunteers and out of the kindness of your hearts and is your way of advancing the technology, I commend you, BRAVO!!!  Right now we are dead as there is no parallel effort that I can see of people developing alternate code, we are depending entirly on your group.

If a FIX in NOT eminent, please give us a heads up as when to expect working firmware.  Please don't say soon, give us a date, two days, 5 days, Sept 15..Something so we are not left hanging here.  I do believe that great things can and will be accomplished with this technology and I will be the first to commend on your concepts and actions.

It was not my intent to make anybody in the design group mad or upset, if I was turse, please excuse me.  I do thank you for your time and listening.  We anxiously look forward to working software.

With great Respect

Paul Strauss

WD6EBY

Camarillo California

I was rummaging around inside a node the other night, and ran across quite a few NTPCLIENT files. I never did find a .conf file. I did find what looked like a perl script (maybe just a shell script) that included a NTPCLIENT call and a ping to the .pool ntp server address. It looked like it was intended to ping out to the world, and if it got a response, it would call the NTPCLIENT program, otherwise it would loop. It wasn't the olsrd.conf fiile, I'm pretty sure of that.  I'm sorry, I can't remember where I found it, but I found it by searching for NTP using WINSCP while connected to the node.

Just shooting in the dark, but perhaps the node won't look for ntp services if it doesn't see a path to a particular address? Perhaps if you could find that routine and plug in your servers' address...

I have to ask; what's the importance of setting the time on the nodes themselves? Aside from displaying on the admin pages, the node time doesn't seem to have any impact on the mesh. If I don't have a gateway up, my nodes usually show random times, and I haven't noticed any negative effects. I have to admit you've piqued my curiosity, but is there a practical consideration?