You are here

Clarity on current flash procedures

7 posts / 0 new
Last post
N7TZK
Clarity on current flash procedures

Our ARES group hasn't purchased any new nodes for sometime, but we are now planning on purchasing some PBE-M5-300 and NS-M5 nodes.  I find it a bit hard to know for sure what the proper procedures are now, so before I risk bricking new nodes, I'd like to verify I understand correctly.

  1. I'm assuming the new nodes will likely come with AirOS newer than v5.5.x.  Is it still necessary to downgrade to v5.5.x?  Specifically for the nodes I mentioned?  In short, are the instructions on the "Installation" page still accurate?
  2. For PBE-M5-300, should I be using the nightly build of AREDN?
  3. For NS-M5, should I use the v3.16.1.1 release version... or the nightly build?  I should note that while we'll do some testing after we flash these, the purpose for this is to support an athletic activity in the back country (no cell coverage) in a couple months and it won't get a lot of use before then.  So reliability is a priority.
  4. For the nightly build, can I install that directly from the AirOS web GUI, or does it need to be done via TFTP?

Thanks

Dave

AE6XE
AE6XE's picture
1) "Is it still necessary to

1) "Is it still necessary to downgrade to v5.5.x?".   To install 3.16.1.1 and before, 'yes'.  For 3.17.1.0RC1 and currently nightly build, "no" (which is the only option for all the XW devices, including PBE-M5-300/400/620.  The NS M5 XW is the exception supported in 3.16.1.1.)
2) PBE-M5-300/400/620 only option is with the current nightly build (I have a PBE-M5-620 on a tower in production using this).
3) "NS-M5, should I use the v3.16.1.1 release version... or the nightly build?"   The current nightly build is as stable as 3.16.1.1 IMO with support for many more devices.   There is one significant exception.  Any device that will not have an RF neighbor, should only use v3.16.1.1.  There continues to be a pesky problem in 3.17.1.0RC1 and nightly builds.  If a device does not have an RF neighbor linked, then it will become sluggish and stop responding in hours to days.  We call this "slugbug".
4) "For the nightly build, can I install that directly from the AirOS web GUI, or does it need to be done via TFTP?".   It depends on the version of AirOS.  Newer versions of AirOS, the UI only accepts signed firmware.  We do not have the keys to sign AREDN firmware.   As such, the most efficient path is to use the 'tftp' process to directly load AREDN. This works on all versions of AirOS released to date.

On a related issue, do consider and expect to receive the XW version of the NS M5.  I suspect everyone is beginning to or will despise this device.  There is a driver bug that LAN devices can only be plugged into the Main/Primary port and the DtDlink/WAN connections must be through the secondary port.     It's always a pain to work around this, which may need 2 cat5 cables and switch ports. I had to work around this issue today configuring equipment for an event next week.   One always scratches their head a bit when it won't dtdlink with another mesh node on the switch. Oh yea, it's the dreaded NS M5 XW!

Joe AE6XE
N7TZK
Many thanks for the detailed
Many thanks for the detailed reply.  In regards to the XW version of NS-M5, I was aware of the issues with requiring DtD via the secondary NIC.  The project I'm planning now is the first project where we had multiple nodes at one site, so maybe I'm yet missing something.  I was thinking I could run a single cable up the pole, and simply split the power at the node end so that I'm feeding power for both nodes.  Then a short jumper between the two secondary ports for DtD.

We wouldn't routinely be using a LAN connection at the site.  That might be a convenience when we are at the site and want to access the node, but if I'm understanding correctly, we'd only really need the LAN data connection to the one node.  We could access the second node indirectly via the DtD connection to verify its performance.  So... no need to involve a switch at the site at all.  Or am I misunderstanding something?
AE6XE
AE6XE's picture
I don't see any issues with
I don't see any issues with that plan.   For other's benefit trying this,  be sure when the cat5 power is split, that the LAN is not also split.  Rather, the LAN only connects into one node.  This insures the same node is always providing the IP address to the device, particularly important if there is a service advertisement on that node.   

Joe AE6XE
AE6XE
AE6XE's picture
One additional thought...
One additional thought...

If you ever find yourself needing to recover the device on the tower, without a LAN connection, there won't be a way to remotely push the reset button.  You'll have to pull down the node and/or climb the tower.  If this is particularly painful, a 2nd cat5 may be worth the time/cost to have this insurance for the future. 
N7TZK
Thanks
Many thanks Joe.

Dave
KG7LMI
KG7LMI's picture
M900 firmware loading issues
Joe, I just picked up 2 Nanostation Loco M900 units to test 900 Mhz vs 2.4 GHz propagation, and I had some issues getting them flashed. I tried to tftp (from Windows 10) the 3.17.1.0RC1 release directly to the unit, apropos the above, but tftp failed silently - no completion message or a "failed" message, it just ended. The activity light was blinking for a while, but after tftp quit the lights on the M900 went back to the alternating flashing pairs. I then tried to tftp XM.5.5 AirOS firmware, and that failed too, but at least this time it gave me an error message. Tried both of the above on the second unit and had the same issues. Finally, I tried flashing XM.5.6 and that worked. It also let me use the AirOS interface to flash 3.17.1.0RC1 (same file I tried to tftp before) so they are both finally up and running. My next approach would have been to try the nightly build but I did not need to take that step. Nothing immediate to address, just wanted to pass on the feedback that the above process did not work (at least for me) on the NM900. Rob

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer