FriendlyARM launched NanoPi NEO board with Allwinner H3 processor, Ethernet, and USB ports for $7.99 to $9.99 in July, and the company is back with a new board with the same form factor and processor, by trading Ethernet for WiFi, dropping one USB 2.0 port for a DVP camera interface, and adding an 8GB eMMC flash.
NanoPi NEO AIR specifications:
- SoC – Allwinner H3 quad-core Cortex A7 @ 1.2 GHz with an ARM Mali-400MP2 GPU up to 600 MHz
- System Memory – 512 MB DDR3
- Storage – 8GB eMMC Flash (Samsung) + micro SD card slot
- Connectivity – WiFi 802.11 b/g/n and Bluetooth 4.0 LE (via Ampak AP6212 module) with IPEX antenna connector
- USB – 1x micro USB OTG port, 2x USB via headers
- Camera – 1x DVP camera interface with optional 5MP CAM500B camera
- Expansion headers
- 24-pin header with I2C, 2x UART, SPI, PWM, and power signals
- 12-pin header with 2x USB, IR pin, SPDIF, and I2S
- Debugging – 4-pin header for serial console (unpopulated)
- Misc – Power and status LEDs
- Power Supply – 5V/2A via micro USB port or VDD pin on serial header
- Dimensions – 40 x 40 mm
- Weight – 7.5 grams without headers; 9.7 grams with headers
The company provides an Ubuntu Core + Qt firmware image, which will most likely be pre-loaded in the eMMC flash on the board when shipping. More details about hardware and software can be found on the Wiki (English translation in progress).
As mentioned in the specifications, FriendlyARM will also offer an optional 5-megapixel “CAM500B” camera board that can be connected to the DVP interface of the board. The Wiki shows instructions to stream the video to a web page using mjpg-streamer.
armbian has also been working on supporting the board, but I’m unclear about the status right now. I’m sure you’ll soon find out by reading the comments’ section of this post.
NanoPi NEO AIR can be purchased for $17.99 with 3 headers, but you may consider adding the heatsink for $2.97, and a 3dB WiFi antenna for $3.99. I could not find CAM500B camera module, but for reference CAM500A camera module (possibly not compatible) is sold for $19.99.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Heh, they finally made one that’s flat, but if the rest of the H3’s are any indication it probably needs a heatsink. 😉
We (Armbian) spotted NanoPi NEO AIR two months ago while monitoring FriendlyARM’s Github repo (fortunately FA develops in the open). Support for the board is also added since weeks but we don’t want to repeat the mistake with NanoPi M1 (released an image containing bugs and not having the board on our desks to check/fix immediately).
The hardware used here is well known (another H3 board — Banana Pi M2+ — uses the same AP6212 for BT/WiFi and also the same camera module) so everything is expected to work out of the box. But IMO the most interesting thing is the camera, I had no luck with any SBC running Linux so far getting good quality/fps out of 5MP camera modules like OV5640 as used here. It seems this has changed in the meantime since a few community members spent a lot of work on the various camera connectors and camera modules found on H3 boards so that we might get working drivers and knowledge how to deal with the different pin-outs on Bananas, Oranges and Nanos soon-ish: http://forum.armbian.com/index.php/topic/1213-ov5640-camera-with-orange-pi/page-3#entry16486
Anyway: For Armbian fully supporting NanoPi AIR it would be nice if FA sends dev samples to Igor and our camera folks (but I would assume they’re already in contact and hardware on its way).
On a related note: Armbian team developed an eMMC backup/flash tool yesterday so for H3 boards with eMMC we might provide OS images that can be flashed directly via USB soon.
@PoV
FriendlyARM had a problem with heat on NEO PCB rev 1.0 but fixed that with rev 1.1 (~10°C less) and I would assume AIR is designed like NEO 1.1. So if you don’t want to run really heavy loads on these little gems you can save the heatsink and rely on throttling instead (which means kernel 3.4 ATM or choosing Armbian images for the NEO with 4.6 since we integrated THS / throttling / cpufreq patches there).
Many people seem to fear chip temperatures above 40°C but H3 is rated for up to 125°C (and ambient temperature of 70°C). Our throttling settings take that into account: we start throttling at 65°C on the smaller H3 boards and 75°C on the large ones. Monitoring (or let’s better say ‘getting an idea what’s going on’) is easy by starting
and you find information in Armbian forum how to adust values to your needs (or feelings — those SoCs are fine running at higher temperatures)
Hey @tkaiser where I can find the eMMC backup/flash tool?
Thanks
@manuti
http://forum.armbian.com/index.php/topic/2125-armbian-for-orange-pi-does-not-boot/?p=16455
Check link and discussion there. I tested read speed from eMMC in USB Mass Storage gadget mode and it was only a fraction of what’s possible (14.7 MB/s vs. 78 MB/s when reading eMMC directly on H3 device) so maybe we come up with some speed improvements in the future. And currently it only works with H3 devices but since FEL boot works with (almost) all Allwinner / sunxi devices that have an USB OTG port exposed we add support for more device families later.
I’m probably asking a dumb question but what video outputs are there? I could see this being great for Gameboy Pi type projects but would want to understand what can be connected where!?!? I see the MicroUSB is also for power in…
Wow, what a nice little board. Would order 10 if not for FriendlyARM now limiting parcels to <1Kg… Will have to do with 2 for now.
Thanks @tkaiser and Armbian team for all your efforts! Really awesome work.
@Meth
You can use the Micro USB port or two pins on the (here unpopulated) 4 pin header. Simply check the link to FA’s wiki above or linux-sunxi page for NanoPi NEO (as soon as AIR dev samples are available we will add the AIR stuff there too): http://linux-sunxi.org/FriendlyARM_NanoPi_NEO
NanoPi NEO/AIR are true headless devices, neither HDMI nor composite video are exposed (and H3 lacks LCD capabilities).
@tkaiser
A little off topic, but do You have a idea if there still will be support in mainline for the nand flash on the A10/A20 devices?
@Roel
If I understand correctly while this is still WiP it is used on NextThing Co’s C.H.I.P. since a while (but they have some trouble with new NAND from Toshiba now) and if it’s working reliable there not that much will prevent using NAND on A10/A20 and other A13 devices (R8 on the C.H.I.P. is an A13 in reality). But using raw NAND directly requires a few other changes compared to SD cards or eMMC where the FTL (flash translation layer or also called ‘controller’) hides the complexity. Using UBI with UBIFS or SquashFS seems like a good idea there.
@Meth
Just had a look: In the meantime Olimex finished their A33-OLinuXino which is now on sale: https://www.olimex.com/Products/OLinuXino/A33/A33-OLinuXino/open-source-hardware
A33 is also quad-core A7 just like H3 but suited for mobile use (LCD, PMIC and battery support). Such a type of device you have in mind (Gameboy Pi type projects) would benefit from both LCD and battery. I wonder whether other vendors will start using A33 for cheap(er) dev boards since for wireless IoT stuff A33 could get as popular as H3/H2 now (PMIC/battery support being a big plus here).
@tkaiser
No ethernet…
@zoobab
…and no HDMI either (just to anticipate TheGuyuk’s next comment here 😉 ). A33 is a tablet SoC and made for very cheap mobile devices. And I would assume the SoC is almost as cheap as H3 so for dev boards or IoT nodes featuring SDIO WiFi it would be a great choice since it’s accompanied with AXP223 PMIC (battery support).
Allwinner’s A33 BSP kernel looks pretty similar to H3, mainline u-boot support is already there and linux-sunxi devs are busy with A33 mainline kernel support. But where’s the hardware? NanoPi AIR with A33 and battery connector would make much more sense IMO…
@tkaiser
Does having OS and user data stored in onboard eMMC either reduce or eliminate the memory corruption problem during brownout power-loss, compared to holding everything on SDcards ?
@paul
No idea, in fact I do not cleanly shutdown any Armbian installation on a variety of SBC since weeks without trouble (SD card and eMMC, currently testing with solar panels and dumb powerbanks). I know SD card corruption only from Rasperries.
Yes, it was on Raspberry forums about 3 years ago I first read about memory ocassionally getting corrupted after abrupt power-loss, when I was considering using headless Pi2 for 24/7 datalogging and needed to guarantee the Pi would reboot gracefully into the last running App on restoration of power. The reply was, not just SBCs using SDcard for all storage, but from memory they wrote all SBCs even with fixed onboard storage have that failure possibility – not necessarily on every reboot, but sometimes. For 24/7 365 days PA, ‘sometimes’ is not reliable enough. I do recall reading decades ago that some MCU board designs had a mains-failure sensor IRQ line, coupled with a big enough capacitor on Vcc to allow the computer state to be saved in non-volatile memory before DC power lost. As I never hear of this protection in modern SBCs, I guess it is not there. Interesting that you who are testing many different SBCs all the time, do not experience memory corruption after presumably just switching off the SBC at the mains. That implies as you say, is a weakness of just the Raspberry SBCs. Curious as to why that should be so.
@paul
On Armbian we use
for the rootfs which is not optimal regarding power losses. Since I’m testing all the time I try to provoke as FS corruption now since weeks. Until now to no avail.
With a bunch of RPi B+ we use as IP cameras trouble all the time (weekly cronjob tries to restart them and somethings they hang and then OS image has to be reflashed — I really have to look into overlayfs or something like that)
@tkaiser
From the above, is it safe to conclude the problem is mainly a limitation of the Raspberry Pi ?
From the absence of a ‘Power-fail-sense IRQ computer-state backup routine’ in other modern SBCs, can one conclude it is not needed because the SBC is otherwise designed to not corrupt storage ?
And from that, is this protection achieved in the hardware that writes to the storage (like fast inhibit the storage ‘Write’ logic when supply voltage low – which could be smarter than using a big capacitor to hold up Vcc for 10s of ms) or in the OS file-system ?
@paul
To be honest: I don’t store any data of value on SD cards or eMMC (everything important is on an i7 box running Solaris implementing a ZFS mirror and sending ZFS snapshots to 2 off-site locations).
Most filesystems are prone to corruption if you suddenly power the system off, if you’ve to fear that better switch journaling on (then you might experience data losses but at least the FS should be in a consistent state). And if you do so also think about using a more recent SD card / eMMC implementing wear leveling correctly (many people fear wearing their SD cards or even SSDs out since they read 10 years ago what happened back then when a lot of data has been written to flash media)
I don’t know what happens with Raspberries but there the whole problems seems to be hardware related too (no idea, now that it seems we can use cheap Allwinner boards for HW accelerated video encoding soon I’ll probably never ever buy any RPi again). At least I try very hard to get a FS corruption but still ‘fail’ after weeks of trying (using maybe 95% ext4 without journaling and 5% btrfs with default settings with OPi onboard eMMC, Samsung EVO/EVO+ or the more expensive SanDisk SD cards)
BTW: Preventing power losses by using SBC with PMIC (eg. the cheap C.H.I.P. combined with a battery) is also a great option since you can monitor battery voltage (capacity) and initiate a clean shutdown when necessary. And at least with the cheap Allwinner tablet SoCs PMIC+battery compensate pretty well voltage drops on DC-IN that would otherwise lead to freezes or power-off.
@tkaiser
Actually tkasier two others things pop to mind.
1/ The Orange Pi PC Plus cost nearly the same and uses emmc too, is it the same chips, implemented the same way?
2/ It is a pity they could not of squeezed the Bluetooth on to the Orange Pi PC Plus. They would then have a Android 4.4 TV box board with GPIO. ( a long time moan of mine ☺ ).
Where does this IOT board leave the chance of a Allwinner R4O board, from Orange Pi?
I suspect, cannot prove Raspberry Pi problems come from use of USB power and original SOC pushed beyond original design speed.
@tkaiser
The datalogging project is for remote unattended environments with minimal energy consumption where there will be no other computer running, and one may or may not have an internet connection, hence the need to store data onboard in case cloud access not available.
From the Raspberry forums, with the Pi2 having no PMIC it appeared to be difficult to get it to consume much less than 1Watt headless, so recently decided on the ESP8266 based WEMOS D1 mini Pro which has 16MB onboard Flash, and consumes around 1 mA in deep sleep, averaging around 20mW overall, so lending itself to battery backup. I will not know for sure, as I may get no time for developing the project for some months. I saw one of your posts somewhere has done quite a bit of work on measuring/customising Armbian SBC power consumption and had a mind to post some questions on it, but as I have now decided on a much lower power platform using Arduino, your work will not apply there. Thanks for your very helpful advice anyway.
@tkaiser Thanks for the info. Looks like I missed that post. I’m not sure which original board revision I have, but I’ll have to double check. Either way, I heatsinked all my H3 boards just to be sure. Hardly an issue when they have tall USB and Ethernet adapters sticking out of them.
But definitely, the appeal of this board to me is the flatness. I’ll have to check the relevant Armbian forum threads to see how it does before I grab one.
… Ah yes, mine is definitely the older/hotter 1.0 model (ordered well before September). Glad to hear they fixed it, as I was definitely concerned about them as a manufacturer when I first read about the new heat issue.
@paul
Regarding SBC and consumption: the main reason RPi Zero is able to stay below 400 mW (I measured 365 mW when idle) is that there’s no USB hub / Ethernet combo there and also circuitry missing to power USB consumers. On RPi B+ when you neither need USB nor Ethernet (data logging to SD card) you can switch off the LAN9514 chip providing both and end up with ~400 mW less that means 600 mW idle:
On RPi 2 and 3 it’s a different sysfs node and you get the same ~400mW savings: idle consumption as low as 645 mW or 770 mW (no idea how to switch off BT/WiFi on RPi 3 — at least it made no difference:
Small H3 boards like Orange Pi One can be adjusted to consume as less as ~550mW while having USB and Ethernet fully functional (Armbian provides the h3consumption tool to adjust settings) but unfortunately NanoPi NEO with PCB rev 1.0 showed the rather high minimum consumption of 870 mW idle (I hope PCB rev 1.1 fixed that and it’s the same with NanoPi AIR now — TBC). On the larger H3 boards you get idle consumption as low as 1W but on the GbE equipped boards only after forcing Ethernet to 100 Mbits/sec:
Same applies to other GbE equipped SBC too, forcing the often used RTL8211 Gigabit Ethernet PHY to Fast Ethernet saves +350 mW. A Banana Pro for example when used as data logger consumes just 670 mW in Fast Ethernet mode and there you always have full control over a connected disk (manually sending it to standby/sleep with hdparm command which always works since the SoC here has a real SATA port — with USB it always depends on the USB-to-SATA bridge used in the enclosure)
In other words: It depends on the board in question (voltage regulators used for example) but there exist a couple of SBC that are able to operate in the 500 mW area.
Oops, forgot to add: the aforementioned numbers are only valid when using Armbian, it seems other OS images or distro bakers don’t care that much about things like thermal issues and consumption…
@tkaiser
Thanks for further consumption info on Debian type SBCs. Judging from my past reasearch, think your right about others not caring about consumption. When I wrote last post mentioning 1Watt, I had to remind myself of the research I did on RPi2 3 years back before abandoning that idea and deciding on this WEMOS D1 Mini Pro, recently posted in cnx. (If you search my cnx posts since then, you will see I regularly ask for the Reviews to give idle and running consumptions, WiFi Range in hope newer similar Debian based SBCs more interesting). It seemed logical to peruse the Raspberry.org forum to discover this. Although a massive Forum, I found little on it so I registered to ask how one could cut RPi2 consumption right down when ‘idling’ in headless mode for battery operation. The reply from what appeared to be one of the ‘official’ responders, said it took 5 Watts, exceeding even the 1.15W 5V idle figure stated in the nearest site (Raspi.TV) listing Pi family power consumptions !! Seemed suprised anyone would want less. I saw in original v1 of ‘User Manual’ 2012, list of ‘over-voltage’ & ‘frequency’ parameters one could put in a config file, stating one could undervolt and reduce CPU, GPU, & RAM frequencies in defined steps. But nowhere could I find any data on HOW MUCH current/power can save at minimum settings, or if Raspbian would run reliably at minimum settings, or, being 2012, if the settings worked on newer models. As not in Pi forum, spent much time searching other Pi forums for info on consumption, finding similar tips to yours in articles on PiB in high-altitude balloons etc. It became apparent to me Linux (I am not familiar with Linux) is not a good OS for very low power IoT type projects, as it is quite busy in ‘idle’ running all kinds of housekeeping, with danger of SDcard failing due to wear out. Under the usual Pi OS’s it seemed not possible/practical to program a Pi2 to go into low-power ‘deep-sleep’ for the >90% of time it need do nothing, so I started looking for another platform more suited. I hope the WEMOS D1 Mini Pro is it.
I doubt will get time to start my project for many months, but meanwhile am mulling over methods of efficiently powering a SBC to consume 90% of the time, about 1Watt for 2 to 10% of the time. Some questions arise. I bought a WEMOS Battery Shield to automatically recharge a battery when 5VDC available. Its minimum Charge Rate setting is 500mA (2.5W) which I think is OTT for a SBC averaging 40mW, 1W max.
A while back I bought a ‘official’ Pi2 5V 2A Adapter (Stontronics) for general purpose use after reading it was qood quality, well-filtered, high efficiency. I measured wall consumption on no load using a Maplin 4 digit mains-power meter. A high 0.6W, ruled it out as trickle charger for this project. Have you any thoughts on an good 5V mains adapter able to efficiently power over range 20mW to 2.5W ?
If it was not for the Shield’s minimum 500mA charge rate, 1 Watt max or even less may be sufficient, as in worst-case of a discharged battery, it is acceptable the SBC remains unpowered until the battery is a few % recharged.
The Shield uses a ‘TP5410’ chip to control charge current. I can only find a Chinese Datasheet. A link to english version would help. I rather avoid having to do fine soldering, but see the charge current is defined by a single resistor value, so if necessary, I could reduce charge power to 1 W to make sourcing a 5V adapter efficient at 20mW a little easier.
@paul
Just spotted missing text in 2nd para. should read “am mulling over methods of efficiently powering a SBC to consume less than 20mW in ‘deep-sleep’ more than 90% of the time, about 1Watt for 2 to 10% of the time.”. It didnt like me using the < chr for less than.
@tkaiser
Re. your mention of “Armbian provides the h3consumption tool to adjust settings”, I recall reading about that in your forum. Is there an equivalent version for Pi2/Raspbian ? Had I known about that, I would have asked a Pi2 owner to set the Pi2 to minimum power and report results.
Re. your mention of ‘sending it to standby/sleep with hdparm command’ do you know if a Pi2 could be programmed to be put to v. low power sleep (All 4 cores off ?) until, say, a RTC GPIO interrupt arrives ?
If so, then had I learn’t that 3 years back, maybe I could have used a Pi2 for my project.
I was about to comment about how disappointed I was that no Analog Audio In and Out was made available on the board until I looked at their schematics to find out that they are in fact here!
Page 10 on the left hand side bottom corner: http://wiki.friendlyarm.com/wiki/images/9/98/NanoPi-NEO-Air-1608-Schematic.pdf
I believe MicInP, MicInN, LineOutL and LineOutR are the four pads next to the camera connector, which one is which will have to be guessed for now.
EDIT: @tkaiser Should the audiocodec device be enabled and available by default using the Armbian image? Thanks again for your work and the work of the whole Armbian team!
@FergusL
I wonder whether FA also exposed MicInP, MicInN, LineOutL and LineOutR in a similar way on NEO PCB rev 1.1 (since on the 12-pin header now they use I2S instead). But regarding audio details please don’t ask me but better open a thread in Armbian forum. As far as I understand with legacy kernel everything is already there, you might have to tweak fex/script.bin and then adjust a few hundred settings somewhere in the various Linux’ Audio subsystems (I’m always not sure whether I should consider this PITA or just brain-dead).
And BTW: please don’t forget about @jernej — without him and his inofficial OpenELEC fork the whole situation around all H3 boards with legacy kernel would look totally different!
FriendlyARM has apparently made a NanoPi NEO like board with Amlogic S905 processor, but they don’t have enough resources to work on the software side. So it’s unclear whether it will be released or not…
Answers to a question above – no video output – this is not going to be a media player – it’s going to be a controller.
And now my own question – WIFI… I don’t want to use their built in Ubunti – invested too much time getting all my stuff working in Debian (you know, the operating system that real PIs use)… so I popped in my DIETPI LITE SD which works an absolute TREAT on the NanoPi NEO with USB WIFI – but not on this one – everything works – just not the WIFI so I assume the driver is different. This should be a treat with no Ethernet. Anyone any idea how to get the right WIFI driver in there?
Here’s where I am up to now.. http://tech.scargill.net/size-matters-neo-air/
Pete.
@Peter Scargill
Simply use Armbian on devices with onboard Wi-Fi. Worked there even before any of the Armbian devs had an Air in his hands (since AP6212 is used on other SBCs and we’ve already experiences with this chip). Setup is also easy since we provide a serial console through Micro USB port (g_serial module).
Unfortunately FriendlyARM puts an OS image on the eMMC (that is not useful in any way since it can not be accessed). If they would ship with empty emmC Armbian could be flashed in a single step to onboard eMMC, all just using the Micro USB jack.