The Orange Pi Zero

Peter ScargillDebian, orange Pi Zero76 Comments on The Orange Pi Zero

Those of you who read my stuff will know that I’ve never been impressed by the Orange Pi boards – the utter lack of communication from the company really is stunning and initially the boards used to get very hot – but then came Armbian and all that changed – third party support and lots of info.  With that in mind I’ve been looking forward to getting an Orange Pi Zero.

Orange Pi Zero

This is not a high end board but it REALLY is cheap so I had to see it working. Well, I’ve started and up to now I’m not stunningly impressed.  But whether it is the BOARD or the SOFTWARE I’m not yet sure. I installed DIET PI – which has worked so well elsewhere and in this case you really are counting on the operating system working from day one because there is no video output. I loaded up the DietPi software and there is a text file on the SD you can go in and setup WIFI etc. This board has both Ethernet and WIFI but I wanted to go in at the deep end. Well, I failed – no-where on the network could we find the board despite setting it up correctly. Ultimately I chickened out and plugged in an Ethernet lead (there’s a long story of broken leads here but we’ll put that to one side).

The board connected up no problem – I went into the setup and set up the WIFI – it found my access point and connected. I changed IP address – voila.  Rebooted – no sign of WIFI (sigh).  I had several attempts at this with a clean SD each time and for now I’ve given up.

My script loaded without apparent issue, on the Ethernet connection.  The thing is – I see these cheap boards as upmarket ESP8266s, i.e. peripherals for dotting around the house – and so the WIFI absolutely must work.

If you’ve read some recent posts I’ve been playing with a VM version of Debian that loads my script up in 18 minutes – well, the Orange Pi Zero isn’t quite like that – it’s nearly done now and at 1 hr 20 minutes – not stunningly fast but no worse than a Raspberry Pi 2.

Now bear in mind when I did a review of the WIFI only FriendlyArm NanoPi Air I commented how much faster the eMMC was – well of course you don’t have that option here. This is a nice, cheap board, cheaper than the Air but I would not want to swap.

Well, the script all worked, no problem – nice little board but the WIFI just would not work reliably – WIFI  is necessary so that it can be used as a place-anywhere peripheral – I remain convinced the better bet is the FriendlyArm product UNLESS you’re planning to use hardwired.

And that started off a WHOLE conversation in here which led to trying XENIAL (Armbian version). After some messing around as the very latest version did not have WIFI installed AT ALL by the look of it.

I also noted that the domain name was not accessible from Windows – as it would have been on a Debian system (Samba) – a line has now been added to the script to ensure that HOSTS is read first.

PHPSYSINFO needed a slight mod – that was provided by Mr Shark and that is backward compatible.

As things stand – I cannot recommend this board for anyone wanting to use it with WIFI.  If you are daft enough to go to the ATTROCIOUS Orange Pi site – you’ll find links for the software – November is the latest at the time of writing and it is irrelevant because there are two links – a BAIDU link in Chinese – and a Google Drive link which AS USUAL is utterly DEAD. So you can go and get DietPI – I could not get the WIFI to work reliably – or grab the latest Armbian – and I could not get the WIFI to work at ALL.  In both cases I’ve now written back to their forums with requests for help and logs in the case of Armbian. Time will tell.

Meanwhile – GPIO for these boards has taken a turn for the better with node-red-contrib-opi-gpio – direct control over GPIO pins from Node-Red – not anything fancy mind you, just input and output – the package is set up for the Orange Pi, not the ZERO so I found some pin differences but if you refer to the actual port bit PA0 etc then this works a treat. That’s a great step forward. Follow the instructions here to install including the additional setup.

https://www.npmjs.com/package/node-red-contrib-opi-gpio

GPIO Orange Pi Zero Node-Red

I’ve also been messing with I2c on this board – you’ll see a July 2017 blog entry on I2c – and that works a treat – actually there are TWO I2c channels on this board and they both work a treat.

76 thoughts on “The Orange Pi Zero”

  1. I’ve just stumbled across this thread after finding the hard way that armbian-config generates a broken /etc/network/interfaces file. You need to edit the line:
    iface lo init loopback
    to be
    iface lo inet loopback
    Then wifi will come up at boot time
    Subtle and took hours to spot…

    2. on 1st boot, always do the UPDATE FIRMWARE on the armbian-config tool… this will update the tool itself, too… well, if you do 1st boot via eth, of course, if wifi is broken 🙂

  3. GPIO works fine from Python at this moment – http://www.diyprojects.io/orange-pi-onelite-tutorial-use-gpio-python-pinouts/#.WOog_vmGPZ5

    I also tried OPI zero as a hotspot is stable and quite fast – 500-600 KB/s.
    To configure OPI as hotspot is easy after read the instructions http://forum.odroid.com/viewtopic.php?f=52&t=25472&

    I didn’t succed to configure it as a bridge, because when I copy /etc/network/interfaces.hostapd to /etc/network/interfaces OPI doesn’t act as a AP.
    If I go back to default configuration from /etc/network/interfaces.default it works fine as a router, but not as a bridge.

    Please @tkaiser send me some instructions if possible.

    2. I’ve got at least 4 of the pins working – both via WiringOP and some random python library I found on github. I am using them at the moment for driving ‘status LEDs’ which I’ve mounted in holes in the official Orange Pi Zero enclosures – one of the GPIOs is HIGH on power up – so I set that to LOW in /etc/rc.local and then I know when the LED on that pin goes out, the Zero has completed its boot up stage. I am writing some bash scripts to monitor various services and then re-light this LED in the event of a fatal error – plus flashing it briefly every minute to confirm the box is still alive. That’s my red LED – I also have a green LED on a GPIO which I’m going to use to indicate other activities but of a non-error nature.

      I’m trying to make it “plug in and go” so that it has visual indication of working okay as a standalone unit rather than having to SSH to it to monitor things.

  5. Hi Pete,

    I have several of these Orange Pi Zeros working and I’ve not noticed a problem with WiFi. I’m running the latest Orange Pi lite/one/zero Armbian image. I’ve been using the WiFi and Ethernet together with a Huawei USB 3G dongle running HostAPD and DNSMasq to make a 3G wireless access point/DHCP setup. I’ve got node.js installed and hope to play with Node red on it. I managed to gIet some cheap but nice looking white enclosures that were designed for the OrangePi zero and it results in a tidy looking tiny Linux box – I just had to make a hole for the WiFi antenna wire!

    I must admit that I’ve not done any ‘test to fail’ testing on the WiFi but the whole install and setup experience was really smooth – much better than earlier Orange/Armbian kit that I dabbled with last year.

    I’ll keep an eye out of WiFi issues and have added it to the list of things I need to pressure test before I roll out too many of these cheeky little budget units – I’ve got 4 sat here waiting to be commissioned!

  7. It could be that this is just not my lucky day.

    Grabbed the nightly built, got Root working – went into NMTUI, told it about the WIFI, OK, now you have to go out of NMTUI and back in to activate which has always seemed strange to me.. and…. nothing to activate. Tried several times, rebooted – still in there – still not showing to activate.

    1. I always use only ‘Activate connection’ for the initial setup but it seems the nightly Armbian build misses the xradio_wlan entry in /etc/modules (without the module loaded WiFi isn’t available). So please try out a ‘sudo modprobe xradio_wlan’ and report back (in Armbian forum).

        1. Thanks. Unfortunately my assumption (missing line in /etc/modules) was wrong. Anyway without logs it’s impossible to get a clue what’s (not) going on 🙂

          Since I can’t test any more I should also stop dealing with WiFi on the Zero at all.

  8. I learned by accident that nightly builds now are available here: https://img.armbian.com/orangepizero/ — please choose Ubuntu_xenial_next_nightly.7z there (links always to the most recent nightly build)

    Latest xradio driver is now included and should be working but unfortunately already misses latest tweaks/fixes made within the last 6 days: https://github.com/fifteenhex/xradio/commits/master

    Please note that Armbian download server structure might change (again) and that in the meantime it has been discovered that this cheap WiFi module used on OPi Zero is based on an already known other chip so currently some devs look into re-using the already available mainline driver for XR819 module too (read as: still WiP and further improvements are very likely in the near future)

    1. Thanks for that, Tkaiser. In the meantime I went off to the DietPi site as someone told me there were updates. Well, I loaded up their DietPi for the Orange Pi Zero – no way does that WIFI driver work – I’ve left them a note. After setting it all up – it finds the access point, you save it – the software confirms you have to reboot to save the settings and next time you power it up – no WIFI hardware!

      Some day soon one of these systems will hopefully give us a good working WIFI on these (otherwise just fine) boards…. I’m downloading that nightly build of Armbian now. As soon as I’ve confirmed the latest version of my script works on DietPi (I’m pretty sure it does) I’ll load up Armbian and give it a go.

    1. Oh well done – because the Orange Pi Zero is REALLY looking like a nice little board marred only by rubbish WIFI performance… if that can be made to work and recover reliably from issues- I can see a bright future.

      I did two minutes ago incidentally find one advantage of the NanoPi Neo Air over the Orange Pi Zero… and it’s a biggy – the latter fits into a standard single-pole DIN rail enclosure (the ones the size of a single contactor). A shame, had there been just 3mm more we could have also fitted one of the little ITEAD power supplies.

    2. So – I waited a couple of days – that Github doesn’t help me much. Forgive me for being thick but is there an image somewhere with the wifi driver? I went to the normal downloads in Armbian – it says there are no nightly builds for this board and the rest come under the heading of “legacy” so I’m not sure exactly where to go to get the latest version…

      Pete.

    3. TKeiser – never did hear back on this – is there an updated Armbian for Neo image we can try out?

  10. tkaiser – got your message above – I will look forward to hearing from you – I’ll just use this 3.4 version for testing… up to now with power management off, the WIFI feels ok.

    Cheers.

    1. NOW I remember why I don’t use Ubuntu… can’t find a single WORKING guide to installing Mosquito with Websockets. Plenty of guides – none of them work.

      1. Well, I don’t know which guides you followed (and hope you didn’t followed guides for Jessie or Raspbian since there mosquitto seems to be broken and has to be built from source). I just did an “apt-get install mosquitto” which also installed “libev4 libuv1 libwebsockets7”. Then I added
        root@fexsend:/etc/mosquitto/conf.d# cat websocket.conf
        listener 1883
        listener 1884
        protocol websockets
        And now mosquitto listens on these ports:
        root@fexsend:/etc/mosquitto/conf.d# lsof -i | egrep “1883|1884”
        mosquitto 24605 mosquitto 4u IPv4 89310 0t0 TCP *:1883 (LISTEN)
        mosquitto 24605 mosquitto 5u IPv6 89311 0t0 TCP *:1883 (LISTEN)
        mosquitto 24605 mosquitto 9u IPv4 89318 0t0 TCP *:1884 (LISTEN)

        1. Seriously – I must’ve done something wrong – I’ll go back to the master (I backed everything up before starting).

        2. Ok, I have to hand it to you – that was worthwhile – I appear to have a reliably working (WIFI) Orange Pi Zero – and my script NEARLY works – I’m making a version to run in Ubuntu… with the change to Mosquitto – that APPEARS to work.

          https://bitbucket.org/snippets/scargill/94yxL

          However – the Apache section failed miserably – too late at night to look at that now… but the rest – Node-Red APPEARS to be fine… if I or some helpful soul can get the Apache version working I’ll mod the script to add options to handle debian or ubuntu – that would be nice…

          2. Hmm… it seems Debian 8 still ships with horribly outdated php5? I remember that was a problem at some customer locations since they had requirements for deprecated php5 while up-to-date distros only provide php7 any more.

            Maybe it’s a good idea to check for Debian/Ubuntu in the beginning and then act on accordingly:

            Distro=$(lsb_release -c | awk -F” ” ‘/^Codename/ {print $2}’)

            Also I would examine the individual packages to be installed individually (apt-cache show) since in your script some requirements seem too hardcoded to me. Usually one should rely on the package management to keep track of dependencies (otherwise it gets kinda useless). Sounds like a bit of work but necessary anyway since I doubt you’ll remain forever on Jessie but switch to stretch sometimes next year (with the above approach that’s then just another $Distro based case for installation)

            1. Any help you can give with replacement commands to provide a better install for that section which will work with both Debian and Ubuntu would be great. There is no need from my perspective to stick with PHP5 as long as PHPLITEADMIN works with later versions.

            2. Thanks for that one-liner (I’m really not that good at batch files) – that is now in the script and later I will use it as a conditional. So far I’ve found “xenial” on the Orange Pi Zero and “jessie” on the Raspberry Pi”.

              1. “lsb_release -c” should be either “jessie”, “xenial” or “stretch” (next year when Raspbian upgrades). I would consider everything else simply as error/unsupported and stop or switch into trialout mode (if you officially support Ubuntu immediately people might try to run your script with Ubuntu 16.10 — I would only support LTS releases and that’s Xenial now and for the next 2 years).

                And then I found it always useful to use functions for different stuff, could then look like eg. this here: http://pastebin.com/WfZu6eL8

                Sorry, no time to dig further, am busy with a huge data migration projects now (feels somewhat strange to deal with ‘big iron’ again where the storage systems alone consume 2.500 times more than an OPi Zero 😉 )

                1. It would seem that there are ways to ensure the WIFI comes back up in the event of failure – but the most recent rely on making changes to etc/network/interfaces which of course is not used in Armbian (well the one I’m using anyway).

                  The suggestion is to merely add a roaming line

                  allow-hotplug wlan0
                  iface wlan0 inet manual
                  wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
                  iface default inet dhcp

                  Where would one put the equivalent in Armbian – or is there another way to do this. In the event of WIFI failure I really need (I would have thought others do to) for the WIFI to attempt to reconnect until it gets there….?? Sorry if I missed something.

                  1. As explained when you exchange the AP then this is something entirely different than ‘disconnect’ and ‘automatic re-connect’ later (this is how it should work and always worked in my tests).

                    Please really forget about fiddling around in files below /etc, use ‘sudo nmtui’ again after exchanging an AP and watch out for the uuid and mac-address values in the profile files below /etc/NetworkManager/system-connections/

                    1. Sorry – they are not reconnecting – and I’ve realised the one Orange Pi I have one Wireless is doing the same. Need a generic method of reconnecting. I’ve tested this again this morning by simply switching off the access point and back on. All of my ESP devices reconnect, none of the WIFI Pi-like devices do – including the Odroid and the Orange Pi Zero.

                  2. I testes it a couple of times when Armbian switched to NM, I tested it before I even answered you and I tested it again: http://pastebin.com/RiKNTyZZ

                    But I did *not* exchange the AP in between. As already written: If the AP changes you’ll have to create a new profile using this new AP (different MAC address!! See also explanation above)

                    1. Went back to hardwired (not practical when the unit has been put in the loft for example) and deleted the wireless connection. Checked there was nothing there. Added a new wifi connection – saved. When I went to Activate – nothing there. So – I rebooted without the WIRED connection. Sure enough – connected (so something wrong there as the newly created connection should have showed up). Turned off the router for 20 seconds – turned it back on. The Orange Pi would NOT come up. Meanwhile as usual, all my ESP boards came back on line so nothing wrong with the new access point. I then did a system scan to see if the IP address had changed.. not there. I don’t know if you are using a different version to me. REbooted the Pi with hardwired reconnected. NMTUI doesn’t seem to have a -v command. Checked and the WIFI version said activated… so took out wired, rebooted – WIFI ok. Turned off router 20 seconds – turned it back on. Waited a minute or so – no WIFI unit. Did another scan – no sign of any OrangePiZero.

                  3. Well, using a Linux device with legacy kernel (your OPi Zero now) and connecting it both via Ethernet and WiFi to the *same* network usually means a lot of strange symptoms (due to the kernel preferring interfaces, due to your router/AP handling stuff like that and timeout stuff).

                    I know it sounds like a lame excuse (but I don’t care that much today since now that all the work is done I get a cold — haha, as every year!) but it’s really like that. Sometimes WiFi works a few minutes later magically after you unplugged Ethernet (when your router/AP learned that the MAC address of the WiFi is not any longer accessible through Ethernet) but this is too complicated I guess.

                    Simple advice, either use WiFi or Ethernet or let’s better say never connect both devices to the same network where the same AP/router/DHCP-server is active. It won’t work.

                    That’s the reason why we enabled serial console on OPi Zero through Micro USB: So can setup WiFi without any hassles. Sounds weird from your perspective but that is my overall experience with OPi Zero and WiFi: works just fine (but you were able to spot even a couple of corner cases we should be aware of and will add to Armbian documentation — next year…)

                  5. Hi Pete,
                    I’m using the Armbian image on my Zero and it has config in /etc/network/interfaces that is definitely used as I have bridging between interfaces as part of my USB 3G dongle to WiFi access point setup (HostAPD etc).

                    However… I’m using wlan0 as a hotspot rather than as a station – basically using an Orange Pi Zero to turn a 3G USB dongle into a mobile internet access point and DHCP server that also happens to host Node-Red… I’ve not done any testing of the Wifi when used in ‘client’ mode so maybe the bugs are particular to that usage rather than mine hence the reliability of WiFi in my experience.

                    I’m just running an Armbian ‘server’ image downloaded a few weeks ago – nothing obscure.

  11. BTW: To ‘fix’ the WiFi issue(s) with DietPi just some information.

    Armbian uses a ‘probing’ mechanism for SDIO attached onboard WiFi (we had no other choice since we support devices like Beelink X2 where the vendor exchanged the WiFi module between production batches — older models have an Ampak, newer ones RealTek). There starts a detection sequence probing each device on the SDIO bus and then the right driver gets loaded automagically. On OPi Zero we had the problem that we had to blacklist the dhd module for whatever reasons and that the xradio_wlan needs to be loaded twice.

    In Armbian this is done automatically — no idea how DietPi does it. Maybe just adding xradio_wlan to /etc/modules a second time does the trick?

    We also refrain from using outdated/anachronistic configuration bits (fiddling around in text files) but provide a network-manager based approach. Connect over USB serial console (like you did on NanoPi Air), run nmtui and you’re done. (Re-)connecting to networks, setting regulatory domain and dealing with WiFi power management is done from within network-manager in Armbian (and simply works… ouch, just realized that a ‘h3consumption -w off’ is needed to disable WiFi power management permanently, we still don’t disable it by default)

  12. In case WiFi should work out of the box I strongly recommend using latest ‘nightly’ Armbian build available here: http://image.armbian.com/betaimages/

    The kernel 4.9.0 variant is still missing Wi-Fi support (none of us devs took the time to throw the available patches into Armbian’s build system) so 3.4.113 is recommended for end users. Setup can also be done via USB (g_serial — serial console available when connecting Zero’s Micro-USB port to an USB port of your host)

    1. Hi Tkaiser – the page you pointed to was full of Ubuntu images – do you have similar nightly builds for Debian 8?

      1. Nope, since this makes absolutely no sense 🙂

        Ubuntu 16.04 is an LTS release, the packages there are usually not that outdated compared to Debian Jessie and most importantly all software is built with a more recent GCC version which results in huge speed improvements in some areas. Since we’re talking about slow SBC here it’s essential to keep an eye on efficiency so avoiding Debian 8 is always a good idea when talking about the normal armhf/arm64 distros (Raspbian being an exception since all ARMv6 packages there are built with maximum optimizations — but on RPi 2 or 3 it’s a no-brainer to immediately switch to armhf based Ubuntu since way faster).

        If you really want Debian 8 Armbian images you can always use our build system. DietPi folks do the same. They let Armbian generate a fully working OS image for a H3 or H2+ device and then let their PREP_SYSTEM_FOR_DIETPI.sh script cripple the installation until it’s DietPi. And then stuff like this happens: https://github.com/Fourdee/DietPi/issues/640

        1. While I cannot disagree with you about performance, but here’s my take on Debian/Ubuntu. Windows is the de-facto operating system which people get used to. There are many who’s first step into Linux is Raspbian via the Raspberry Pi – and using Debian is only a stone’s throw away. There are many who are unwilling to get into the differences between these operating systems – I do know that I have an installation script that works with a wide range of boards using Debian – and falls over very quickly on Ubuntu. I’m going to take a guess that the number of people using the Raspberry Pi outweighs the rest and so surely something that is more compatible with the Raspberry Pi has to be a good thing. I have been wrong before however. And to prove myself wrong I will give your nightly a go.

          1. Hmm… well, the ‘do it like we did it all the time before or as everyone else does’ take isn’t that sufficent if you want to improve things (which is at least one of the reasons I contribute to the Armbian project).

            I also can not guarantee that your installation script will run flawlessly within 16.04. But in case of installation scripts it’s good practice to check environment first (lsb_release -c) and then maybe implement some switches to deal with known issues here and there.

            In the past the installation scripts we developed had to run on Linux, Solaris, OS X and IRIX (the latter gone in the meantime and replaced by FreeBSD) so the first thing always was to check ‘uname -s’.

            BTW: Calling your script with ‘/bin/bash -x’ won’t be an option to debug Ubuntu problems but maybe adding a ‘set -x’ followed by an ‘exec 2>>/tmp/debug.txt’ inside routines that fail is a good idea? At least that’s what I always do when I have to debug bash scripts: http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html

            1. It can never be said I don’t try. So right now my little Orange Pi zero is sitting there having successfully loaded the nightly Ubuntu build doing an update/upgrade cycle and I’m looking around for the bit that tells you how to enable WIFI on it without having to research which chip it uses… want to point me in the right direction so I don’t re-invent the wheel?

              1. Just ‘sudo nmtui’ as usual. Given you use Armbian_5.24.161221_Orangepizero_Ubuntu_xenial_3.4.113.7z this should work out of the box. In case you got the mainline kernel variant (kernel 4.9.0) then no WiFi since no one so far added the necessary patches (I would do it but since I currently can’t test with the Zero I won’t).

                1. Right – back to flashing the SD – I assumed the later one would be better – might be a good idea to add “-no-wifi” on the end of the name!?

              2. Well, I did some reading and realised one should use NMTUI – problem with that is – in setting up a WIFI – as well as SSID and PASS it wants a “device” for the profile. No idea what to put up there but the WIFI is not coming up as an option for “activate”.

                  1. Ok, got the earlier version – now I can “activate WIFI” once I’ve put in the ssid and pass.. in Putty – the characters inside that setup page are weird – the borders are fine – but where it says WIFI connect – weird blocks.. Anyway, I’ve disconnected WIRED and it does appear to be working – is that it – do I have to disable WIFI power management or am I good to go?

                    2. I would disable WiFi power management using the ‘sudo h3consumption -w off’ call as long as you’re doing interactive stuff via WiFi. Otherwise it feels too sluggish.

                      But when I did some consumption measurements with WiFi power management active Opi Zero went below 0.5W… which is somewhat impressive IMO. And in case it’s just used as a sensor or data logger that receives/transmits some bytes from time to time enabling power management seems like a good idea.

                      Anyway: As soon as we’re ready with a mainline kernel image fully supporting all features (that means also getting the device tree overlay stuff in a state almost as easy useable as on Raspberries with Raspbian) I’ll drop you a note.

                      One great thing when using 4.x kernel is already that memory management is way better than with the outdated Android 3.4 kernel now used. Especially useful on the small 256 MB variant.

        2. Question Tkaiser in case you (or anyone else) has any thoughts. Today, I bought a new access point. My office here has a variety of little ESP8266 boards (Orange Pi Zero, Odroid etc all running Armbian of one type or another).

          I set up the new access point – gave it the same name and password as the old one , turned off the old one, turned on the new one.

          In every case, all the little ESPs reconnected immediately – none of the Armbian boards reconnected at all and had to be shut down and turned on again at which point they worked perfectly.

          Somewhere in the back of my mind I remember having this issue with Raspbian and read an article as to how to ensure that the board would reconnect flawlessly every time after WIFI outage. My main controller for the house has done that flawlessly for many months – sadly I have no idea what I had to do to make that happen. Any ideas – because a home controller that stops working after a WIFI failure is not very useful.

          2. It’s designed to reconnect automatically if one of the configured access points comes back into reach. But if you exchange the AP then this is slightly different since you might use same SSID and passphrase but it’s a different device (differing MAC address) and since NM doesn’t use it automatically.

            It should be anough to simply use ‘sudo nmtui’ again to ‘Activate Connection’ (different MAC address will also lead to different UUID so for the board these are two different network profiles).

            If you just switch off your AP and later on there shouldn’t be any hassles.

            BTW: We chose network manager here especially for devices like OPi Zero (or soon Pinebook or Olimex’ OSHW A64 laptop) that might be used with different SSIDs and also with wired connections from time to time. NM when set up correctly should ensure that always the SSID with strongest signal is chosen and in case an Ethernet cable is connected this is used mainly (adjusting the routes, but I fear that also doesn’t work that great with 3.4 kernel so another reason to upgrade ASAP to 4.9 on those small H3 devices)

            1. Hi there – made no difference, to test last night I simply turned the access point off for a minute and back on – the boards do NOT reconnect.

              1. Did you repeat the ‘sudo nmtui’ step *after* you exchanged your AP already? Since if not i can’t work. If you exchange an AP you need to ‘activate a new connection’ since the MAC addresses changes.

                NM has to deal with situations where 20 AP are present all being called »Pete’s net« and using same SSID/passphrase while always trying to choose the ‘best’ (signal strength amongst other criteria). So APs with different MAC addresses are different devices and there’s a need to distinguish between them.

                The WiFi client in your ESP is not prepared for such sophisticated stuff but a full blown Linux implementation has to deal with such stuff (to be honest: If you use a Linux Laptop or an OPi Zero or NanoPi Air with a drone it’s important that these devices (re-)connect always to known SSIDs and must be able to use more than one)

  13. WiFi on the Zero works simply great though I can only speak of Armbian here (there’s one issue with driver loading that we could immediately fix and then we don’t rely on anachronistic methods to configure stuff but use flexible methods). WiFi works way better than any of those el cheapo USB WiFi dongles.

    Combine this with the PoE option, the fact that you get an antenna even with the cheap $7 variant, that they now start to solder 2 MB SPI NOR flash by default (so when it’s about netbooting you do not even need to spend another few bucks for an SD card) and this is simply the greatest ‘Linux capable’ IoT device currently around. 🙂

    Xunlong plans to release a H5 based Zero Plus 2 soon, same form factor but just like NanoPi Air AP6212 (WiFi/BT) and eMMC. They also start to produce ‘HATs’ for the 13-pin connector. As usual all information available in Armbian forum: https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/?p=21651 (see also pages before for the $2 universal HAT).

    All the stuff on the board is also already supported upstream (my Zero runs kernel 4.9) so as soon as all the patches have landed also official mainline kernel support will be ready (which is great news since the smelly 3.4 kernel most OS images currently use is pretty inefficient)

    Comprehensive device information: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero

    1. Be careful with the “PoE” support 🙂 It would seem that this is just reusing unused Ethernet lines to supply +5v rather than supporting 802.3af PoE. Plug this thing into a PoE switch and I’d expect it to go pop.

      1. Just read through http://linux-sunxi.org/Xunlong_Orange_Pi_Zero#Powering_the_board — everything is explained there.

        As PoE support is optional nothing pops when you combine this with 802.3af/802.3af+ switches. It needs taking a decision which PoE variant to implement. For obvious reasons I prefer passive PoE (simply using those 2 unused cable pairs combined with a 24V or 48V central PSU, a passive PoE injector there and buck converters soldered to those solder pins on the Zero).

        But you can also implement ‘real’ PoE and add an active 802.3af (mode B) PoE splitter for 20 bucks or above to any $7 Zero (which does not make that much sense IMO).

        Now with SPI NOR flash pre-populated the total costs of one PoE powered OPi Zero installation fall down below $15 ($7 for the device, $3 for the step-down converter and proportional costs for the central PSU + passive PoE injector). No need to add a (quality) SD card, no need to use a (quality) PSU with each device. Simply great.

        And for those thinking that would be an exotic setup simply take a look at Ubiquiti or MikroTik network gear.

          1. Power supplies are not something I’d like to get into recommending – could generate a lot of questions! Some are good – some are not so good. Whatever you pick – if it is from China – overrate it by at least 50%, maybe more.

  14. Hi Pete,

    I received my Orange Pi Zero couple of weeks back.. Tried Armbian Legacy 3.4.113 Jessie, Wifi worked flawless and stable. Had some problems with DietPi on NanoPi NEO with Wifi.. was intermittent, not sure if it’s the OS or dongle.. DietPi worked great on NanoPi M2 too.. Armbian mainstream doesn’t have good support for Samsung processors, till date only supports Odroid XU4.

    One thing good about OrangePi Zero, CPU H2+ runs super cool, didn’t had the need for any heat sink.. Still will test full burner with high number crunching routines..

    Found this interesting post to slow down CPU frequency and disable cores under low load situations..

    Running H3 boards with minimal consumption:
    https://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/

    Cheers,

  15. Peter, I’ve got two CHIPS here. I cleared all the original stuff off and just loaded the no gui firmware. I loaded your script without some of the stuff I don’t use and it has run fine for days now. However, the cost is most definitely not $9 to the UK! I wanted 4 CHIPs + 5 off bottom covers so CHIP + cover = $11 total cost was $68.10.
    Like you I had envisaged using them as ESP like peripherals. I think some of the Chinese companies are using shipping charges to bump up the profit on the boards. The shipping charges are increased by each board added to the order. Similar tactics are used with the Nano’s

    1. shipping tactics: yeah could be, but then they don’t “expect” mass orderings, in which case you could try an aliexpress type supplier?

  16. Why not considering the CHIP as an alternative? Not the fastest, but 9$, wifi working, 4gb emmc, battery connector, eventually a vga adapter “to rule then all” on first setup, plenty of i/o and documentation, and your setup working (not tried gpio, though)

    1. Tried the Chip – slow as molasses… and 4GB is not quite enough for me? I do like the battery connector bit though – lasts for ages on the battery.

        1. Oh true – I probably don’t need it on most devices – I just put it all on there because I can 🙂

Comments are closed.