Size Matters… Neo AIR

Peter ScargillGeneral34 Comments on Size Matters… Neo AIR

tmp897DWhen it comes to size, this one is as good as any… the FriendlyArm Nano Pi Neo Air.

You’ve probably read my blog about the Nano Pi Neo, a device I can only describe as “cute” because of it’s really small size – but powerful non-the-less. Well, the AIR version takes things a stage further. No video, no USB (well, no connector anyway) and no Ethernet connector which makes it EXCEEDINGLY THIN.  But it DOES have Bluetooth and WIFI including a socket for an optional external antenna (it also has on-board antenna).

tmp39E7So – H3 Cortex A7 Quad-Core processor – which means that a variety of alternative operating systems to the default Ubuntu will work (just as well as I for one have no interest in Ubuntu). The board is 40mm square and the highest point on the board before you (optionally) fit the (provided) connectors, is the micro-USB connector, which could make for a MIGHTY small controller!

The Neo AIR comes complete with 8GB of on-board  eMMC loaded with Ubuntu. I really don’t see the point of this as it is so hard to fully make a copy as against just replicating SD cards. Aside from anything else – all these boards call themselves or refer to PI – and the PI comes with Debian – not Ubuntu!  However – reporting this for the record. Idling power (depending on operating system as little as 1 watt (i.e. 200ma at 5v). Headers for 3  USB 2.0 ports (but no connectors) 512MB RAM and finally a DVP camera interface. Connectors include UART, SPI, I2C, GPIO, IR, SPDIF and I2S (though actually making use of these will be down to software support!)

Here’s a handy pinout:

tmp4E0F

The whole thing weighs less that 10gms.  I’m thinking this could well make a minimal system for talking to Alexa DOT – perhaps with some IO all in one tiny box!!

tmp23CAA heatsink was provided but no box – but then again any box would probably be of a height to accommodate connectors and I’d really like to see this in a super thin box – or even on the back of a Nextion display.

I note that another blog has covered the use of the board with the Ubuntu operation system so I won’t get into that here.

Note the micro SD connector bottom left in this photo and the power connector/ OTG port top right. There is also a separate 4-way connector for serial debugging.

I tried to use one of my NEO SDs with DIETPI but the software worked – but without WIFI – I could not see a way to fix that and have written to the  DIETPI site in case their software can be updated. That would be good.

Meanwhile I’ve just tried the latest ARMBIAN – blew the SD – popped it in – it works – (serial monitor) – went into NMTUI (command line WIFI etc. etc.) – works a treat. How there is NO mention of Bluetooth in that setup but as I don’t need that right now I’m not too bothered. One of our readers has already commented “No Bluetooth” so I’m guessing that remains off the table for now. I could of course use FriendlyArm’s image but that means re-jigging my script with umpteen installs which probably would not work. Erm, no.

Right now I’m in the middle of running my script from the serial terminal. WinSCP works with an IP address (it would be so much better if Samba were installed from the start so that the domain name worked) and I have noticed that when bringing up a terminal, it is SLOW – I suspect that is down to the WIFI signal – I noted when using Armbian in the past that the WIFI was not that hot on other boards – using DIETPI on he NEO it was marvellous – but that’s not working for the AIR so far.

I did note earlier that the TIME was wrong on the unit (no doubt an issue with Armbian) as it said the last log-in was November 1st – it is November 7th and I’ve only just installed Armbian.

Accordingly my script has been sitting here in a loop complaining that “binding.gyp has a modification time 180293 in the future” and it looked like it was going to sit there and wait that long! As I write this I’ve used the DATE command and all came along nicely if slightly more slowly than normal. First time I’ve ever had that date issue.

And while all of this was going on – the board was only just warm, certainly not warm enough to warrant a heatsink.

HOWEVER – initial impressions – once my script was done.. WINSCP – slow as a DOG. Not remotely in the same league as a typical Raspberry Pi – or even the NEO – HOWEVER – According to TKAISER of Armbian this is because the board needs an external aerial – which begs the question – why didn’t that come with the board!! On close inspection there is no internal aerial… dohhh…..

Update Nov 08, 2016: Ok, aerials on the way – I’m using it with a GPS aerial which is hardly ideal and the WIFI seems solid enough. I hope the proper aerials are small!! I read elsewhere that the chip used is the Ampak AP6212 as used on  Raspberry Pi 3 and there’s a link to more info on that… https://github.com/seemoo-lab/bcm-rpi3 (https://github.com/seemoo-lab/bcm-rpi3). Still running cool enough to NOT need a heatsink.

Update Nov 11, 2016: While waiting for the aerials – and in another blog, TKaiser of Armbian just happened to mention they have a utility to copy an SD setup to eMMC.  It is part of the standard installation and is:

/usr/lib/nand-sata-install/nand-sata-install.sh

So I ran it in a terminal and after a while – it told me to reboot without the SD. I did that and LO – not only a working AIR but a much faster AIR. I took the SD, inserted it into the other board, booted up – repeated the operation – and lO – TWO working AIRS– a quick change of name of one of them and Bob’s your uncle! Well impressed!

Update Dec 20, 2016: Here’s a thing. After not using the Neo for a little while, last night I decided to do an apt-get update/upgrade. The update failed due to inability to contact some sources. I tried 3 or 4 times – no joy. I decided that either the WIFI was in trouble or a source was offline and to leave it until this morning.  I got up this morning and the update was fine.. but when it came to the upgrade, I got a message to say the disk was full.  8GB of eMMC – i was sure I’d only used half of that.  Anyway I went off searching – and discovered several large LOG files – deleted the larger onces and now all is well – I’ve recovered over 2GB of log space. Hmm.

34 thoughts on “Size Matters… Neo AIR”

  1. Having dabbled with Orange Zeros, I encountered a serious overheating issue but wifi worked fine. Adding heatsinks and disabling 3 cpu cores reduced the processor temperature but not to an acceptable level. About 4 weeks ago, I downloaded and installed the latest Armbian image which reduced greatly the internal temperature but now wifi doesn’t work on either of my two O-Pis. I am sitting it out with fingers crossed, awaiting for the next Armbian release.

    1. My experience with Armbian has generally been good – and their temperature management has also generally been far better than some of the default releases that come with some boards. However, like you I find the WIFI on the Orange Pi Zero to be utter rubbish – whether that is due to incorrectly implemented software or a “feature” of the board, I leave to others to define.

    2. i think i’ll use mine (which unfortunately has only 256mb ram) attached to my laser printer to convert it to a Google Cloud Print device, leaving it off most of the time and turning it on only when printing… at least it will have some use… have to see if it could fit inside the printer itself, if i could harvest power with a stepdown from inside…

  2. On a related note. Got my $7 package 2 hours ago (Orange Pi Zero *with* external antenna included). We added support for the board already without physical access two days ago and now being able to test I got the last missing part up and running (Wi-Fi, the board uses a new Wi-Fi chip no one used before)

    Wi-Fi is not that great as on earlier Orange Pi boards but of course outperforms every USB dongle around. I already configured the board as low-consumption data logger (h3consumption -D 132 -u off -m 912 -c1) and started with consumption tests.

    http://linux-sunxi.org/Xunlong_Orange_Pi_Zero

    1. Oh excellent. Well I thought they might’ve sent me a couple of samples to review but I must be talking to the wrong guy because I can’t get a much as a hello..

      Your armbian email address bounces incidentally…

      Pete.

  3. One final comment regarding your Wi-Fi update and RPi 3 reference from today. While the Air uses the same Ampak chip as RPi 3 (and eg. also Banana Pi M2+) some of the features that can be used are a *driver* thing. And driver means kernel (version).

    Armbian on H3 devices supports a so called legacy kernel (3.4.113 based on Allwinner’s Android kernel for their older SoCs but with tons of patches on top) and in dev branch mainline kernel (we switched to 4.9 recently). Currently to make use of mainline kernel you would’ve to build your OS image yourself (easy but needs a VM and some time, just check docs.armbian.com for details) or choose one of the ‘nightly builds’ also called beta images: http://image.armbian.com/betaimages/ (sorry Ubuntu Xenial only since faster due to more modern compiler switches used)

    Why does this matter? Since with mainline kernel you would use the brcmfmac driver (that’s what all examples for RPi 3 are based on) and with legacy kernel it was bcmdhd until recently and is now an improved version called just dhd. And with this driver to let the Wi-Fi work as AP for example you would’ve to use “op_mode=2” when loading the module. So not all examples known from RPi 3 will work out of the box until you switch to mainline kernel.

    I haven’t tested myself yet but an Armbian image with 4.9 kernel for NanoPi Air should bring up all the hardware except of camera interface since CSI is still WiP in mainline kernel: http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix

    1. The TWO is not new – the ZERO is. I did ask them if they’d like it reviewing but as always – no answer.

      1. PC 2 is new and the first of its kind (64-bit H5 SoC instead of H3), same applies to Zero (H2+ SoC which seems fortunately be compatible with H3).

        I kinda agree that Xunlong’s naming scheme sucks (“OPi 2” was a “Plus” minus SATA-bridge, GbE and eMMC, “OPi Mini 2” was a “2” minus Wi-Fi also, the “PC 2” now is something new and according to naming scheme we’ll see a “PC 2 Plus” then with eMMC and Wi-Fi in a few months) 🙂

        I also kinda agree that communication with Xunlong is… different. But on the bright side it should be mentioned that the *kind* of answers is surprising in a positive way.

        1) I asked Steven almost a year ago whether he can not start to develop a H3 board that exposes all 4 real USB host ports without playing Raspberry Pi (using an internal USB hub). Never got an answer but when they released the great OPi Plus 2E (GbE, 2 GB DRAM, all 4 USB ports directly exposed) he mentioned in a small comment that this device is dedicated to our community wishes

        2) I asked Steven to provide PoE abilities long time ago. Answer was ‘no, people would fry their board’. What can be seen now on OPi Zero: PoE option useable in 3 different ways which is amazing!

        3) ssvb, one of the linux-sunxi core devs, asked Xunlong to solder cheap SPI NOR flash on the boards so that we could bring some sort of ‘BIOS experience’ to dev boards (a basic bootloader can reside there that contains all the device specific bits which can then boot a device agnostic OS image from SD card, eMMC, any USB device, network, whatever). As usual he got no answer but instead PC 2 is the first SBC now with 1 MB SPI NOR flash soldered (but I fear without contents, we just start with this work)

        So the ‘style of communication’ is not that verbose but surprising in a positive way 🙂

        A lot of information regarding both devices as usual in Armbian forum and on CNX (comments section):
        – http://www.cnx-software.com/2016/11/05/orange-pi-pc-2-development-board-based-on-allwinner-h5-soc-launched-for-20/#comments
        – http://www.cnx-software.com/2016/11/02/orange-pi-zero-allwinner-h2-board-with-wifi-and-ethernet-is-up-for-sale-for-7/#comments

        We should receive dev samples soon. If assumptions are correct and H5 is pretty similiar to A64 (Cortex-A53 with *real* 64-bit support unlike RPi 3) and also H3 (USB — 4 real USB ports and not just one + hub like on the Raspberries) then GbE equipped PC 2 will be a great device and software support will be ready soon.

        And OPi Zero will simply be an IoT game changer even if our first assumptions regarding compatibility aren’t correct. At least I already hacked together a so called fex file describing the hardware yesterday so if everything goes well we have full Armbian support pretty soon (and ‘Armbian support’ means that other projects that rely on us doing all the difficult bits can then also provide OS images later: DietPi, RetrOrangePi and maybe more)

  5. Peter, a suggestion… editing your previous articles is ok, but make readers go nuts… i’ve just seen addition about tkaiser observations, i would never reread an article i already read… maybe is better, in case of additions and not full rewrite, to time tag your updates at the end of the article, so anybody know he read this a month ago, and now there’s something new… and maybe publish both creation and last modification date below article title… just my 2c…

    1. I usually write “Updated XXXX” – but in the original article I did say it was ongoing 🙂

      I update a lot of articles as I can’t stand seeing blogs that are hopelessly out of date.

        1. Ok so they sent me a heatsink… a big one – but running Armbian – the chips including the H3 are running luke-warm. I don’t know if that means the chip is throttled down too much (TKAISER any comments?) but there is currently absolutely no need for a heatsink.

          I’ve plugged in a GPS antenna as an emergency measure. It is probably only a little bit better than useless but the WIFI is working a treat now.

          1. Pete, you never need the heatsink unless you want to run permanently heavy loads on those small gems at maximum clockspeed (since without heatsink throttling will occur). We (linux-sunxi community and Armbian) tweaked throttling settings for H3 half a year ago and now it’s just simple adoptions when a new device will be released. Armbian settings for NEO and Air focus on IoT useage so they prefer lower consumption over maximum speed but you’re free to adjust that to your needs utilizing our h3consumption tool: http://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/#entry14381

            Your date problems were clearly also related to no Wi-Fi being useable (none of these small boards has a RTC so without network their time is always reset to ‘OS image build time’) and it would be great if you can also try to poke FriendlyARM that they start to ship with an Antenna like Xunlong does. The $7 Orange Pi Zero comes with an antenna while $20 NanoPi Air does not? Close to unbelievable.

            BTW: In case your Wi-Fi is still too slow on the Air it’s most probably related to power-management settings, latest fix from a few hours ago requires manual intervention (on the final Air OS image this will be fixed of course, I also think BT will then work out of the box): https://github.com/igorpecovnik/lib/issues/536#issuecomment-258765831

            1. Right – yes, the time issue – you’re right- it would be down to lack of WIFI – obvious when you think about it.

              LAtest update – just for clarity – are we just talking about an APT-GET-UPGRADE here to make sure I have the very latest Armbian of a few hours ago?

        2. Seems only NanoPi NEO PCB rev 1.0 was prone that much to overheating (U7 being an LDO regulator back then producing heat and increasing consumption unnecessarily). Seems that was fixed on the NEO with PCB rev 1.1 or 1.2 and the Air wasn’t affected at all (but settings matter, when overclocking DRAM you might get 2-3% more performance with some tasks but increase temperature by 10°C).

          Just a reminder: Allwinner devices receive great community support and you should find comprehensive device documentation in linux-sunxi wiki: http://linux-sunxi.org/FriendlyARM_NanoPi_NEO_%26_AIR (just use the search bar in the upper right for other devices)

          1. Thanks for that TKaiser… to save me re-inventing the wheel do you know if there is an AIR-specific WiringOP ? Or is it the same as the NEO? GPIO/I2C etc control always seems to be the awkward bit compared to Raspberry Pi….

            1. Regarding WiringOP NEO and Air should have identical pinout (at least according to FA’s wiki). With all the various H3 devices it’s pretty easy: There’s

              – Orange Pis with 40-pin header (they’re all the same but on some models pin header is rotated by 180°)
              – Orange Pi Zero (26-pin header with slightly different pin outs)
              – NanoPi M1 (and its OEM pcDuino 4 Nano)
              – NanoPi NEO/Air
              – Banana Pi M2+

              So given that all the pinouts are documented somewhere someone could tweak WiringOP in a way that the specific device could be provided as an argument so one version could serve them all.

              And nope, currently last-minute fixes in Armbian won’t be available in ‘normal’ OS images immediately, this is only supposed to work for our ‘beta images’: http://image.armbian.com/betaimages/

              So currently you would’ve to modify the contents of the specific file (see Github link above) and then also issue a ‘h3consumption -w off’ to disable Wi-Fi powermanagement.

              BTW: There’s a reason why we don’t disable it by default since while active PM might interrupt SSH sessions and lead to some dropped packets it might be exactly the mode you want for a data logger or a wireless IoT node in general. I just did some quick tests but active and disabled Wi-Fi powermanagement made a difference. To test really through this stuff would take one day or two, time I spend currently on more important stuff (providing more fun 😉 )

              1. I was referring to consumption differences with active vs. disabled Wi-Fi power management. I’ve a setup here using another SBC (Banana Pi Pro) whose power management IC allows to measure consumption through an ADC (so BPi Pro powers the other device through its USB ports and voltage + amount of current are fed into a monitoring solution).

                Using average values this is pretty precise (20mW differences can be monitored) but really testing through different settings requires a lot of time since I use 30 or even 60 min average values (otherwise you can’t measure stuff like ‘consumption with Wi-Fi more or less idle’)

  6. When I was referring to DietPi and H3 devices I just wanted to point out that in the meantime they take an Armbian image (or create one themselves using our build system) and then start to strip the installation down (removing packages and functionality) and add DietPi stuff. U-Boot, some of the settings and kernel (including Wi-Fi drivers) rely on Armbian, so when you do an ‘apt-get upgrade’ in DietPi you get automagically some of the kernel/driver improvements we at Armbian made in the meantime.

    But I still think that the main difference why el cheapo USB Wi-Fi dongles worked better with DietPi than with Armbian is that DietPi already took care about power-management settings while Armbian added this just recently (read as: hopefully bug free since an hour). In Armbian now it should just be an ‘h3consumption -w off’ to disable Wi-Fi power-managent on H3 devices.

    As already said: Wi-Fi is still WiP in Armbian, we really don’t care that much about those cheap USB dongles (since they’re crap compared to onboard Wi-Fi of cheap H3 devices) but will focus on squeezing out the max of onboard components (I hope Wi-Fi on upcoming Orange Pi Zero is at least as good as on OPi Lite — and that’s magnitudes better compared to RealTek dongles). And regarding your Wi-Fi experience with the Air you already spotted the problem: No antenna, horrible connection 😉

    I tested the Air with both the crappy cable antenna from Pine64 and with the Antenna Wi-Fi equipped Orange Pis come with: with the latter NanoPi Air and OPi Lite worked in a similar good way, with Pine’s antenna it’s ok-ish (but still way better than RTL8192 based Wi-Fi)

    1. Thanks for that TKaiser. I’m off to find something that will pass as an aerial until Friendlyarm come back to me. Probably a bit of wire.

  7. Pete, please be aware that NanoPi Air has no antenna unless you add an external one. Crappy Wi-Fi experience as expected without.

    Then please be also aware that DietPi images for H3 devices rely on Armbian. If you get ‘better’ Wi-Fi throughput with DietPi compared to Armbian than maybe this is either the result of better drivers (DietPi uses Armbian’s repositories to get kernel — read as driver — improvements) or different power-management settings.

    Wi-Fi in Armbian is currently a lot WiP so expect things to improve. I just tried to fix power-management settings in a way that will work on every of the +40 SBC we support: https://github.com/igorpecovnik/lib/commit/fe8afb20f0c8d5f62f0d4e6fbc0f6f536faeb97d

    We also try to make stuff working in a generic way so we now rely on network-manager that can also be used from the CLI (nmtui, nmcli). As a side effect also Avahi is now available so a ‘ping nanopiair.local’ will just work (installing Samba for name propagation/resolution is just insane — seriously this IoT stuff should also be looked at from a security perspective and minimizing attack surfaces is important)

    BT will work with this device (don’t forget to attach an antenna!) but currently no Armbian dev looked into enabling it out of the box. We have support for Cubietruck for a long time, Igor added BT support now for BPi M2+ and I would assume he’ll soon look into NanoPi Air (same chip, same procedure, it’s just doing it and testing through — but since we have a few other interesting devices to play with this is not top priority).

    1. Hi there TKAISER

      I thought that the little unit on the back of the AIR was a ceramic antenna – but on close inspection it an XTAL and there is no sign of an internal aerial… In which case why on EARTH did they supply the board with no aerial – I will write.

      No – DIETPI right now isn’t supporting the AIR – a shame as I had a perfect working setup for the NEO and it won’t work on Air. I’ve now installed Armbian and by and large LOOKS ok – aside from the WIFI – which we’ll resolve soon – thanks for the feedback.

      I will keep an eye out for Bluetooth developments 🙂 and thanks for the feedback.

  8. Peter in regard to Bluetooth I’m not seeing any Bluetooth devices detected by Ubuntu, either. Looks like Linux support for the BT chip isn’t ready (or not loaded)

    1. Christopher – please elaborate – so you’re using the FriendlyArm installation then? How is that going other than the BT?

      1. The ubuntu build that shipped with the device is ok for basic use,
        wifi setup was a doddle (just add a wpa_supplicant.conf as in their wiki).

        There don’t seem to be temperature sensors exposed, so I’ll be going with
        armbian when I can, as I haven’t fitted a heatsink and am a little concerned about cooking the chip.

        Power consumption has been good, I haven’t seen it go over 500mA so far.

        I haven’t been able to get the DVP camera port working, if I connect an orange
        pi camera the board doesn’t boot.

        1. Thermal readout with sun8i legacy kernel is available, you should get fully blown monitoring also convering supply voltage (that is lightweight enough to not influence the device’s operation!) using my script http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh

          In Armbian it’s more easy: ‘sudo armbianmonitor -r’ will install everything needed. Armbian’s approach to deal with Wi-Fi is also different. In my opinion dealing with /etc/network/interfaces and wpa_supplicant.conf is so anarchonistic. Better use nmtui/nmcli. NetworkManager takes care about routing too, re-connects lost connectings and so on. It’s way better than those static stuff you find in gazillions of tutorials copy&pasting outdated stuff again and again.

          Regarding thermal protection there’s not that much to fear. Armbian team developed sane throttling settings a few months back and we informed FA how to implement this with their OS image too. But after few tests with freshly released (and simply amazing) Orange Pi Zero I’ll tweak Armbian settings for the NanoPis maybe also soon (always fun to tweak settings to both increase performance and decrease temperature/consumption)

          Be careful connecting different cameras to the boards. Xunlong, SinoVoip and FriendlyARM all use the same 24 pin connector but pinouts differ (especially voltage!) even if these are all H3 based boards. There’s a huge thread with details in Armbian’s H2/H3 forum.

        2. And another one regarding NetworkManager vs. static configuration. In my opinion devices like NanoPi Air or OrangePi Lite/Zero will be used mobile so it’s important that they search for available SSIDs and chose those that fits best. Not possible with static config, easy when adding a few connections to NetworkManager since the latter deals with details from then one.

          Also what most people don’t know: NanoPi Air as well as all other H3 boards always can be also used wired too. Armbian’s legacy images ship with the g_ether module so simply connecting the H3 device with a host and enabling g_ether support will lead to an usb0 network device and you get slightly more performance through the Micro USB port compared to Fast Ethernet (for details search for ‘g_ether’ in Armbian H2/H3 forum).

          AFAIK that’s not possible with FA’s image since their kernel misses the small necessary patch we added a few months back. And in Armbian you would’ve to disable g_serial since by default we enable a serial console on the Micro USB port of NanoPi Air and Orange Pi Lite (those two not Ethernet equipped)

  9. Where can you buy these from at a reasonable (?) price?. I specced up a unit with camera/case/heatsink = $47 but then $22 to ship to uk….

  10. Have you tried i2c on these things yet? I was thinking about using one in a project but I can’t seem to find much on how to use i2c apart from they support it.

    1. I’ve not tried anything yet – I put the NEO SD in and everything booted up fine – but no WIFI – clearly they’ve used a different driver to the one I was using on the NEO (plug-in USB cheap Chinese). Busy researching now how to get the WIFI working – I’m not planning to use their standard Ubuntu.

    2. I’ve got i2c working on it for an SSD1603 display. I’ve documented all my work over on github. Basically what this OP did here but WAY more involved.

      I also tinkered a little bit with Bluetooth and got that working on FriendlyArm’s Ubuntu kernel. Still need to test it out on Armbian kernel. I’m told that the Bluetooth only does file transfer, not music though. In any case, all is documented here:

      https://github.com/BiTinerary/PocketServerPi

Comments are closed.