newUI-64

README.md

@@ -1,15 +1,15 @@
-# AREDN Documentation
+# AREDN® Documentation
-This repository is for creating documentation for the AREDN project so it can be made available on ReadTheDocs.
+This repository is for creating documentation for the AREDN® project so it can be made available on ReadTheDocs.
 
 ## Viewing the Docs:
-To view the AREDN documentation in a web browser, navigate to [https://arednmesh.readthedocs.io/en/latest/](https://arednmesh.readthedocs.io/en/latest/) or select your choice from the `Docs` dropdown menu on [https://www.arednmesh.org](https://www.arednmesh.org).
+To view the AREDN® documentation in a web browser, navigate to [https://arednmesh.readthedocs.io/en/latest/](https://arednmesh.readthedocs.io/en/latest/) or select your choice from the `Docs` dropdown menu on [https://www.arednmesh.org](https://www.arednmesh.org).
 
 ## Exporting to PDF:
-While viewing the AREDN documentation in your web browser, you will see the contents list in the left panel. At the bottom of the panel is a drawer labeled "ReadTheDocs" showing the version you are viewing. Click the label bar to open it. From the drawer you can export the documentation set as a single PDF or Epub file. This is handy if you want to take a PDF copy of the guidebook with you into the field where you do not have Internet access.
+While viewing the AREDN® documentation in your web browser, you will see the contents list in the left panel. At the bottom of the panel is a drawer labeled "ReadTheDocs" showing the version you are viewing. Click the label bar to open it. From the drawer you can export the documentation set as a single PDF or Epub file. This is handy if you want to take a PDF copy of the guidebook with you into the field where you do not have Internet access.
 
 ## Contributing:
-If you are interested in contributing to the rapidly growing set of AREDN related information, you can easily do so on GitHub. The workflow for contributing documentation is described in detail here: [How to Use GitHub for AREDN](https://github.com/aredn/documentation/blob/master/How%20to%20Use%20GitHub%20for%20AREDN.md).
+If you are interested in contributing to the rapidly growing set of AREDN® related information, you can easily do so on GitHub. The workflow for contributing documentation is described in detail here: [How to Use GitHub for AREDN](https://github.com/aredn/documentation/blob/master/How%20to%20Use%20GitHub%20for%20AREDN.md).
 
-AREDN documentation is written using the [reStructuredText](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html) markup language and your text is saved in "rst" files. Before committing your changes, be sure to test your "rst" files locally using [Sphinx](https://www.sphinx-doc.org/en/master/usage/quickstart.html) to ensure they will render correctly.
+AREDN® documentation is written using the [reStructuredText](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html) markup language and your text is saved in "rst" files. Before committing your changes, be sure to test your "rst" files locally using [Sphinx](https://www.sphinx-doc.org/en/master/usage/quickstart.html) to ensure they will render correctly.
 
-Your local code branch name can be anything that makes sense to you. After you create your Pull Request, the AREDN team will review your request just as it does for code changes. Once your documentation contributions are committed to the AREDN GitHub repository, a webhook automatically updates and builds the latest docs for viewing and exporting on ReadTheDocs.org. All contributions that are included by the AREDN® team in the documentation set will be covered by the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license held by Amateur Radio Emergency Data Network, Inc.
+Your local code branch name can be anything that makes sense to you. After you create your Pull Request, the AREDN® team will review your request just as it does for code changes. Once your documentation contributions are committed to the AREDN® GitHub repository, a webhook automatically updates and builds the latest docs for viewing and exporting on ReadTheDocs.org. All contributions that are included by the AREDN® team in the documentation set will be covered by the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license held by Amateur Radio Emergency Data Network, Inc.

appendix/more_info.rst

@@ -4,8 +4,8 @@ Additional Information
 
 Additional information about the AREDN® project can be found at the links below.
 
-- `AREDN homepage <https://www.arednmesh.org/>`_
+- `AREDN® homepage <https://www.arednmesh.org/>`_
-- `AREDN forums <https://www.arednmesh.org/forum>`_
+- `AREDN® forums <https://www.arednmesh.org/forum>`_
 
 
 Contributing AREDN® Documentation
@@ -21,7 +21,7 @@ If you are interested in contributing to the rapidly growing set of AREDN® docu
 6. Go to your local computer and clone your fork of the AREDN® documentation: ``git clone https://github.com/YOUR-GITHUB-ID/documentation``
 7. Navigate on your local computer to the folder where your cloned copy of the repository is located: ``cd documentation``  This directory contains your local copy of the AREDN® documentation, and all of your document editing should be done while you are in this directory or its subdirectories.
 
-The workflow for contributing documentation is described in the file titled `How to Use GitHub for AREDN <https://github.com/aredn/documentation/blob/master/How%20to%20Use%20GitHub%20for%20AREDN.md>`_, a copy of which you will have in your new local repository. Refer to that document for additional information about contributing AREDN® documentation.
+The workflow for contributing documentation is described in the file titled `How to Use GitHub for AREDN® <https://github.com/aredn/documentation/blob/master/How%20to%20Use%20GitHub%20for%20AREDN.md>`_, a copy of which you will have in your new local repository. Refer to that document for additional information about contributing AREDN® documentation.
 
 Your local editing branch name can be anything that makes sense to you as you add topics to the documentation. AREDN® documentation is written using the `reStructuredText <https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html>`_ markup language and your text is saved in "rst" files. Before committing your changes, be sure to test your rst files locally using `Sphinx <https://www.sphinx-doc.org/en/master/usage/quickstart.html>`_ to ensure they will render correctly.
 

arednGettingStarted/downloading_firmware.rst

@@ -12,7 +12,7 @@ Types of Firmware
 Choosing Firmware to Download
 -----------------------------
 
-The first step is to choose the AREDN® firmware image for your specific hardware. You can find the available firmware images for your device by using the `AREDN Firmware Selector (AFS) <http://downloads.arednmesh.org/afs/www/>`_.
+The first step is to choose the AREDN® firmware image for your specific hardware. You can find the available firmware images for your device by using the `AREDN® Firmware Selector (AFS) <http://downloads.arednmesh.org/afs/www/>`_.
 
 .. image:: _images/afs-1.png
    :alt: AREDN Firmware Selector

arednGettingStarted/installing_firmware.rst

@@ -72,7 +72,7 @@ Download the *Install Checklist* for Ubiquiti 802.11n devices. These devices hav
 
 Different TFTP client programs may have different command line options or flags that must be used, so be sure to study the command syntax for your TFTP client software. The example shown below may not include the specific options required by your client program.
 
-Download the appropriate *factory* file for your device by following the instructions in the **Downloading AREDN Firmware** section of this documentation.
+Download the appropriate *factory* file for your device by following the instructions in the **Downloading AREDN® Firmware** section of this documentation.
 
 1. Set your computer’s Ethernet network adapter to a static IP address that is a member of the correct subnet for your device. Check the documentation for your specific hardware to determine the correct network number. As in the example below, most Ubiquiti devices have a default IP address of 192.168.1.20, so you can give your computer a static IP on the 192.168.1.x network with a netmask of 255.255.255.0. For example, set your Ethernet adapter to a static IP address of 192.168.1.10. You can choose any number for the fourth octet, as long as it is not the same as the IP address of the node. Of course you must also avoid using 192.168.1.0 and 192.168.1.255, which are reserved addresses that identify the network itself and the broadcast address for that network. Other devices may have different default IP addresses or subnets, so select a static IP for your computer which puts it on the same subnet but does not conflict with the default IP of the device.
 

arednGettingStarted/node_admin.rst

@@ -322,7 +322,7 @@ Message Updates
 Local Message URL
   This field allows you to enter the URL for a local message source. If you configure a local message server, then your nodes without Internet access can also receive alert messages pertinent to your local mesh. Enter the URL without a trailing backslash.
 
-  A local message server can be configured on a mesh-connected web server which allows nodes to query the URL you entered. There is also a separate package called *AREDN Alert Message Manager* which allows the local message repository to be hosted on the node itself, rather than requiring a separate LAN-conneted web server. You can find out more about this application by reading *AREDN Alert Message Manager* in the **Applications and Services Guide** under the *Other Services* section.
+  A local message server can be configured on a mesh-connected web server which allows nodes to query the URL you entered. There is also a separate package called *AREDN® Alert Message Manager* which allows the local message repository to be hosted on the node itself, rather than requiring a separate LAN-conneted web server. You can find out more about this application by reading *AREDN® Alert Message Manager* in the **Applications and Services Guide** under the *Other Services* section.
 
 Message Groups
   In addition to local messages addressed by node name, it is possible to subscribe to group messages. Multiple group names can be added to this field as a comma delimited list. Group messages are retrieved from the web server specified in the *Local Message URL* field. The following are example grouping ideas:

arednHow-toGuides/beginner-guide.rst

@@ -7,7 +7,7 @@ Beginner's Guide
 What it’s all about
 -------------------
 
-By loading the AREDN® firmware in a outdoor wireless access point, you can join a ham radio network. It’s like the Internet but runs on ham radio frequencies, mostly in the 2.4, 3.4, and 5.8 GHz bands. By joining this network you can find and use all sorts of applications (known as “services”). Anything running on a server, like weather stations, web sites showing site conditions, and email servers can be provided as a service. There are also services that don’t rely on a browser: video streams, chat servers, and VOIP PBXes. The network can also be used to connect Winlink stations, Dstar and DMR repeaters, and Allstar devices. Pretty much any kind of service you can put on the Internet you can put on the AREDN network, subject to the restrictions of the ham radio regulations (FCC “Part 97”).
+By loading the AREDN® firmware in a outdoor wireless access point, you can join a ham radio network. It’s like the Internet but runs on ham radio frequencies, mostly in the 2.4, 3.4, and 5.8 GHz bands. By joining this network you can find and use all sorts of applications (known as “services”). Anything running on a server, like weather stations, web sites showing site conditions, and email servers can be provided as a service. There are also services that don’t rely on a browser: video streams, chat servers, and VOIP PBXes. The network can also be used to connect Winlink stations, Dstar and DMR repeaters, and Allstar devices. Pretty much any kind of service you can put on the Internet you can put on the AREDN® network, subject to the restrictions of the ham radio regulations (FCC “Part 97”).
 
 RF access to the network
 ------------------------
@@ -106,7 +106,7 @@ GL-iNet
 Configuring your node
 ---------------------
 
-After you have your equipment in hand, you need to install the AREDN® firmware, configure its settings, and put it up in the air. Installation and configuration of the firmware is covered in the **Installing AREDN Firmware** and **Basic Radio Setup** sections of the *Getting Started Guide*.
+After you have your equipment in hand, you need to install the AREDN® firmware, configure its settings, and put it up in the air. Installation and configuration of the firmware is covered in the **Installing AREDN® Firmware** and **Basic Radio Setup** sections of the *Getting Started Guide*.
 
 Aiming High Gain Antennas
 -------------------------

arednHow-toGuides/dish-aiming.rst

@@ -11,23 +11,15 @@ Practice with Nearby Nodes
 
 If you can drive to within 1/4 mile of an active node, you should be able to pass signals well. At close range the aiming may not be as critical and you could even place a NanoStation or SXTsq panel on your dashboard. Find a public park, open parking lot, or street parking where you have line of sight to a remote node that uses the same frequency as your portable node. Here are some steps you can follow to practice aiming your node.
 
-* In your vehicle, power up your node and plug in your laptop. Disable the wifi interface so the laptop gets its IP address from the node. Open a web browser and use *localnode.local.mesh:8080* to load your node's home page. You will need to have your user name (root) and password to authenticate to the *Setup* display.
+- In your vehicle, power up your node and plug in your laptop. Disable the wifi interface so the laptop gets its IP address from the node. Open a web browser and use ``http://localnode.local.mesh`` to load your node's home page. You will need to have your admin password to authenticate to *admin* mode.
 
-* Enter the SSID, Channel, and Channel Width that matches the remote node you are surveying. Regarding the "Distance to Farthest Neighbor" setting, refer to the node help page or the *Configuration Deep Dive > Mesh Column > Distance Setting* section in the **Getting Started Guide** for information. On short paths the zero-distance (automatic setting) may not work well, so you should adjust the slider to a setting close to the estimated distance between your nodes. If you changed any of these settings, click ``Save Changes`` followed by ``Reboot``.
+- On the **Radio** page enter the SSID, channel, and channel width that matches the remote node you are surveying. If you changed any of these settings, click ``Done`` and ``Commit`` your changes.
 
-* Now you can do a ``WiFi Scan`` from your node's home page. Put the scan on ``Auto`` refresh and the screen will refresh the scan every ten seconds. The scan list will show remote nodes along with their signal strength, channel number, and SSID. If you have chosen the correct SSID and channel, you should see a connected status if the signal is -87 or stronger. If the channel or SSID doesn't match, you will see a "foreign network" status. There may be other devices on different channels at a particular location. Pick the strongest one and use that channel.
+- Now you can click the *Tools* icon to select **WiFi Signal** from the menu. Choose your remote node by clicking in the field at the right and selecting the desired remote node from the dropdown list. The signal level will be updated on the graph, and you can also enable an audio tone to give you an audible indication of the signal level. Turn your radio slowly or even change the car position to find the position at which the signal level is best.
 
-* Once you have a connection with the remote node, quit the WiFi scan and click the ``Charts`` button. You will see a moving graph for the average of all connected stations. In the dropdown menu, choose the remote node you are connected to. Click the *Sound:* ``On`` button, and the pitch of the tone you hear will get higher with greater Signal-to-Noise Ratio (SNR). You may want to adjust the level of the starting tone as well as the tone volume using the sliders below the sound button. You will see the SNR updated every second above the sound button.
+- Once you have the highest SNR at your test location, click ``Done`` to return to the **node status** display. You should see the remote node in the list of *Neighborhood Nodes* in the center column. There will also be values displayed for the link quality. Hover over the row for the remote node and click to show the **Neighborhood Device** display. This will provide a wealth of information about the quality of the link to the remote node being tested.
 
-* To get the highest tone pitch and the best SNR, turn your radio slowly or even change the car position by driving forward or back a few feet. If the tone stays at one frequency and the chart is no longer changing, you may have lost the signal. Quit the chart and start again.
+- If desired you can click the neighbor node name to show the remote node's view of your connection by following the same procedure as above.
-
-* Once you have the highest SNR at your test location, quit the chart and click the ``Mesh Status`` button. You should see the remote node in the list of *Current Neighbors* on the right. There will also be percent values for LQ based on the signal your node hears, as well as NLQ based on the signal the remote node hears. Right-click the neighbor node link and open it in a new tab on your browser. In the new tab you can see the remote node's view of your connection.
-
-* On the remote node's home page, click the ``Chart`` button and follow the same procedure as in the step above. This time choose your own node from the dropdown menu, since that remote node may be connected to other stations too. You can turn on the audio tone if you want to hear the relative strength of your node's signal from the perspective of the remote node.
-
-* Now you can turn your node's antenna a little at a time in order to get the highest possible SNR that's being received by the remote node. You will probably notice less variation in the chart with small movements making it easier to adjust for strongest SNR.
-
-* Quit the chart once you have the best signal level. If you hover your mouse over the chart you can also view the individual data points that show the specific transmit and receive signal levels (dBm). Check both your *Mesh Status* page and the neighbor's *Mesh Status* page for the LQ and NLQ values. Try to achieve 100/100 percent on each side.
 
 Aligning Distant Nodes
 ----------------------
@@ -44,9 +36,7 @@ For example, Mikrotik LHG5 and Ubiquiti RocketDish5 antennas are very narrow, wi
 
 While it is helpful to know the antenna pattern for the nodes at both ends, the key is knowing the exact coordinates of the two locations so you can determine their topographical relationship to each other (horizontal and vertical azimuth). There are several computer tools for modeling radio links that were mentioned in the **Network Design Guide** under the *Network Modeling* section. One of the most useful is `VE2DBE's Radio Mobile <http://www.ve2dbe.com/rmonline.html>`_ which provides all of the required details for aiming directional antennas between two locations, including both true and magnetic bearings for both sides of the link.
 
-Another invaluable tool mentioned in the **Applications and Services Guide** under *Other Services* is KG6WXC's MeshMap Network Visualizer. This program automatically discovers live nodes on a mesh network and periodically polls them to display their location, configuration, services, and link information. It also has a ruler tool that displays the distance and true bearing (not magnetic) between any two points you select on the map.
+Studying various local maps may allow you to discover other sites where you could place intermediate nodes that might link two distant locations. Google Earth can help you identify visible landmarks before aiming. Obvious tall objects such as water towers or multi-story buildings can be added as markers. Nearby objects such as church steeples or park features can be useful as visual reference points during the aiming procedure: for example, "I need to aim over the skate park to the left of the church to hit the remote node." Google Earth also provides a ruler tool which shows the bearing between map locations, and you can look at the Profile View to see whether there are features which may block your signal. Another tool mentioned in the **Network Design Guide** under the *Network Modeling* section is `Radio Fresnel <http://www.radiofresnel.com>`_ which generates a Google Earth KMZ file that identifies ground features which may block the Fresnel Zone along your link path.
-
-Studying the types of maps mentioned above may allow you to discover other sites where you could place intermediate nodes that might link two distant locations. Google Earth can help you identify visible landmarks before aiming. Obvious tall objects such as water towers or multi-story buildings can be added as markers. Nearby objects such as church steeples or park features can be useful as visual reference points during the aiming procedure: for example, "I need to aim over the skate park to the left of the church to hit the remote node." Google Earth also provides a ruler tool which shows the bearing between map locations, and you can look at the Profile View to see whether there are features which may block your signal. Another tool mentioned in the **Network Design Guide** under the *Network Modeling* section is `Radio Fresnel <http://www.radiofresnel.com>`_ which generates a Google Earth KMZ file that identifies ground features which may block the Fresnel Zone along your link path.
 
 .. image:: _images/link-azimuth.png
    :alt:  Antenna Aiming Details
@@ -56,4 +46,4 @@ Studying the types of maps mentioned above may allow you to discover other sites
 
 The chart above shows typical link details that are provided by `Radio Mobile <http://www.ve2dbe.com/rmonline.html>`_. It is very helpful to know these kinds of details and to have an accurate compass before you begin the antenna aiming process. If you use magnetic bearings you will need to know the declination for your location, and be sure your phone or compass is not influenced by nearby metal objects.
 
-Some antennas are easier to aim than others. Large metal dishes are heavy and may require two people to aim, whereas lighter dishes like the Mikrotik LHG units are easier to manipulate. Often only a slight change in position can make a large difference in SNR and link quality. Be sure to avoid trees and be sure your link's first Fresnel Zone is clear of obstructions in order to achieve the best link quality. See the **Network Design Guide** on *Radio Spectrum Characteristics* for examples of ground clearance at different frequencies to ensure the Fresnel Zone is clear.
+Some antennas are easier to aim than others. Large metal dishes are heavy and may require two people to aim, whereas lighter dishes like the Mikrotik LHG units are easy to manipulate. Often only a slight change in position can make a large difference in SNR and link quality. Be sure to avoid trees and be sure your link's first Fresnel Zone is clear of obstructions in order to achieve the best link quality. See the **Network Design Guide** on *Radio Spectrum Characteristics* for examples of ground clearance at different frequencies to ensure the Fresnel Zone is clear.

arednHow-toGuides/firmware_tips.rst

@@ -2,10 +2,10 @@
 Tips for Uploading Firmware
 ===========================
 
-Uploading firmware to an AREDN® node is usually a straightforward process. Follow the procedures documented in the **Downloading AREDN Firmware** section to ensure you have the correct firmware version from the AREDN® website to install on your node. If you experience issues uploading firmware, the following tips may be helpful.
+Uploading firmware to an AREDN® node is usually a straightforward process. Follow the procedures documented in the **Downloading AREDN® Firmware** section to ensure you have the correct firmware version from the AREDN® website to install on your node. If you experience issues uploading firmware, the following tips may be helpful.
 
 Error message when uploading firmware
-  If you see an error message displayed when uploading new firmware to your node, verify that you are loading the correct file by referring to the `AREDN Firmware Selector (AFS) <http://downloads.arednmesh.org/afs/www/>`_, then you can safely ignore the warning. The file naming standard recently changed from a non-standard naming convention to the standard naming convention used by OpenWRT.
+  If you see an error message displayed when uploading new firmware to your node, verify that you are loading the correct file by referring to the `AREDN® Firmware Selector (AFS) <http://downloads.arednmesh.org/afs/www/>`_, then you can safely ignore the warning. The file naming standard recently changed from a non-standard naming convention to the standard naming convention used by OpenWRT.
 
 Web browser cache and sessions
   One common issue can occur when installing firmware using a web browser. Your computer's browser cache stores data for the URLs that have been visited, but IP addresses and other parameters may change during the install process. It is possible for the cache to contain information that doesn’t match the latest settings for the URL, so the browser may block the connection setup and display an ERR_CONNECTION_RESET message. Clearing your computer's web browser cache will allow the latest URL settings to be registered so you can continue with the install process.
@@ -28,9 +28,9 @@ PXE Server
 Tips for Upgrading Firmware
 ---------------------------
 
-Upgrading an AREDN® node is accomplished using the *Setup > Administration > Firmware Update* feature on the node's web interface. Follow the procedures documented in the **Downloading AREDN Firmware** section to ensure you have the correct firmware version from the AREDN® website to install on your node.
+Upgrading an AREDN® node is accomplished on the *Firmware* page. Follow the procedures documented in the **Downloading AREDN® Firmware** section to ensure you have the correct firmware version from the AREDN® website to install on your node.
 
-.. note:: Currently there are a few Mikrotik devices which require that the standard firmware compatibility checks be disabled in order to upgrade from version 3.22.12.0 or older to a newer firmware version. This is a "one time" issue which will migrate these devices from the legacy *ar71xx* firmware architecture to the current *ath79* architecture. The specific devices are shown in the **Supported Devices** list on the AREDN® website (see footnote 1). You must first install the `Dangerous Upgrade package <https://github.com/kn6plv/DangerousUpgrade/>`_ (the **ipk** file) which will disable the firmware compatibility checks. After this package is installed on your node you can perform a normal firmware upgrade (for example) from 3.22.12.0 to 3.24.4.0.
+.. note:: Currently there are a few Mikrotik devices which require that the standard firmware compatibility checks be disabled in order to upgrade from version 3.22.12.0 or older to a newer firmware version. This is a "one time" issue which will migrate these devices from the legacy *ar71xx* firmware architecture to the current *ath79* architecture. The specific devices are shown in the **Supported Devices** list on the AREDN® website (see footnote 1). You must first install the `Dangerous Upgrade package <https://github.com/kn6plv/DangerousUpgrade/>`_ (the **ipk** file) which will disable the firmware compatibility checks. After this package is installed on your node you can perform a normal firmware upgrade (for example) from 3.22.12.0 to 3.24.x.x and above.
 
 In rare cases the upgrade process can fail due to lack of node resources, but such a failure will leave the node running its previous firmware version. The following tips help ensure that memory utilization is at a minimum on the node.
 
@@ -61,16 +61,16 @@ Tips for legacy nodes with low memory (32mb)
 
     To transfer the image from a Windows computer you can use a *Secure Copy* program such as `WinSCP <https://winscp.net>`_. Then use a terminal program such as `PuTTY <https://www.chiark.greenend.org.uk/~sgtatham/putty/>`_ to connect to the node via ssh or telnet in order to run the sysupgrade command shown as the last line above.
 
-  - As a last resort, use the First Install procedure to load the *factory.bin* firmware image to the node. This procedure is described in the *First Install* sections of **Installing AREDN Firmware**.
+  - As a last resort, use the First Install procedure to load the *factory.bin* firmware image to the node. This procedure is described in the *First Install* sections of **Installing AREDN® Firmware**.
 
 Tips for Downgrading Firmware
 -----------------------------
 
 Downgrading AREDN® firmware is typically accomplished using the same procedure as for uploading firmware to your node. You are simply uploading a previous version of the firmware rather than the latest version.
 
-However, there is a difference if you are downgrading the firmware on a node which previously used a different target architecture. As explained in the **Downloading AREDN Firmware** section, the legacy ``ar71xx`` target has been retired and replaced by the ``ath79`` target. For example, you may have a node that was previously running an ``ar71xx`` firmware version but you installed the latest Stable Release or Nightly Build which upgraded it to an ``ath79`` firmware target. In this case you will need to do a fresh First Install using the legacy architecture's firmware.
+However, there is a difference if you are downgrading the firmware on a node which previously used a different target architecture. As explained in the **Downloading AREDN® Firmware** section, the legacy ``ar71xx`` target has been retired and replaced by the ``ath79`` target. For example, you may have a node that was previously running an ``ar71xx`` firmware version but you installed the latest Stable Release or Nightly Build which upgraded it to an ``ath79`` firmware target. In this case you will need to do a fresh First Install using the legacy architecture's firmware.
 
-1. Use the `AREDN Firmware Selector <http://downloads.arednmesh.org/afs/www/>`_ to download the previous release's install files. For example, if your Ubiquiti Rocket M5 XW is currently running version ``3.23.4.0``, then download the files required for a First Install from release ``3.22.12.0`` which used *ar71xx* (as shown below).
+1. Use the `AREDN® Firmware Selector <http://downloads.arednmesh.org/afs/www/>`_ to download the previous release's install files. For example, if your Ubiquiti Rocket M5 XW is currently running version ``3.23.4.0``, then download the files required for a First Install from release ``3.22.12.0`` which used *ar71xx* (as shown below).
 
 .. image:: _images/downgrade.png
    :alt: Downgrading across target architectures
@@ -78,12 +78,12 @@ However, there is a difference if you are downgrading the firmware on a node whi
 
 |
 
-2. Review the **Installing AREDN Firmware** documentation and follow the steps for the *First Install* procedure that is appropriate for your node model.
+2. Review the **Installing AREDN® Firmware** documentation and follow the steps for the *First Install* procedure that is appropriate for your node model.
 
 - For Ubiquiti and TP-LINK models you will be uploading the *FACTORY* firmware.
 - For Mikrotik models you will boot using the *KERNEL* file (which you rename to *rb.elf*) and then immediately apply the *SYSUPGRADE* firmware image.
 - For GL.iNet models you will use the `recovery procedure <https://docs.gl-inet.com/en/3/tutorials/debrick/>`_ to upload the *SYSUPGRADE* firmware image.
 
-Another possible way to downgrade firmware between architectures is to enable **Dangerous Upgrade** under the *Advanced Configuration* settings. Setting this to *ON* will disable the normal firmware compatibility checks that are done automatically during the firmware install process. This should allow your node to install a firmware image that uses a legacy architecture.
+Another possible way to downgrade firmware between architectures is to enable **Dangerous Upgrade** under the *Advanced Options* on the **Firmware** settings page. Setting this to *ON* will disable the normal firmware compatibility checks that are done automatically during the firmware install process. This should allow your node to install a firmware image that uses a legacy architecture.
 
-After downgrading your node's firmware you will then continue the process for entering your callsign and configuring the node's settings, as explained in the **Basic Setup** section.
+After downgrading your node's firmware you will then continue the process for entering your callsign and configuring the node's settings.

arednHow-toGuides/lqm.rst

@@ -9,12 +9,12 @@ AREDN® mesh networks often lack the bandwidth you might expect. Here we look at
 Introduction
 ------------
 
-Low SNR links between nodes break the Linux “auto distance” algorithm resulting in poor bandwidth utilization on node links. This document describes *Link Quality Manager* which can be enabled on nodes to better manage RF links. Typically 3x bandwidth improvements have been observed, but much higher improvements are possible.
+This document describes *Link Quality Manager* which is enabled on nodes to better manage RF links. Typically 3x bandwidth improvements have been observed, but much higher improvements are possible.
 
 Expected link speed vs. actual link speeds
 ------------------------------------------
 
-We’ve all pointed an AREDN® node at another node, found the sweet spot for the best SNR, and then been underwhelmed by how much bandwidth there seems to be. WiFi is famous for over-reporting how much bandwidth is available vs. what you actually get (think 1/6th in many cases), but somehow we all expect a 2 mile link with SNR > 20 to do more than 1 Mbps. Unfortunately actual performance data is difficult to come by, and experiments to see what might improve are difficult to coordinate. Several theories are described below.
+We’ve all pointed an AREDN® node at another node, found the sweet spot for the best SNR, and then been underwhelmed by how little bandwidth seems to be available. WiFi is famous for over-reporting how much bandwidth is available vs. what you actually get (think 1/6th in many cases), but somehow we all expect a 2 mile link with SNR > 20 to do more than 1 Mbps. Unfortunately actual performance data is difficult to come by, and experiments to see what might improve are difficult to coordinate. Several theories are described below.
 
 Performance theories
 --------------------
@@ -38,7 +38,7 @@ Checking the status of various omnidirectional antennas on the SF Bay Area netwo
 CSMA vs. TDMA
 ^^^^^^^^^^^^^
 
-TDMA is more efficient than CSMA and avoids many of its problems. However, Linux currently has no implementation of the protocol; it is restricted to proprietary radios. This means that AREDN® as currently envisaged cannot support TDMA. While TDMA radios can have a place in an AREDN® network, they seem better suited for backbone operation.
+TDMA is more efficient than CSMA and avoids many of its problems. However, Linux currently has no implementation of the protocol; it is restricted to proprietary radios. This means that AREDN® as currently envisaged cannot support TDMA. While TDMA radios may have a place in an AREDN® network, they seem better suited for backbone operation.
 
 That said, racing to embrace TDMA without understanding why the current CSMA network is failing is problematic. If hidden nodes aren’t the issue, and network utilization is too low for bandwidth decimation, how would TDMA fix this? What actually is the problem?
 
@@ -53,14 +53,14 @@ The WiFi standard (IEEE Std 802.11TM-2007, Part 11) briefly discusses “Coverag
 Auto-distance
 ^^^^^^^^^^^^^
 
-AREDN® provides a “Distance to FARTHEST Neighbor” setting which, indirectly, allows the Coverage Class to be set (the Linux kernel calculates the coverage class from the distance setting). An “auto” option is provided and enabled by default. “Auto” uses a “dynamic ack” algorithm in the kernel which automatically adjusts the Coverage Class. The adjustment is based on the timing of packets sent to and acknowledged from other devices. The class will always be large enough to handle the most distant device.
+Legacy AREDN® firmware versions provided a “Distance to FARTHEST Neighbor” setting which, indirectly, allowed the Coverage Class to be set (the Linux kernel calculates the coverage class from the distance setting). An “auto” option was provided and enabled by default. “Auto” uses a “dynamic ack” algorithm in the kernel which automatically adjusts the Coverage Class. The adjustment is based on the timing of packets sent to and acknowledged from other devices. The class will always be large enough to handle the most distant device.
 
-AREDN® is an open, ad hoc, network allowing any node to associate with any other node as long as it uses the same channel and bandwidth. This results in distant nodes with very low SNRs being associated with each other. Unfortunately the dynamic-ack algorithm does not know that these links are essentially unusable, but it still adjusts the Coverage Class to accommodate them. The result is a higher Coverage Class than is required for optimal network operation, resulting in longer delays in packet retransmission. This compounds the already increased retransmissions inherent in longer links and further reduces the throughput.
+AREDN® is an open *ad hoc* network allowing any node to associate with any other node as long as it uses the same channel and bandwidth. This results in distant nodes with very low SNRs being associated with each other. Unfortunately the dynamic-ack algorithm does not know that these links are essentially unusable, but it still adjusts the Coverage Class to accommodate them. The result is a higher Coverage Class than is required for optimal network operation, resulting in longer delays in packet retransmission. This compounds the already increased retransmissions inherent in longer links and further reduces the throughput.
 
 Link Quality Manager (LQM)
 --------------------------
 
-The *Link Quality Manager* can be enabled on any node running 3.22.12.0 or newer firmware. It runs in the background to evaluate RF links and automatically take the following actions:

+*Link Quality Manager* is enabled on any node running firmware 3.22.12.0 or newer. It runs in the background to evaluate links and automatically takes the following actions:

 
 1. Blocks radio links which are also DtD links
 2. Blocks radio links which have too low an SNR
@@ -74,11 +74,17 @@ What does this mean?
 ^^^^^^^^^^^^^^^^^^^^
 
 1. Occasionally nodes are directly connected (DtD) to collocated nodes which are also using the same channel. Although the DtD link should be preferred by OLSRD, LQM ensures that any radio link between DtD nodes is always ignored.
+
 2. LQM ignores links with SNR too low to be useful. The application uses adjustable settings to accomplish this: drop below the minimum SNR and the link is blocked until the SNR is above the activate level. The hysteresis avoids links bouncing in and out of a blocked state. This stops OLSR from using poor links.
+
 3. LQM limits how far a node can be from a neighbor and still have a reliable link, even if there is a high SNR. The more distant a node, the lower the throughput of the link. In addition, the total throughput on a node is affected by the most distant node it communicates with. LQM automatically determines the distance between nodes using the latitude and longitude information available from each node’s sysinfo.json api.
+
 4. Some links can have high SNR, not be far away, but still have terrible performance due to excessive retransmission errors. While some retransmissions are to be expected, if this rate becomes large then performance suffers. LQM blocks links with poor link quality.
+
 5. LQM disables automatic distance detection and takes over the job of managing the Coverage Class. LQM evaluates the non-blocked links and determines whether there is at least one route which uses this link. It then selects the link with the largest distance and uses this to calculate the Coverage Class.
 
+The *Link Quality Manager* refreshes its state every minute and adjusts the blocked nodes and Coverage Class calculations. The *node status* display shows statistics for each link. LQM settings can be adjusted on the **Radios & Antennas** display.
+
 What LQM does not do
 ^^^^^^^^^^^^^^^^^^^^
 
@@ -115,12 +121,18 @@ Link Distance (miles)  SNR    No LQM (Mbps)  With LQM (Mbps)  Notes
 34                            0.7/0.6        0.7/0.7
 =====================  =====  =============  ===============  =============
 
-These results yield the following conclusions. LQM never negatively affects bandwidth, but the positive effect can be very large. The only result where there was no measurable improvement was at a site having a mixture of many long and short distance links. As expected, the very long 34 mile link negatively impacted all other links on that radio. Improvements of 47x was observed in one case (which was verified multiple times) and it occurred in a crowded, noisy environment. More typical improvements were around 3x.
+These results yield the following conclusions:
+
+- LQM never negatively affects bandwidth, but the positive effect can be very large.
+
+- The only result where there was no measurable improvement was at a site having a mixture of many long and short distance links. As expected, the very long 34 mile link negatively impacted all other links on that radio.
+
+- Improvements of 47x were observed in one case (which was verified multiple times) and it occurred in a crowded, noisy environment. More typical improvements were around 3x.
 
 Conclusions
 -----------
 
-Experiments with the *Link Quality Manager* have demonstrated that we can improve the throughput on links by a significant amount without making physical changes to the network. Improvements of 3x bandwidth are common and in many cases much more is observed.
+Experiments with *Link Quality Manager* have demonstrated that we can improve the throughput on links by a significant amount without making physical changes to the network. Improvements of 3x bandwidth are common and in many cases much more is observed.
 
 LQM also blocks paths in the network which are marginal, either due to excessive distance, poor SNR, or high retransmissions. We expect that by blocking poorly performing links the entire network will be more stable and performant.
 

arednHow-toGuides/supernodes.rst

@@ -43,7 +43,7 @@ As more Supernodes are deployed linking more local networks, the overall perform
 Setting up a Supernode
 ----------------------
 
-Typically a Supernode is configured on a dedicated *Mikrotik hAP ac2*. Its sole task is to serve as a node on the Supernode network. The local network is linked to the Supernode using a :abbr:`DtD (Device to Device)` link on one of its LAN ports which is configured for *dtdlink* on the *Advanced Network* display (Port 5 by default).
+Typically a Supernode is configured on a dedicated *Mikrotik hAP ac2*. Its sole task is to serve as a node on the Supernode network. The local network is linked to the Supernode using a :abbr:`DtD (Device to Device)` link on one of its LAN ports which is configured for *dtdlink* on the *Ethernet Ports & Xlinks* display (Port 5 by default).
 
 .. image:: _images/supernode-localDTD.png
    :alt: DtD Link Example
@@ -57,11 +57,11 @@ The following steps are required to configure a Supernode.
 
 #. Configure the Supernode with a nodename prefixed with your callsign followed by a location identifier as well as the word "SUPERNODE." For example you could use ``AB2CD-NYC-SUPERNODE`` or ``AB6CD-LAX-SUPERNODE``
 
-#. Ensure that *Mesh RF* is ``disabled``
+#. Ensure that the *Mesh* radio is ``off``
 
 #. Provide a reserved or static IP address for the device's WAN connection to your Internet routing device.
 
-#. Do not add any other configuration settings at this point or you may encounter problems later in this process. At this point simply *Save Changes* and *Reboot* the device.
+#. Do not add any other configuration settings at this point or you may encounter problems later in this process. At this point you can ``Commit`` your changes and *reboot* the device.
 
 #. Login to the rebooted device via *ssh* or *telnet* to get a command line prompt, and then manually type and execute each of these commands:
 
@@ -93,9 +93,9 @@ If you do not see these lines, please start this process again from the beginnin
 Things to Avoid
   Here are several things **NOT** to do when configuring your Supernode.
 
-  - Your Supernode must **not** use any Cross-links (Xlinks) to other nodes.
+  - Your Supernode must **not** use any cross-links (xlinks) to other nodes.
   - Your Supernode must **not** have tunnel links to any non-Supernode devices.
-  - Your Supernode must **not** have its *Mesh RF* interface ``enabled`.` *Mesh RF* must be ``disabled`` as noted above.
+  - Your Supernode must **not** have its *Mesh* radio interface enabled.
 
 Before proceeding, make sure all the previous steps have been completed successfully. Now you should be able to connect to another Supernode using a tunnel. The easiest way to do this is to ask another Supernode owner for a set of tunnel client credentials. Your node can use either a client or server tunnel link. Supernode owners can be identified from the `Supernode Network Map <https://worldmap.arednmesh.org/>`_
 

arednHow-toGuides/xlinks.rst

@@ -18,19 +18,19 @@ Tunnels and cross-links both connect two nodes together, so they are the same in
 Configure the AREDN® nodes at both ends
 ----------------------------------------------
 
-You can use either a *Mikrotik hAP ac2* or *ac3* as the AREDN® device on each end of the cross-link. Navigate to the **Administration > Advanced Network** page of the node on one side of the link. To add a cross-link click the *plus* icon, enter an unused VLAN number for the link, an IP address for the near-side radio, an IP address for the far-side radio, a weighting factor, and the available port to which the near-side radio is connected on your node. The *Weight* will be used by `OLSR <https://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol>`_ to determine the best route for AREDN® traffic.
+You can use either a *Mikrotik hAP ac2* or *ac3* as the AREDN® device on each end of the xlink. Navigate to the **Ethernet Ports & Xlinks** page of the node on one side of the link. To add an xlink click the *plus* icon, enter an unused VLAN number for the link, an IP address for the near-side radio, an IP address for the far-side radio, a weighting factor, and the available port to which the near-side radio is connected on your node. The *Weight* will be used by `OLSR <https://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol>`_ to determine the best route for AREDN® traffic.
 
 .. image:: ../arednGettingStarted/_images/admin-ports-xlinks.png
-  :alt: Advanced Networking
+  :alt: Ethernet Ports & Xlinks
   :align: center
 
-In this example we chose VLAN ``20`` because it is not in use anywhere else on our network. We assigned an *IP Address* of ``172.16.1.1`` for the this node, and we assigned ``172.16.1.2`` as the *Peer Address* for the node on the other side of the link. The xlink knows nothing about the details or configuration of the PtP radios, or their IP addresses. The *Weight* is set to ``1`` which is the same weight as would be used by a tunnel connection, but this can be increased if you want the cross-link to be chosen at a lower priority for routing traffic on the mesh. *Port* ``3`` was chosen because it is an open port on this device. After entering your values, click *Save Changes* to save the new cross-link information. Now you can cable your near-side PtP device to port 3 on your AREDN® node.
+In this example we chose VLAN ``20`` because it is not in use anywhere else on our network. We assigned an *IP Address* of ``172.16.1.1`` for the this node, and we assigned ``172.16.1.2`` as the *Peer Address* for the node on the other side of the link. The xlink knows nothing about the details or configuration of the PtP radios, or their IP addresses. The *Weight* is set to ``1`` which is the same weight as would be used by a tunnel connection, but this can be increased if you want the cross-link to be chosen at a lower priority for routing traffic on the mesh. *Port* ``3`` was chosen because it is an open port on this device. After entering your values, click ``Done`` and ``Commit`` your changes. Now you can cable your near-side PtP device to port 3 on your AREDN® node.
 
 .. image:: _images/xlink.png
   :alt: Cross-link diagram
   :align: center
 
-Next, open the **Administration > Advanced Network** page on the node for the other side of the PtP link. Set the *IP Address* for this node to ``172.16.1.2`` and the *Peer Address* for the node on the other side of the link to ``172.16.1.1``. The *Weight* is set to ``1`` which is the same weight as would be used by a tunnel connection, but this can be increased if you want the cross-link to be chosen at a lower priority for routing traffic on the mesh. In our example we are setting the *Port* to ``4`` because it is an open port on this device. After entering your values, click *Save Changes* to save the cross-link configuration for this side of the PtP link. Now you can cable your far-side PtP device to port 4 on your AREDN® node.
+Next, open the **Ethernet Ports * Xlinks** page on the node for the other side of the PtP link. Set the *IP Address* for this node to ``172.16.1.2`` and the *Peer Address* for the node on the other side of the link to ``172.16.1.1``. The *Weight* is set to ``1`` which is the same weight as would be used by a tunnel connection, but this can be increased if you want the cross-link to be chosen at a lower priority for routing traffic on the mesh. In our example we are setting the *Port* to ``4`` because it is an open port on this device. After entering your values, click ``Done`` and ``Commit`` your changes for this side of the PtP link. Now you can cable your far-side PtP device to port 4 on your AREDN® node.
 
 Configure the intermediate Point-to-Point link
 ----------------------------------------------

arednServicesGuide/chat_programs.rst

@@ -23,9 +23,9 @@ As originally designed, MeshChat uses the Perl programming language and is able
 
 - `Latest Lua version of Meshchat at the new package maintainer's repository <https://github.com/hickey/meshchat/releases>`_
 
-- `Older Lua version of Meshchat for AREDN ≥3.22.6.0 (no longer maintained) <https://github.com/kn6plv/meshchat>`_
+- `Older Lua version of Meshchat (no longer maintained) <https://github.com/kn6plv/meshchat>`_
 
-- Original Perl version of Meshchat for AREDN ≤3.22.1.0 or for running Meshchat on a Raspbian or Debian computer (no longer maintained) 
+- Original Perl version for running Meshchat on a Raspbian or Debian computer (no longer maintained) 
 
 .. image:: _images/meshchat.png
    :alt: MeshChat Web Interface

arednServicesGuide/other_programs.rst

@@ -30,7 +30,7 @@ You may choose to purchase an inexpensive off-the-shelf NTP appliance such as th
 AREDN® Alert Message Manager
 -----------------------------------
 
-AREDN® Alert Messages were explained in the **Getting Started Guide** under the *Node Status* and *Advanced Configuration* sections. The example given there showed the Alert Message source running on a separate LAN-connected web server. It is also possible to provide Alert Messages using an application created by Gerard Hickey (WT0F) which runs directly on a node having adequate storage. The AREDN® Alert Message Manager *(aamm)* uses the node's web server to provide a web interface for creating, updating, or deleting Alert Messages -- as well as actually hosting the message repository on the node itself, so that no external LAN-connected web server is required.
+AREDN® Alert Message Manager is an application created by Gerard Hickey (WT0F) which runs directly on a node having adequate storage. The *(aamm)* package uses the node's web server to provide a web interface for creating, updating, or deleting Alert Messages -- as well as actually hosting the message repository on the node itself, so that no external LAN-connected web server is required.
 
 .. image:: _images/aamm-display.png
    :alt: AAMM Display
@@ -46,7 +46,7 @@ The two advantages of using this application are 1) having the message managemen
 
 |
 
-The recipient nodes are configured the same way as described in the **Getting Started Guide** under the *Advanced Configuration* section for AREDN® Alert Messages. For additional information about the AREDN® Alert Message Manager, visit this link: `aamm <https://gitlab.com/aredn-apps/aamm>`_. You may also download and install the latest *aamm* package files `here <https://gitlab.com/aredn-apps/aamm/-/packages>`_.
+The recipient nodes are configured as described in the *Internal Services* section of the **Node Admin Guide**. For additional information about AREDN® Alert Message Manager, visit this link: `aamm <https://gitlab.com/aredn-apps/aamm>`_. You may also download and install the latest *aamm* package files `here <https://gitlab.com/aredn-apps/aamm/-/packages>`_.
 
 weeWx Weather Service
 ---------------------