This morning, a parcel turned up for me from Banggood with a couple of Orange Pi boards inside it. Specifically the Orange Pi PC2 and the Orange Pi Plus 2E. Shame they’d not turned up earlier as Banggood had their sale on over the weekend – oh, well.
Let’s get down to some detail as I open the packages and start investigating.
Regular readers will know I have my reservations about Orange Pi – partly due to lack of support from the design company and secondly as the WIFI on the Orange Pi Zero was and is basically rubbish (though that is possibly down to implementation rather than hardware – others may know better).
First things first – no, neither of these will fit in a Raspberry Pi case 🙂
The Orange Pi Plus2E
This unit is based on the familiar 32 bit H3 chip so no surprises there.
I won’t waste your time with the full specs, you can get that anywhere – important things… it has EMMC (faster than SD) and unlike some boards which only have 8GB you get 16GB. 2GB Ram – which for me should really be the standard as adding a RAMDISK to minimise SD wear can take a chunk out of systems with 512MB RAM.
Other things I like – audio output – so many skimp on this. There is also a microphone and an IR receiver. The unit came complete with antenna.
Three USB 2 sockets as standard. Not keen on the WIFI antenna – but then you do have Gigabit Ethernet.
The Orange Pi PC 2
Based on the H5 chip, this is smaller than the Plus2E both in width and height.
This time it is the 64 Bit H5 processor – which is good and bad – good as it is more powerful, but not the same support as the H3 as you’ll see later. This board, despite it’s greater power has 1GB, not 2GB of RAM and has no eMMC. In both cases of course you have an SD slot.
Again the audio output – again the microphone and IR receiver. As with the first board, this one has Giga Ethernet too – and three USB 2 sockets as before.
Not particularly interested in testing Android on either of these two units – though clearly if you want a media centre out of it, the Plus 2E would seem to be the better bet due to faster EMMC and 2GB RAM.
In neither case is there any support for getting power via the microUSB connection – a right pain in the bum as the power connector they give you is, erm, small – and I don’t have ANY supplies that will fit – however, there’s always the 40 pin connector!
On the Orange Pi site itself there are several operating systems for these boards but then I’ve hever had much luck with their site. I figured I’d try Armbian server software from the Armbian site on both – notably the PC2 version is marked “experimental”.
I took the Plus2E and grabbed the Armbian server image for it. I didn’t see much in the way of startup information but the screen came up asking for username and password after a while. I was asked to change password…. I then had the option to change the screen size. At this point I was on HDMI – and the resolution was poor – I chose 1080p at 60hz. I rebooted. NO build-up information at all which is unusual – but after a while, a green background came up – and sure enough – clear text at the resolution I’d asked for, asking for username and password.
The screen suggested I was using Armbian 5.30, Ubuntu 16.04, that I had 2GB Ram and the temperature was 46c. All of that was in order.
At that point I’d had enough of using a screen and keyboard and went off to get WinSCP running so I could do this from the comfort of my PC – sure enough it worked straight away – and that’s a GOOD thing as enabling remote access for root users can confuse beginners. This just worked. I had attached a little heatsink to the H3 processor – just as well because by now the processor was sitting at 60c.
I went off to try armbian-config which immediately went to get some updates before popping up with a menu. It warned me that the config program runs under supervisor permissions – I ticked the box and agreed. Despite the wrong font setup which meant instead of nice lines around the menu there were a bunch of x’s (no it ISN’T my Putty settings), the menu offered everything I needed to get started.
At this point I noted the ability to “boot from EMMC” – I took a chance – SLOW at 20 minutes to complete – but then – dead easy. When done – the menu options included power off and exit – i selected power off – after a moment the lights stopped flashing, I pulled the power and removed the SD. I re-applied power and…. sure enough – the unit came back up, running from eMMC. The few updates required had by now gone up to 42.
I closed the terminal session and opened again to get stats – sure enough – 16GB of eMMC and 2GB of RAM. I was getting a warm feeling – time to install “the script”. Now easier than ever of course..
wget –no-check-certificate http://bit.do/the-script
bash the-script
This did a quick collection of preliminaries and then told me to log out and in as pi user. The script remains easy…
bash the-script
Something about the screen setup – the script came up with a purple background – yechhh… I set it going and went off to hammer some nails in somewhere. 47c said the display (that’s ok). During installation it rose to 54c, also ok.
So – everything worked ! But there appears to be only one serial port on view – that is ttyS0… and that is used by the debug.
In /boot/armbianEnv.txt – console=both or console=serial
That’s the two options in the Armbian docs… what I want is the other one – ie not serial – what ever that is – anyone any idea? I really would rather have that port free than have debug on it.
I had only one serial port and that was being used for debug – so over at the Armbian blog, two helpful fellows came up with a “solution” – just as I was trying to destroy the board by altering the FEL settings many of which meant nothing to me (and which apparently don’t work on the “legacy” version of the software – which was the one that was staring me in the face).
However, to cut a long story short, in the file /boot/armbianEnv.txt – add this:
overlays=uart1 uart2 uart3 i2c0 i2c1
Well, you could have blown me away – after a reboot, my Node-Red had/has full access to those three UARTS (as well as UART0 still used for debug) and if I need the pins for something else I now know what to do. Also because of the above – the I2c port 0 which had previously shown a UU at location 0x48 and ignored my SSD1306, now worked perfectly and I2c1 was blank (I could probably skip the latter but you never know)….
On 21st of August, realising the RPI-CLONE will not currently work on eMMC-based installations – I put a copy of Armbian onto SD – this time, the latest nightly build marked ARMBIAN 5.32.170921 nightly Ubuntu 16.04.3 LTS 4.11.12-sun8i. The above overlay code also did the same job on this one.
This board gets better by the minute!!!
Meanwhile back on the dark side
Meanwhile I decided to try the PC2 board. That installed Armbian without issue – just as above – and “the script” installed similarly without issue – taking somewhat longer at 42 minutes to install. This time the end temperature (with a little heatsink similar to before) was 48c.
I rebooted the PC2 board and…. nothing – no HDMI output, no winSCP connection – lots of Ethernet activity but no light on the board. I’ve tried the script twice now – I think something in the update/upgrade is messing up the install. I have to say at this point I was not impressed with this board.
I then tried the Debian server image from Orange on the PC2. A red light came on along with the green – and lots of disk activity – but no HDMI output. I really do wonder if ANYONE tests this stuff before they put it on the web. At least the Armbian people said their version was experimental – no such honesty from the Orange website. Perhaps I should have watched MickMake’s video before testing (or even ordering) this board… might’ve saved some time. https://www.youtube.com/watch?v=SWysgpZBzos. The new Debian installation, despite not working on screen did come up on WinSCP – but the stated password (orangepi) would not work.
I took the “raspbian” image – that booted up though there was no HDMI output at all. Whoever tested this stuff should be SHOT. However, the unit appears on WinSCP and the default password worked. I was given an instruction to resize the SD (why they didn’t just do it is beyond me) – I did that and rebooted the unit.
A ray of light – and then the darkness…
Having decided the best thing to do with the PC2 was to put it up against a wall and shoot it having done my own tests, read other people’s tests and having seen some comments on the subject , I made what would appear to be a bit of a stupid move and took the image off one of my other H5 boards (Neo Plus2) which worked perfectly with I2c, GPIO, Node-Red, Grafana etc etc etc… and after making a back-up (in case the SD didn’t survive) – decided the worst that could happen by plugging it into the Orange Pi would be an explosion as the chip came flying off the board….
And guess what – it worked PERFECTLY including I2c and serial. Same SD, same power supply, same board, same conditions… but – with no HDMI out – I was concerned – how reliable was this going to be? I tried serial ports on Node-Red and at one point the board rebooted on me mid-operation. I then tried another SD – same code – this time it would not even start up (but it was an older SD) – maybe that has something to do with all of this – maybe it needs SDs that are so fast they don’t exist yet – the first one I used was a Sandisk Ultra – you would think that would be fast enough…
The H3-based Plus 2E is fine – someone will tell me how to sort out the uart 0 debug thing (could it be you?) meanwhile I have three more serial ports to play with. Lovely
But back at the P2, there is something seriously wrong with this board (and it is not the H5 because my NEO Plus2 boards are just fine). I discovered that, by replacing my battery pack with a decent power supply, I could get the HDMI to work reliably – now bear in mind that this SAME battery supply has worked utterly reliably for loads of other boards. I also found that an older Samsung HC SD would not boot up AT ALL – so unlike other boards I’ve tested (and there are many) this P2 is sensitive to power AND to SD. As power affects SDs – my money is on the SD interface. If it would just work reliably and not keep throwing up memory errors I reckon it would be just fine on that FriendlyArm image.
This information I gleaned didn’t help me a lot – but it may be of some use to others. The Ubuntu image from FriendlyArm for the FriendlyArm Nanopi PLUS2 appeared to be working a TREAT on the P2 – when it works. It was fully updated, I had Node-Red, Apache, Grafana, HaBridge, Mosquitto and other items all running – and after removing changing the debug line in the boot to console=tty1 (missing it out causes all manner of issues) instead of it referring to the serial, I now had full access to ttyS0 and ttyS1 in Node-Red along with I2c.
However, next time I booted up, sure enough, a bunch of memory errors appeared. Do we really need this hassle? No. I have a pair of NEO2s running 24-7, same with my NEO+2 boards and a Raspberry Pi.
Conclusion
This P2 board seems to me to be WAY too picky and just plain unreliable – the images out there for it are rubbish – but the FriendlyArm image seems to be the business – if only the board would not keep throwing out error message on power up and occasionally when running – could it be there’s a setting that needs to say “use slower SD” ?? I don’t know but I’ve spent too much time on this.
But the Plus 2E – with 4 UARTS, 2GB RAM and 16GB fast eMMC… depending on what you are doing – gives Raspberry Pi with it’s only-one-uart-shared-with-bluetooth nonsense a run for it’s money at something like £8 more…
Of interest
Not directly about the Orange PIs but while I was struggling today, I learned about FEX files… essentially a compiled file with info about what’s enabled etc… a fellow called Martinayonette answered a query of mine..
Here is a FEX Guide : http://linux-sunxi.org/Fex_Guide
In summary, you need to first do a backup of /boot/script.bin, then decompile in with “bin2fex /boot/script.bin > /tmp/script.fex”, then edit the /tmp/script.fex to enable other I2C or UART, and finally recompile it using “fex2bin /tmp/script.fex > /boot/script.bin”
That is useful info to know if you’re stuck with trying to change a board but it seems it does not work with earlier images – like the one I’m apparently using as I chose “legacy”.
Having said that in this case (PLUS 2E) all I needed was that one liner in the ambianEnv.txt file and a reboot to end up with a board that really – is not bad at all.
Yes you’re right about Pi Zero. Just having interrogation about stability..
What is the script u’re using? (the link has probably drop somewhere)
Thanks again for this reading : I probably will less loosing time!
Pretty hard to miss – THE script.. see right hand menu…
Of interest, if you want to try this – install the script – Mosquitto is all setup for you with the username (admin) and password you pick at setup. It is at port 1883 and needs no configuration at all – ready to run.
correction : not sure routers for less than 20€ have enough memory for mqtt !
But routers are not the answer – ANY of the current boards you’ll see I’ve tested will handle Mosquitto the MQTT broker – in my script it is a standard installation – so you could presumably use the little NEO DUO (review coming soon) or a little Orange Pi Zero (I’m not sure I’d recommend using wireless for the broker but if you insist you could even use a Raspberry Pi Zero WIFI) for this..
So for me – the only reason I’d find this interesting is the idea of a £3 MQTT broker IF it would handle 20-30 clients without issue – otherwise it’s a none-starter.. Thinking about it – as this IS WIFI only being an ESP8266, the Orange Pi Zero WIFI would seem to be a direct competitor – and one which could simultaneously not only run Mosquitto broker – but also Node-Red, Apache and much more – indeed it has done as my script works on it – granted, not that quickly.
See other comment – router for mqtt completely the wrong route – a Raspberry Pi Zero WIFI would beat any of this hands down with Mosquitto – personally I’d be more inclined to the Orange Pi Zero as it also has hardwired Ethernet. See other comment.
for me, a central controller needs to be hardwired… i was thinking at the espressobin but want to wait to see how it evolves in sw…
Thanks for your points 🙂
I’ve also around 12 esp boards connected. And I can easily virtualisate mqtt clients to see how the esp will reply to.
I was talking to a collegue today about mqtt server, and he points me to openwrt.. I forgot that possibillity : cost of wifi router is <20€ (included power supply), so less than rpi..
I will try to test both solution more or less in parrallel
yes, more or less the same..
for me, mqtt is ok but node red is slow on RPI (perf are better using Bluemix in Texas compare to local network)
I’ve also cost problems with RPi (not so low cost, considering all that is not integrated)
my IoT are wemos compatible based
Next week, i’ll test mqtt SERVER on esp8266 :
https://github.com/martin-ger/esp_wifi_repeater/tree/uMQTT_broker
Hi Clys
I think that link was outdated – the current link for the MQTT Broker is this – https://github.com/martin-ger/esp_mqtt
The old one didn’t support username and password (which would immediately stop me using it) – it sound GREAT but… it says that it does not support many MQTT clients) – the whole point of a broker is to connect several clients together.
I think I may have maybe 15 ESP8266 boards on at any one time in here and a couple in England that talk to the broker – so for me I’d want to see a broker that could easily handle 20 clients….
The description actually says “This program enables the ESP8266 to become the central node in a small distributed IoT system” – well, if it’s going to do that we need exact clarification as to how many clients it can be a central node to… and right now it is looking like it supports – maybe 8 clients – really – that just isn’t enough for any but the smallest of systems.
Hello Pete,
Thanks a lot for this review. I was more or less looking doing the same .. Last week, I’ve check armbian status for all compatible card and low cost product don’t seems to have a good compatibility for now 🙁
It’s fun to see our parrallel work… Probably lot of other are doing the same..!
So currently raspi still the solution for (not so) low cost internal mqtt + node-red server . For my own need (not professionals ones), I’ve switch to cloud solution (Bluemix IBM) for 0$- (free!) around a year ago. Except few problems and instability in June (a full reinstall of nodered has been needed), everything is OK
I’m finding the RPI to be a tad slow as my stuff grows and will be looking to boards with 2GB RAM, hence the interest in the Plus 2E.
Hi Peter,
The Armbian devs are doing a great job of improving Linux under all these “unusual’ SoCs. A united front is what it takes to deal with the lack of support from hardware vendors. As I mentioned in my YouTube comments; the software, hardware, marketing and finance guys all have a very different mindset. When you come across a “hardware company”, my money is down for the software support being terrible.
BTW, The recently released Linux kernel 4.13 will start to improve things greatly for the ARM based SBCs.
Pete, the eMMC on all these Xunlong boards is way faster than those used by most other SBC vendors (Hardkernel being one of the exceptions). FriendlyELEC for example shows write rates of just 7.5MB/s while even on the smallest Xunlong boards ~40MB/s are possible.
Anyway wrt software and general support there’s nothing to argue. Vendor offerings simply suck totally.
Well. no-one can say I didn’t try with that Orange Pi P2 – I had serial, I2c and a whole boatload of programs running – yet despite using a decent supply and decent SD, I just cannot trust it to come out of reset without some issue or other – SOMETIMES it works perfectly – so I don’t see how that can be software – but then – I’ve been wrong before. I’ll go back to playing with the Orange Pi Plus2E – and if anyone can help me resolve my serial port issues I’d appreciate it – everything else seems to be fine. Even just stopping S0 from being used for debug would help. I can’t seem to do that (despite stopping it no problem on the H5 board).
To get more than 1 serial on the Plus 2E you might need to fiddle around with script.bin. I’ve to admit that I’ve moved away from the old kernel long ago so no idea what has to be adjusted.
With mainline kernel Armbian now has ‘device tree overlays’ and at least activating UART1 and UART2 should be easy: https://docs.armbian.com/User-Guide_Allwinner_overlays/#overlay-pinmux-conflicts
But I can’t recommend switching to mainline kernel right now either (for my use cases — OMV/NAS — it’s already sufficient). We switched just a few days ago from 4.11 kernel to 4.13, still a lot is work in progress but I would expect asking in a month over at Armbian forum would yield results how to get everything working with the new kernel version FriendlyELEC already uses on their OS images.
Hi there
A couple of guys on the Armbian site put me right – after I wasted time messing with the FEL settings – how I didn’t blow the board up I don’t know – anyway as you can see in the updated blog it was just a one liner to add to the env file – and I have all the ports running a treat.
Now, I2c is another matter. I2c0 seems to be at pins 3 and 5 on the connector (not unusual) and I can see with i2cdetect -Y 0 – but I cannot see my little board at location 3c as I would normally…
Ideas?
Hi Pete,
I’ve been running a couple of OrangePi +2E boards for a while now and found the internal storage and the 2Gb of RAM very useful indeed. I’ve certainly no complaints about them other than the price making them slightly less easy to justify as an R&D toy bought because I like tinkering (which is what so many of my SBC collection start life as!).
I’ve got one running Android and another running Ubuntu and the 2Gb of RAM means that they’re even quite useful as a desktop replacement for basic tasks (if my main PC is tied up doing stuff). Android/Linux desktops on 1Gb SBCs have always been a bit strangled so the extra RAM on the +2E is very welcome. I imagine it’s pretty good for server setups too, especially if you’re running an application that requires a big mySQL database or something else that gobbles RAM.
I’d not dabbled with the GPIO/Serial side of things on the +2E as I wanted them just for basic server / emergency desktop stuff rather than anything IOT or fancy. It’ll be interesting to see how you get on longer term, but I was impressed.
I’ve also got one H5 processor Opi Zero but I’ve not done anything with that as I was waiting for better Armbian support (and something to do with it – I’ve got quite a few ‘spare’ SBCs now so need to stop buying them as they come out.
I rushed into buying an OrangePi 2G IOT but every time I’ve checked, there’s too much still not working so I am waiting for those more technical than me (i.e. Armbian) to fix the basics before I’ll risk frustrating myself with trying to do anything with it. It may just end up as an ornament.
Ornament – yes, that about sums up the P2. I thought I had a FriendlyArm ROM running on it – but unless I just picked a bad SD (I’m trying another one) – it just works when it wants to – which could indicate that the actual board isn’t as solid as it might be… working on that….
Hi Pete,
I think i’d be inclined to agree with one of the earlier comments that it’s best to avoid ALL of the H5 based OrangePi boards for the time being. That’s the thing with these chinese SBC manufacturers, they keep pumping out variations on a theme, new boards every month without much care about documentation and support. Idiots like me keep buying them though. I’ve stopped now as I’ve found that the H2+/H3 Orange Pi Zero/Zero Plus are fine for small form factor stuff and the Orange Pi One/Lite are good for RetrOrangePi emulation and the PC+/+2E are good as RPi 2/3 replacements. Can someone tell Shenzhen
Xunlong to stop randomly pumping stuff out now as the market is pretty saturated and the OrangePi range itself is overpopulated and confusing to all but the keenest eyed observer.
FriendlyARM are nearly as bad for releasing too many boards and not sticking with any one model for too long and I have mixed views of them. Their earlier boards were bad for overheating (worse than OrangePis – Armbian fixed that issue with some software settings pretty quickly).
My NanoPi NEO2 crashed the other day and won’t boot back up in Linux (may be related to the update issue you posted the other day?).
I’ve got one of my two NanoPi K2s in casual use running Android and that seems okay – I want to see how well my ‘spare’ K2 runs Linux and compare performance to the Orange Pi +2E to see which is the best 2Gb RAM SBC to use for Home Automation etc when the 1Gb limit of the Raspberry Pi2/3 becomes a problem. I’m guessing the K2 as its 64 bit but it’s not always as clear cut as that. There’s certainly a market for a reliable, sensibly priced, 2Gb+ SBC and there seem to be a few appearing now…
Hi Darren,
What ROM do you use on the NanoPi NEO2 board? If it’s from FriendlyARM, you can send your feedback to the tech support email(techsupport@friendlyarm.com), If not, We have no way since we are not that developer.
We took the reasonable suggestion and made better board, As you said, the old version NanoPi NEO is too hot, and we changed it better, surely we don’t make the old one any more. We have sold the Mini2440 board for 10 years, no any change.
Thank you
Mindee
Hi Mindee,
It’s the FriendlyARM Ubuntu image but I’ve not investigated the issue at all yet as I I was only running the Neo2 as a test server so it’s not been a priority for me to follow up yet. The Neo2 was fine until a routine “apt-update” was done and a reboot so it’s most likely a software conflict following the update. If/when I get chance to investigate further, I’ll liaise with Tech Support with my findings.
Thanks
Darren
an image is fine if you can safely update it, you don’t have to be forced to stick with what they give you in first place… and nothing is blocking friendlyarm to release updated images, if they want to… always with the possibity to update them, of course…
I’ve been testing the Orange Pi Zero Plus 2 H5 (among many other Orange Pi boards). It appears that the H5 CPU is poorly supported by Allwinner/Orange Pi. Linux support is quite shaky and is missing support for much of the hardware. I’ve mapped the GPIO ports (no documents available), by manually testing them one by one. It’s currently sitting in the “drawer of shame” because it’s such an awful device. I think both Orange Pi and Allwinner share the blame for the poor support of the H5. Until things change, stay away from all H5 boards.
Well Larry I would tend to agree with you given the horrendous experience of the Orange Pi P2 but for one thing.. I have a pair of FriendlyArm NEO Plus2 boards sitting here running on my desk with GPIO, I2c etc and they are absolutely working a treat.
I think your other comment more closely resembles my thoughts “poorly supported by Allwinner/Orange Pi. None of the images on the Orange Pi site seem to work properly – I tried the “Raspbian” image last night – aside from no HDMI output that seemed fine – but this morning it was still sitting running my install script. I think I’m going to put the P2 board up against a wall and shoot it.
Allwinner’s own software offerings for H5 are horrible. They don’t even get voltage regulation to work and that’s why the Orange Pi / Xunlong OS images all limit cpufreq to 1008 MHz and why FriendlyELEC’s NanoPi NEO2 has no voltage regulation at all and is limited to 912 MHz cpufreq max.
Back in March we were talking to FriendlyELEC about some issues, I mentioned that voltage regulation with community developed mainline kernel works and encouraged FriendlyELEC CEO to give their developers some time to become familiar with mainline kernel. They did, they discovered that they now can create boards with better voltage regulation (higher clockspeeds), stopped two devices to redesign them (NEO Plus 2 and M1 Plus 2) and dropped the crappy Allwinner software completely using their own mainline kernel fork.
Since mainline kernel is a moving target Armbian declares H5 support still experimental even if we had OPi PC 2 running with this kernel almost one year ago. Hopefully this will change soon since with 4.13 kernel and most recent u-boot version a lot stabilized and community did also a great job to write graphics drivers from scratch.
But it will still take some time until these H5 thingies will be ready from an end user perspective if you’re not already using FriendlyELEC OS images (though those are working only headless now since they stay at kernel 4.11 and ignored everything that happened since then)
found this on OPi forums, try these couples:
orangepi orangepi
root orangepi
debian debian
the barrel connector (which i prefer on microusb, as it has better connection and stability) is a 4mm one, typical of the “psp” console 🙂
i got a couple of these adapters a while ago and use with the “oranges” and a couple of other boards:
https://it.aliexpress.com/item/10pcs-DC-Power-4-0-x-1-7mm-Male-Plug-to-5-5-x-2-1mm/32683044712.html
about the “android” path as mediacenter, i stay on my thoughts: nobody has to buy these boards (to which you have to add an sd card, a box, a power supply, an heatsink and an unsupported distro) to use them as such, unless he has GOOD skills… a tv box costs less than the sum of the items i just wrote, has a proper remote, and works way better…
other use is for retrogaming, where thanks to “retrorangepi” these boards are quite good… 😉
If anyone wants to use Android on Allwinner H3 devices then he should look here: https://h3droid.com
Community (Armbian) kernel, sane settings (both wrt performance and thermal issues), easy installer, no shitty tools needed to write the image 🙂
That’s useful to know – thanks!
Orange Pi PC2 also have Gigabit Ethernet.
Suitably corrected…. I’m just busy setting it up now having come to a halt with the serial port on the Plus 2E
whoaaaa fast !!!
Nice to read about your troubles and success with Orange Pi hardware.