The NanoPi Neo

NeoBy now if you read this blog regularly you’ll have heard me rant on about the FriendlyArm boards – mainly because they are inexpensive and actually do work well as Pi alternatives – you’ll also note that I don’t blindly praise them – I’ve still not managed to get the T3 to run a 32gig SD of Android – and it’s an old Android to boot… but generally – I like their stuff.

SO it will come as no surprise then that I’m interested in the new NEO. And why would that be? Because it is SMALL and CHEAP. It has no WIFI or Bluetooth but it has hardwired Ethernet – just the job then for a NODE-RED central controller perhaps?  This is clearly aimed at a market not wanting a graphical interface as no hdmi out – but at the price – I’m happy with that.

So there’s a reason it is cheap – there are two versions, 256Mb RAM and 512MB RAM – I would not personally give time to the former – but the latter would, you would think, run Node-Red, SQLITE and Mosquito without issue… So the extra RAM puts the board at $9.99 plus whatever postage you get stuck with in your country…  cheap by any standard…

Neo in caseBut – looking at the docs – it seems that right now the main official option is for Ubuntu – I don’t know about you but when something says “An open source tiny PI” on the front of the box, you might expect it to be somewhat compatible with THE PI.. and that means Debian for me – and no doubt for most people familiar with the Pi.

The internal processor is an Allwinner H3 quad core like the Orange Pi so it is reasonable to assume that there will be alternative  software. It looks like there are 3 UARTS so one would hope for  two to be accessible.

There is one USB, a microSD slot, a micro USB OTG port and 2 USBs via headers.  The expansion port claims the usual, I2c, SPI etc but of course that will only happen if the software will support it.   Size is 40mm by 40mm – which makes it kind of smaller than a Pi Zero.

It occurred to me that setup could be a problem with this board as it has no SCREEN but read on – as it turns out it wasn’t an issue.

FriendlyArm sent a copy of Ubuntu which I’ve no interest in but thought I’d better try to ensure the board was ok. Sure enough it worked but the instructions on the box were the wrong way around. The blue LED flashes constantly – the green LED stays on – according to their info – it should be the other way around. Also to resize the SD they offer a Linux solution – assuming everyone has a Linux computer spare – or a simple SUDO fs_resize. The latter at first didn’t work until I realised that firstly the sudo command was not there and secondly I didn’t need it as I was root !!!

So all of that worked well – but I know for a fact my script won’t work on Ubuntu so I needed to get a working Debian

So – off I went to get ARMBIAN – and sure enough there is one version there for this particular board! Update 22/09/2016 – there have been some issues with the Armbian setup – read their site – but also see my script – it refers to a specific version of the legacy Jessie installation on the Armbian site (at the time of writing the latest). With the script this is running exceedingly well  - and yes, Node-Red can see serial ports 1, 2 and 3 (0 is in use for debugging).

I flashed a 16GB SD with the Armbian code using Win32DiskManager, plugged in the Ethernet and power. A dim green light came on. After a few seconds it brightened up.  And then maybe 30 seconds after that a blue light started flashing regularly along with the green – a sure sign SOMETHING was happening. On the Armbian website it warns that the first time boot could take minutes – so I left it.

Next stop Advanced IP scanner. Sure enough there was a board in my address range – sitting at – with my favourite tool, WinSCP, I used the login credentials root and 1234 and – no file list – it HAD logged in but nothing.  I wrote off to the Armbian guys and apparently logging in with Putty (SSH) was needed to make an initial password change – and sure enough – it worked. I went back to WinSCP – and bingo.

The software asked me if I wanted to change screen resolution which was a bit odd as I was running in a terminal and the board has no screen!!!  Not really sure what to do with that – why would they enable the graphical environment when there’s no screen. So – off I went (as root) to get tightvncserver – and sure enough it installed but would not run – complaining about lack of fonts. No big deal – I un-installed it. i had no intention of running a graphical environment on a board with no screen connection anyway !! Ultimately I did return to this and did get the graphical interface running as I wanted to see if I could get WIFI working on Armbian – but for the life of me could not get WIFI drivers to install.

I REALLY think this board needs a heatsink which was not initially supplied.  I wonder why it is that Raspberry Pi manage to run without one and these H3 boards end up running hot enough to cook eggs – there ARE H3 boards which are faster than the Pi but I don’t think this is one of them.  However the fact that it is so SMALL and inexpensive it is worth a little effort. Having said that with the latest Armbian the chip is running at 51 degrees C without the heatsink so that’s not bad.

Next stop, with the board running Armbian I left it  running my installation script designed for a Raspberry Pi to install a host of utilities and Node-Red, Mosquitto and SQLITE.   In the process I updated my script to include the new node-red-dashboard which is the worthy successor to node-red-contrib-ui and added things like “cu” which allow you to use the terminal as a serial VT100 terminal.


Overall? Well, I’m really happy – I have two working UARTS in Node-Red (UART1 and 2) I can’t find the pins for UART3 but Node-Red is happy to talk to it. UART0 works well as a serial monitor.  I’ll need to load up some GPIO tools etc. but the bulk of my stuff just seems to work.

Update 29/09/2016 – FriendlyArm just contacted me –just to confirm – on the NEO – they never did bring out GPIOA13 and GPIOA14 to the connectors and hence UART3 though technically “there”, is not actually available.

For connections – see here -

Now as it turns out they bear no resemblance to other boards (unless I’m missing something) – so I started to experiment with the help of links from people in here.

THIS FELLOW - got the M1 working with the Wiring Pi and so I installed that (H3 – same chip) – but could not get pin mappings to work.

I discovered that GPIO WRITE 24 ON turned on the little blue light on the board… and then purely by trial and error…

  • GPIO WRITE 10 ON  -  GPIOC3 – pin 24
  • GPIO WRITE 14 ON  -  GPIOC2 – pin 23
  • GPIO WRITE 12 ON  -  GPIOC0– pin 19
  • GPIO WRITE 13 ON  -  GPIOC1 – pin 21
  • GPIO WRITE  3 ON  -  GPIOA3 – pin 15
  • GPIO WRITE 6 ON  -  GPIOA2 – pin 13
  • GPIO WRITE 2 ON  -  GPIOA0 – pin 11
  • GPIO WRITE 28 ON  -  GPIOG6 – pin 8
  • GPIO WRITE 29 ON  -  GPIOG7 – pin 10
  • GPIO WRITE 24 ON  -  GPIOA6 – pin 12
  • GPIO WRITE 26 ON  -  GPIOG9 – pin 18
  • GPIOG8  (pin 16) could not turn on
  • GPIOG 11 (pin 7) – could not turn off
  • GPIOA1 (pin22) could not turn on

So – that’s a START!!! Just need I2c now!! The only issue for me here is that FriendlyArm ONLY provide and support UbuntuCore for the NEO which is of no interest to me.  I don’t know if this is down to a language problem or what but…ok, the ad does say Ubuntucore ready – but the name says “NanoPi” – and surely to qualify as a Pi you should be supporting the main operating system of the Pi – that being… Debian.

Interestingly their M1 product DOES support Debian – which is strange.  But here’s the problem – though WiringOp just happens to work for GPIO on both the M1 and the NEO, and compiled WiringOp programs can be made to work as user Pi,  as the company’s Matrix software which DOES give you access to I2c etc. seems to have some issues with any other than ROOT access - and FriendlyArm do not currently know how to get around that.

So the ONLY  the way forward here to make full use of these boards, is for someone brighter than me to work on WiringOP to make it completely compatible with the NEO and hopefully the M1 – at that point – we’re onto a real winner but it would be so much better – when someone brings out hardware products like this – which rely SO heavily on documentation and software – if they would get it right themselves!!!  The manual for the Matrix software is even now in Chinese only!

Update October, 2016: If you look at my later article which includes updates on the NEO, there is a DietPi out that works with this and my script and makes for a small, fast installation.

Conclusion: All down to postage… this is a marvelous little board you might describe as “cute”. With no 3.5mm jack I’ll have to get my hands dirty and solder that 0.1” edge connector on to get audio out. I’ll report on that later and it appears there’s a microphone input too on that connector along with an option for an IR input! Also look out for their new Lite version - I have one on the way - with WIFI instead of Ethernet - and it has 2 USBs. At the time of writing - the Armbian installation with a WIFI dongle on the Neo was not that good but the DietPi version works a treat.


45 thoughts on “The NanoPi Neo

  1. Pete,

    If your CPU is getting extremely hot when the system is at idle, you might want to check your kernel/syslog log files for “ARISC ERROR” and “ARISC WARING” (sic) messages. The system should be automatically scaling back the clock frequency (and reducing the CPU dissipation) when there's little to no load, but some versions of Armbian had a typo in a config file which caused this to fail (the typo should be fixed now, but large numbers of the "ARISC" errors in the logs shows that you've got a pre-fixed version).

    The quick fix for this is to modify the file /etc/default/cpufrequtils and change this line:-


    to be:-


    ...then reboot the system.

    Not only will the errors disappear, but the CPU temperature will drop by 10~20C, because the system can now throttle the CPU speed successfully.

    Thanks to Thomas Kaiser at Armbian, who's been putting in a lot of effort to get this working on the little ARM boards.

    1. Thanks for that. It was hot (maybe just too hot to touch) on powerup - I just checked the file and sure enough it was set to 24000 and I've now changed it to 480000.

      After some faffing on due to a power cut and my script being slightly out of date I'm now all up and running and I've updated the blog accordingly. Not touched GPIO yet - I'm rather partial to PIGPIO on the Pi which I'm sure will not be available for this - but I'll need to get some tool up to ensure that as PI user running Node-Red I can access GPIO. Other than that it's looking good.

      Question - why does doubling the minimum speed make something work that didn't before?

      1. "Why does doubling...?"

        Because the typo -isn't- in the cpufrequtils file, but rather in one of the config files which is compiled into a binary. The system is unable to run at the 240MHz setting (which is why it generates the ARISC messages) and ends up running at full speed all of the time. Setting it to 480MHz gives it a usable frequency which it can drop back to at idle.

        Bet you wished you hadn't asked, now. 🙂

        [Many apologies to Tomas and the Armbian team if I got that too badly wrong]

        1. Thanks. Well I left it at 240000 as I'm not seeing those error messages you suggested - now that I've found the log file.

          Everything works - but I need the equivalent of the Raspberry Pi GPIO utilities so that use Pi can control the ports... anyone any advance on that? In Node-Red happy to call a cmd line function if need be - but it has to be usable by a normal user and not root.

            1. This ABSOLUTELY could be helpful MrShark!!

              Ok so taking that as a starting point I ran the code (I note he refers back to my blog!!) and it kind of compiled (as user pi).

              pi@nanopineo2:~$ git clone -b h3
              Cloning into 'WiringOP'...
              remote: Counting objects: 262, done.
              remote: Total 262 (delta 0), reused 0 (delta 0), pack-reused 262
              Receiving objects: 100% (262/262), 237.78 KiB | 236.00 KiB/s, done.
              Resolving deltas: 100% (139/139), done.
              Checking connectivity... done.
              pi@nanopineo2:~$ cd WiringOP
              pi@nanopineo2:~/WiringOP$ chmod +x ./build
              pi@nanopineo2:~/WiringOP$ sudo ./build
              ./build: 4: ./build: [[: not found
              wiringPi Build script

              WiringPi Library
              [Compile] wiringPi.c
              [Compile] wiringSerial.c
              [Compile] wiringShift.c
              [Compile] piHiPri.c
              [Compile] piThread.c
              [Compile] wiringPiSPI.c
              [Compile] wiringPiI2C.c
              [Compile] softPwm.c
              [Compile] softTone.c
              [Compile] softServo.c
              [Compile] mcp23008.c
              [Compile] mcp23016.c
              [Compile] mcp23017.c
              [Compile] mcp23s08.c
              [Compile] mcp23s17.c
              [Compile] sr595.c
              [Compile] pcf8574.c
              [Compile] pcf8591.c
              [Compile] mcp3002.c
              [Compile] mcp3004.c
              [Compile] mcp4802.c
              [Compile] mcp3422.c
              [Compile] max31855.c
              [Compile] max5322.c
              [Compile] sn3218.c
              [Compile] drcSerial.c
              [Link (Dynamic)]
              [Install Headers]
              [Install Dynamic Lib]

              WiringPi Devices Library
              [Compile] ds1302.c
              [Compile] maxdetect.c
              [Compile] piNes.c
              [Compile] gertboard.c
              [Compile] piFace.c
              [Compile] lcd128x64.c
              [Compile] lcd.c
              [Compile] piGlow.c
              [Link (Dynamic)]
              [Install Headers]
              [Install Dynamic Lib]

              GPIO Utility
              [Compile] gpio.c
              gpio.c:804:13: warning: ‘doPadDrive’ defined but not used [-Wunused-function]
              static void doPadDrive (int argc, char *argv [])
              gpio.c:892:13: warning: ‘doGbw’ defined but not used [-Wunused-function]
              static void doGbw (int argc, char *argv [])
              gpio.c:934:13: warning: ‘doGbr’ defined but not used [-Wunused-function]
              static void doGbr (int argc, char *argv [])
              [Compile] extensions.c
              [Compile] readall.c
              [Compile] pins.c

              All Done.

              As you can see - despite some error messages - the compilation went ahead. and sure enough GPIO READALL worked.

              The next problem - the ports don't match with the M1 which has a completely different connector - and a larger one.

              I tried several at random and was just about to give up - thinking perhaps the GPIO facility may not have worked properly - when I stumbled on 24... "gpio write 24 on" turned on the blue light on the NEO board. not QUITE what I had in mind but it proved the software was actually working.

              The only comment I would make is that the GPIO pins they've brought out.. are those used for other functions - such as serial, SPI, I2c etc. Not real general purpose pins.

              So I'm guessing the sensible way forward would be to get I2c working on this board as a first step to getting more IO pins!!

              GPIO write 10 ON - turns on pin 24 on the connector - SPIO_CS/GPIOC3

              Just a case of deciding which are best served as special functions and which as GPIO.

            1. No you cannot in Node-Red.... the pins need to be accessible to the normal user which Node-Red is running as. GPIO works - but I've not yet figured out the pin mapping for the NEO - apart from one pin

          1. But I remember in the past, maybe in the orangepi post, that you said that eventually you could recall shell commands via exec nodes, in case of an higher level library missing...

    1. Regarding NEO consumption: With FriendlyARM's or DietPi's settings it might be more than an RPi B+ when Ethernet is connected (makes a difference of up to 200mW on any LAN9514 equipped RPi but not on H3 boards) but with Armbian's new settings (day before yesterday!) it's as less as 900mW in idle and won't exceed 2W in worst case conditions (measured between PSU and board!)

      You find NEO numbers starting from post #13 in this lengthy thread here: (the RPi stuff above might also be interesting since cutting power to LAN9514 is the most effective measurement on Raspberries while it's disabling HDM/GPU, lowering DRAM clock and tuning cpufreq settings on the H3 boards). If you want a really energy efficient H3 board better choose the two small Orange Pis, they idle as low as 500mW when features are stripped down to RPi Zero level.

  2. Just a few words regarding different H3 devices (be it NanoPi M1/NEO, one of the many Orange Pi or BPi M2+). For all these boards except M1 you find comprehensive information in the wiki at -- on the NEO page there are also some links to Armbian forums which might explain a few differences.

    At Armbian we did a lot of research the last weeks targeting IoT stuff (a new area for us since just half a year ago we only focused on server usage). A first result are special settings for NanoPi NEO since this device has a higher idle consumption than the Orange Pis and also a different DRAM configuration which also needs special consideration. Since DietPi's David now uses Armbian's build system for all non-RPi DietPi versions I would assume our new optimized settings will arrive in DietPi rather sooner than later.

    Anyway: Please forget about thermal/consumption results for H3 devices from the past. It's all about settings, these were close to moronic with most OS images and with Armbian's optimized ones H3 boards idle at below RPi level.

    From the software/usability perspective we're eager to learn what has to be done to get Pete's home automation stuff up and running on our Debian Jessie variant (Armbian is not another distro but a build system utilizing either Debian or Ubuntu) since once it works flawlessly on NEO or any other H3 board it will automagically also work on all the +40 SBC we currently support 🙂

    1. What would be really nice would knowing how to modify that wiring pi utility to properly reflect the available pins on a given board... trying to adjust the NEO right now as it isn't the same as the M1...

      1. Pete, it's pretty simply to adjust pin mappings in WiringOP sources. Foxconn/SinoVoip were surprised that the pin mappings they defined for their own hardware (written as definitions in a so called fex file) do not match reality. And it took them just a few months to figure this out:

        At least in the link to their forum it's explained how to adjust the different pin mappings. I'll get back to you after vacation and hope that I can convince other Armbian devs/users to support looking into this GPIO library and sysfs stuff and to provide unified settings for the various different H3 and A20 boards as a milestone for the end of this year. Depending on legacy or vanilla kernel sysfs nodes differ between boards/kernels and different SoCs require different Wiring* libraries. All the knowledge is present in Armbian forum but scattered all over the place 🙁

        By providing an unified Wiring* library and sysfs nodes for just these 2 SoCs we would have identical situation for +25 SBC most of them featuring an RPi compatible GPIO header 🙂

        1. Hi there

          "Pretty simple" being a relative term... 🙂

          It would be really nice if you could put a command line option into GPIO to adjust for the different boards - like ...

          gpio -neo

          or similar... took me ages to map the neo pins -lucky I didn't blow anything up as I just made a text file to turn everything from gpio0 to 40 on and off to see which pin worked. Still don't understand the other two.. if you have any insights on using I2c from the command line (as a normal user - in the way that GPIO works) would be great as if one wants to use the serial etc on that board there are not that many GPIO pins.

      1. The whole magic why user pi in Raspbian has access to this and that is located in /etc/udev/rules.d/99-com.rules and the fact that the pi user is added to a few groups by default.

        Armbian doesn't have group gpio (yet), does not have a default user account but forces you to create one on first login (we don't like pre-defined accounts and especially passwords since users do not change the latter!) and does not add the first normal user to (yet non-existing) group gpio.

        But changing this is easy but needs a few considerations. Also I'm the wrong person to deal with this since I'm a server guy who never used WiringPi/OP directly and is a novice with all this IoT stuff. The best way to deal with this is to create a new thread in developer forum at and collect what has to be done to make transition from Raspbian to Armbian for an average RPi user as smooth as possible while not undermining the security principles Armbian is built on 🙂

        As an example: We could tweak Armbian's user creation in a way that if the account name is 'pi' then group gpio will be created, user pi added and the udev created. Accessing GPIO pins with account pi? Done.

        But this needs some time, considerations and contributions by users way more familiar with all this stuff than me.

  3. Hi,
    Great post.
    This is a request for guidance.
    My ESP8266 module connects to "" and subscribes to a topic say "b1". What ever is published to "b1", it can read it immediately.
    Problem happens when my second ESP8266 module subscribes to "" to "b1". It continuously returns :

    WiFi connected
    IP address:
    Attempting MQTT connection...connected
    Message arrived [b1] 0
    Attempting MQTT connection...connected
    Message arrived [b1] 0
    Attempting MQTT connection...connected
    Message arrived [b1] 0
    Attempting MQTT connection...connected

    Could you kindly suggest what might be going wrong. I look forward to your advice.

  4. There has been discussion about a script to install Node-Red on the NanoPi; could you share that with me? Also, have you gotten access to the NanoPi's GPIO pins within Node-Red? Any insight on how you accomplished this would be helpful.

    1. My script will indeed (UTTERLY no guarantee) work with the NEO and if you look through the blog you'll see that I have at least managed by using the EXEC function and GPIO managed to control most of the outputs (and inputs)... not quite gotten to the point of getting I2c out of them yet and unless someone re-compiles WIRINGOP for the NEO, the PWM might be out (Friendlyarm seem quite content with their ROOT only code - I have tried to explain why that's not a good idea but it's fallen on deaf ears - my argument being that they should be making their IO as useful as that on an RPI... I don't think some of these guys are really that familiar with the RPI). Anyway - here's the link to the script - read carefully - I ended up on this device using ARMBIAN as the base - got WIFI working but NOT well (REALLY poor range but I honestly think it is software related), so I abandoned that route and I'm using them hardwired.... as against the M1 who's WIFI is very good on WIFI.

      Anyway, check out NEO in my blog - and here's the address of the script...

    1. Quick answer - no. There is only one pin (at least, this is my understanding) that is hardware PWM - you can have several software PWM pins but I would not expect them to be of any use. On the other hand, check out my home-made I2c peripheral - recent blog - you can have lots of PWM pins on that and they are pretty solid - only 8-bit PWM of course - another solution - there is a board out there - can't remember it's name but I've blogged it - that is i2c in and has something like 16 channels of high-definition PWM - it is dirt cheap.

Leave a Reply

Your email address will not be published. Required fields are marked *