Ubiquity NanoBeam 5AC available for testing

I noticed that while NanoStation AC and NanoStation Loco AC are in the daily images, the NanoBeam AC is not.

And I have said NanoBeam 5AC-16 build 2017 with a flaky ethernet port, keeps disconnecting for a second, but it works well enough for play. So as I cannot deploy it anymore, I may as well use it for validating OpenWRT.

I suspect the NanoBeam AC is internally identical to the NanoStation and NanoStation Loco, but short of me simply flashing that firmware, is there any dev who wants to give me some warning about things I may be forgetting to consider, and/or build a special variant of the firmware for me?

Doublechecked the bootlog, and installed it.
It works.

Made a Wiki page to describe: https://openwrt.org/toh/ubiquiti/ubiquiti_nanobeam_ac

The only thing is: The model is wrong, can someone please make a NanoBeam build where the model is called "Ubiquiti NanoBeam AC (WA)" instead of "Ubiquiti Nanostation AC loco (WA)"

Thanks

You reminded me to rebase my tree and make a PR for NanoBeam 5AC, I was waiting for the rest of WA boards to get merged and got completely buried in work in the meantime

Not sure what a "PR" is, but sounds good.
Let me know if you need me to test anything.

Pull Request.
Last time I tested it worked fine, but it needs updating

Sorry, I didn't know you were working on the NanoBeam AC, too. I've lust created an experimental patch that adds support for it. Since I do not have a device for testing It is missing LED configuration though. Do you happen to know the GPIO -> LED mapping / do you already have LED support?

Dudes, you guys are being way to responsive, I may get spoiled :smile:

Anyway, need to do some social duties. Will test tsys build later this evening, but would prefer to see this in the normal openwrt tree.

No worrys, this will eventually be integrated into upstream OpenWRT. We do however need to make sure it works properly before submitting it to OpenWRT.

I've written a small shell script that should make determining which GPIOs control which LEDs pretty easy: https://gist.github.com/TobleMiner/001fbcdb0479a6766a98cd3e33d76490

It would be nice if you could run that on your device and report what LED is controlled by which GPIO.

Note that on the NanoBeam, all LED are blue. That was also already true on the NanoBeam M5
So not the normal UBNT Red, Yellow, Green, Green arrangement.

The LED are:
Low signal : gpio11
Next : gpio16
Next higher : gpio13
Highest : gpio14

This was still tested using the Loco build. Next up is loading the latest NanoBeam build.

Loading tsys' special NanoBeam AC build: It simply seems to work.
Is Atheros AR9342 rev 2 the actual chip, or a family? asking because the Loco is reported to be no rev 2

image

Thanks for testing! I've just updated the firmware repo to include support for the signal strength indicator. Would be nice if you could test that, too :grinning:

I'm not quite sure about the "rev 2". I'm not entirely sure where from LUCI is taking that information. I think it's simply a difference in representation originating from the use of device tree based ath79 vs ar71xx. AR9342 rev 2 is in fact the actual chip.

Edit:

Since I'm a new forum user I can only post a max of 3 replies in this topic. Thus I've added my response to your reply below here:

Nice, again many thanks for testing! I've created a PR to push support into mainline OpenWRT: https://github.com/openwrt/openwrt/pull/1733

Regarding your issues with auto rollback: If you wait the full 30 second rollback period and allow the device to rollback withour changing anything it will display a dialog that allows you to apply the configuration changes anyway. That comes in quite handy when changing IP addresses.

LED seems to be working, I say "seems" because I am sitting next to the device, so obviously all 4 LED come on as it is a strong signal from my phone. But they go off again when I turn off my phone.

Took a little while to test, because I had to do a full reset to get the default info into /etc/config/system. And that ff-ing auto-rollback is really not working when you have to change IP and juggle cables to move to another IP subnet.