It’s been a while since I checked out the Raspberry Pi, as my fleet of original Raspberry Pi Model B, B+ and Pi 2 Model B’s have all been working well doing their little jobs around the house. I haven’t really felt an inclination to upgrade, despite the original Pi feeling a little dated and underpowered, as for single-purpose jobs, they are more than enough.
However, rather surprisingly, the Raspberry Pi Foundation never seems to stop and incremental upgrades come rather quickly. In February this year, they launched the third iteration of the Raspberry Pi – namely the Raspberry Pi 3 Model B. This unit replaces the Raspberry Pi 2 Model B, and offers a faster 1.2Ghz 64-bit quad-core ARMv8 CPU and built-in 802.11n 2.4Ghz Wireless LAN and Bluetooth 4.1 + Low Energy capabilities while retaining the same footprint, I/O and RAM for a very similar price (AU$55 excluding GST at the time of writing). Getting more Pi for your dollar is a nice thing, especially when it remains software-compatible, and the inclusion of wireless eliminates one common USB-port-hog and means it’s very much ready for easy IoT deployment out of the box.
Thanks to element14, I have finally managed to get my hands on a Raspberry Pi 3 Model B to gawk at, put it through its paces and play around with.
As with other element14-supplied Raspberry Pis, this one comes in a matte colour print cardboard box. Along its spine, it is familiarly raspberry-coloured with the logo and brand.
The design changes subtly for each model, and in the case of the Pi 3, it looks rather plain with a more “muted” raspberry. The front has logos for Wireless LAN and Bluetooth, and the rear has the appropriate regulatory approval logos including the Australian regulatory compliance mark (RCM). Getting such approvals for wireless radios can be a rather expensive and long process, so having this integrated would have probably been a big step for the Raspberry Pi Foundation to accomplish. That being said, I’m not sure if this has the full Wi-Fi Alliance “blessing” as it doesn’t carry that logo, although I’m sure most people wouldn’t really care as long as it interoperated just fine as that might just add to the cost. This particular unit is Made in China, which seems to be along the lines of the recent Pis and a little disappointing for the UK perhaps.
Inside, the main PCB is wrapped inside a static shielding bag, with a folded safety guide and quick start guide leaflet. Just as with the other Raspberry Pi models, the rest of the components are an “optional BYO”.
The board retains the familiar footprint and I/O layout which was standardized in the Raspberry Pi Model B+ era. This means size compatibility with cases, as the jacks are all where you’d expect them to be. A few things have changed though:
- Placement of the power and activity LEDs is now near the bottom left corner, meaning the holes and or light-pipes used in Raspberry Pi B+/Raspberry Pi 2 B-era cases will now instead be facing the Wi-Fi/Bluetooth on-board chip antenna. This is a minor inconvenience, as it just means the status lights may not be visible from the outside without drilling a hole. In the case of the official Raspberry Pi case, the red LED is visible through the plastic, but the green LED is not. Clear cases don’t have to worry.
- The run/reset header has been moved from near the top left to the top-mid-right just behind the USB connectors. This is likely because that area is now dedicated to RF-componentry.
- On this board, the HDMI, USB and FFC connectors have been changed to different units – I can’t say whether there is any meaningful difference, as it should be functionally identical.
- The Raspberry Logo has moved from near the DSI connector to above the CPU, and gotten marginally smaller. The board now carries an FCC ID, as it has a radio on board.
- The SoC is now a Broadcom BCM2837, a faster 1.2Ghz 64-bit quad-core ARMv8 CPU as opposed to the BCM2836 900Mhz 32-bit quad-core ARM Cortex-A7 CPU used in the Raspberry Pi 2 or the BCM2835 700Mhz 32-bit single-core ARM11 CPU used in the original Raspberry Pi series.
On the underside, there are a few differences as well:
- For one, there seems to be a lot more test points scattered around the place, with some pads tinned and others not tinned.
- There is a new bare silicon-chip mounted onto the board which is likely to be the radio IC. Purportedly, it has FM radio capabilities which are not allowed for in the Raspberry Pi design.
- The board manufacturer has changed from KCE to JX.
- The microSD card slot has been changed from a “push-push” type with springy eject to a friction fit slot. This might have been a necessary cost-reduction measure to make everything “fit” into the budget. It’s not likely to make a big difference to most users.
The power comes from a microUSB-B connector as before, although in the case of the Pi 3, they claim a maximum power draw of 2.5A rather than the 1.8A claimed in the Pi 2. This is a little confusing to me, as most microUSB-B connectors are only specified for 1.8A, so maybe it’s just pushing the limits ever so slightly as a way of noting the increased power draw of the SoC while allowing for equivalent downstream USB peripheral loads.
From the other sides, not much as really changed, save for the positioning of the LEDs and chip antenna in this model. The chip antenna seems to be made of a metallized spiral deposited on some sort of dielectric core.
A side by side comparison with the Pi 2 shows the many similarities and few differences.
It’s been a long time since I’ve had to set-up a Raspberry Pi from scratch, so I headed over to the Raspberry Pi Foundation’s site to grab the latest Raspbian Jessie (Lite and Full) images. It’s also good to note that some of the OSes made for the Raspberry Pi 2 have been updated for the Raspberry Pi 3, so really it’s only the original Raspberry Pi that misses out on Ubuntu Mate, Windows 10 IoT Core, etc.
So many nice things have happened since I last used it – for one, it seems the image auto-expands to the size of your SD card on first boot. As usual, SSH is open from the beginning so a headless install is simple and only needs for you to ssh to the user account pi with password raspberry on the IP it has been assigned. The reminder to run sudo raspi-config is no longer there, but the tool still works and gives a few new options.
For one, you can now enable a VNC server without all the fuss of setting your own x11vnc server up from scratch or dealing with Krfb quirks.
You can also set the Wi-Fi region setting for compliance with local laws, specific for the Pi 3. Of note is that overclocking the Pi 3 through raspi-config is not supported and comes up with this message.
More options in regards to how it boots up, including waiting for network, auto-login, console-or-desktop really makes things easy to set up. Some things are still best done through manual editing of the /boot/config.txt. For example, I set a fixed framebuffer size of 1920×1080, since I would be exploring the graphical desktop via VNC instead.
Because the included VNC server came from RealVNC, and the UNIX password authentication method and encryption was not supported by my other clients, I had to use RealVNC to connect the first time.
After first setting up the connection in the main window, and then attempting to connect, I’m prompted to verify the identity. Because I didn’t know the specific signature, but I trusted the network I was on, I proceeded.
I was quite impressed, however, by double-clicking on the icon, we can configure the server to improve its compatibility with other clients (at the cost of security – the loss of encryption and UNIX user login support).
Configure the Authentication from UNIX password to VNC password, then navigate to Users & Permissions and set the VNC password.
Optionally, you can also configure the other tabs to stop serving the Java/HTTP VNC viewer (connect with port 5800, no software needed). Whatever you do, don’t enable the direct capture method as it will result in screen geometry issues. I did it, and I had to use a physical USB Keyboard and Mouse to recover.
The main attraction of on-board Wi-Fi worked just a treat. Clicking on the network icon allowed us to view the nearby Wi-Fi networks. The signal strength appears slightly lower, due to the chip antenna being less optimal. Clicking on a network and providing the necessary authentication key allowed me onto my home network without any hassle at all.
The connection obtained was probably more solid than that achieved by using the Wi-Pi, and it doesn’t hog any of the USB ports or use any USB bus bandwidth as far as I can tell. The fact it is integrated is a big boon for IoT users as it means that it can get to the internet without any wires or hassle, so pushing sensor data to the cloud is no big problem at all. I can even run remote VNC desktop which is somewhat bandwidth heavy with no real issues either. Big tick of approval!
The fun doesn’t stop there, because the radio also has Bluetooth 4.0 with Low Energy support. This means that those using BT-LE sensors for data can use the Raspberry Pi 3 as an IoT gateway, extending the reach of their Bluetooth devices.
Consequently, if you’re feeling like a little challenge, you could even use the Bluetooth link to talk to speakers/headsets for an audio output. This is normally a difficult task as support can be somewhat flakey, but as I demonstrate with connecting to my Xiaomi mini speaker, it worked a treat! To activate it, it’s as simple as right-clicking on the speaker icon and choosing the Bluetooth device as the audio output device.
The default browser is now Chromium, so none of the old Epiphany “scaled back” browser stuff of the old days, and the performance is better than expected. It’s no desktop replacement, but it’s not a test of patience as it once was. I was able to play Rainy Mood over the Bluetooth speakers (with an occasional resampling crackle), so that was unexpectedly smooth!
CPU usage was also quite low, showing there’s a lot more ability up the sleeve of the Pi 3. Youtube was a bit of a stretch though, and the Bluetooth audio driver seems to crash-out to silence when overloaded necessitating a reboot to restore its functionality.
However, most of the time, the Bluetooth is most useful for attaching keyboards and mice wirelessly (e.g. home media center usage) or reading sensor data, connecting to Bluetooth serial devices or performing small file transfers, which really makes this Pi work in many places with “just power” connected.
Hot & Thirsty Pi: A Stability Problem?
The Raspberry Pi 3 has developed a bit of a reputation of being “a bit hot” and needing a little more power. However, in return, you get more peripherals and more performance. I wanted to see just how much more you get, so I tried to use it a little more heavily and run some benchmarks.
The honeymoon was indeed sweet but shortlived, as after some rather intensive usage, I found that the Pi would hang and sometimes never come back after a power cycle. The microSD card would be trashed, and I would have to reimage it. A closer look showed that the power LED would flicker, indicating a short power brown-out despite being run on numerous 5V/2A and 5.2V/2A supplies which had no problems with an overclocked Pi 2 and despite not having any USB downstream peripherals on the Pi 3.
Trying to exacerbate the issue, I tried to run some stability checks, with HPLinpack being the one favoured by most. Unfortunately, this is where I began to discover some real stability issues with my Pi 3 board. Using my Blackberry 5V/2A supply, running HPLinpack was a problem. It would flash the power LED indicating brownout, while also crashing after a few loops resulting in an unresponsive Pi. Knowing this power supply was good with the Pi 2, I decided to investigate further.
With my oscilloscope, I measured the power rails at the back of the USB connector pins (B) and at the GPIO header (A). Indeed, during heavy processing in HPLinpack, the power supply to the board is browning out but only so slightly as to just trip the supervisor chip. It doesn’t brown out so far as for me to be necessarily concerned that the CPU isn’t receiving enough power.
Zoomed, we can see the deepest dips didn’t really go below the 4.5v level, so I presumed the blinking is more a sign that the peak current draw of the CPU might be rather extreme, and maybe its own supply rails is having trouble handling it and the resistance of the polyfuse and connector contacts may not be helping.
My overclocked Pi 2 (1000Mhz core, 500Mhz SDRAM) attached to the same adapter and tested with HPLinpack showed no such issues, with the supply being a steady and almost perfect 5V.
Such instablility at load and blinking of the power LED suggests that the Pi 3 is even more picky about power supplies than ever before. The original Pi with the linear regulator was a bit of a thirsty device, but since switching to a switching converter in the + series, the consumption was tamed. If anything, I wonder if they’ve been just a little too ambitious in putting more into the same envelope.
Changing over to my Xiaomi 16000mAh power bank with a slightly higher output voltage did allow me to finish the HPLinpack benchmark, just once. Rerunning the benchmark straight after resulted in inconsistencies, indicating computational errors. The SoC was also extremely hot. Conscious of this, I tried to give the board the best chance by leaving the case open in an air-conditioned 21 degrees C room.
The throughput was 3.6GFLOPS, or about twice the 1.7GFLOPS I got from my best overclocked Pi 2. More performance, but stability is an issue. Reasoning it might be heat-related or power-related, I decided to blow on the SoC while I ran another test.
The unit ended up passing the test with me blowing on the SoC, which was a surprise, but the speed of the chip was still much the same at 3.6GFLOPS. As a result, it seems that the problems may be a combination of both power and heat. Having a decent heatsink fitted is definitely advisable for those doing heavy computational work to ensure stability, and a well ventilated case may indeed be a good idea.
Even where the Pi 3 didn’t crash in the HPLinpack tests, I found occasions where telltale corruption has happened somewhere, including HPLinpack refusing to run after a reboot, .tar files not being able to be untarred, and commands quitting due to Illegal Instruction or module linking issues.
As it turns out, this problem doesn’t seem to be an isolated one, with some other people on Raspberry Pi forums noting the same issue.
A Fix to the Problem?
At this point, I was in two minds. This was one of my favourite Raspberry Pi boards to date, but if it’s not stable, it can’t be relied upon and that defeats its whole purpose. Do I try to fix it myself, or do I (hypothetically) return it and get another which may or may not be just as problematic.
Of course, as an engineer, I decide that I might as well fix it on my own as best as I can. It’s a review sample, so I’m not really eligible for a return anyway, and I don’t like taking the chance on swapping for something else that could be nearly equally bad.
Note: The following information is provided as a log of what I have done and the experiments I have run. Attempt these fixes at your own risk. I will not be held responsible for any damage, direct or consequential, as a result of using or misusing the information provided including voided warranties. You bear all risk in regards to your actions.
I started off by underclocking the device to try and assume stability. Knowing that the power consumption scales close to linearly by frequency, reducing the frequency should help give that extra margin and reduce the power consumption.
In all, I had to underclock to 1000Mhz and add an overvoltage of 2 to assume stability. Without the overvoltage, I was finding strange corruption was occuring. This can be achieved by editing /boot/config.txt and adding:
But this did not seem to me to be the optimal course of action. For one, even at this setting, I was getting LED blinks during processing, and I was sure that something else may have been “sabotaging” the power supply. This situation would have only been borderline, as a change of USB power supply or an increase in downstream peripherals would probably “change” the power budget just enough to bring back instability.
Perform the Following Modifications at Your Own Risk!
I can’t say that these modifications are new, or that they will necessarily help, but the first thing that came to mind as being potentially problematic at high peak currents is the polyfuse. A common offender in the original Raspberry Pi days, a remedy is to remove or bridge it out entirely to save the voltage drop that could occur over transients.
This is best done with a hot air gun, a set of tweezers, a header pin and some solder. This modification can potentially compromise safety in case something does short out, as there is no longer current protection on the board, and the upstream protection from the power source is being relied on.
The next point of contention was the USB socket, as I found the solder a bit thin which may impact on the mechanical rigidity as well as the pin conductivity. I reflowed and added a tiny bit of solder to the first and last pin, as well as the shell, hoping to gain a few milli-ohms.
I’m not sure this was entirely necessary, but I was voiding the warranty on the Pi 3, so I might as well go all-out.
The difference was rather interesting. No longer did I have any LED blinks when running at 1000Mhz (2 overvolt). I couldn’t run at full-stock 1200Mhz speeds without LED blinks though, so underclocking still seems to be the key.
Now, I felt that I could push the boundaries further. I couldn’t get 1100Mhz or 1050Mhz stable under any circumstances, but at 1000Mhz, I could begin undervolting significantly to save energy and heat. The reason for this will become apparent shortly.
Trials with undervolting allowed for the setting to be dialled down to -5 without instability, failing the tests at -6. As the power consumption generally has a quadratic relationship with voltage, any reduction in voltage means significant heat and power savings, which should improve the power budget.
I then overclocked the SDRAM to 550Mhz which was stable, although at 600Mhz, it would boot but lock-up fairly quickly. I didn’t feel it was worth pushing the SDRAM with custom schmoo settings or overvolt settings, so I left it there.
The reward with the casing still off was amazing – we achieved an HPLinpack speed of 5.304GFLOPS, followed by 4.753GFLOPS, 4,482GFLOPS and 4.271GFLOPS on consecutive runs. This is not a typo. Underclocking the SoC and undervolting the SoC allowed it to pass HPLinpack repeatedly and produce a faster result than at the stock settings where it could only pass the test just once at 3.6GFLOPS.
Confident with the result, I decided to shove the case on, to really “cook the Pi” to see if it would survive. Interestingly, it did.
The performance fell rather sharply as the Pi 3 heated, but then flattened out achieving about 3.3GFLOPS in the thermally difficult environment. Rather interestingly, this is not much less than the one stock run I could get, and still pretty much twice as fast as the Pi 2. Now it’s stable, and I didn’t even put on a heatsink, although I probably should.
It also points to some thermal throttling behaviour that I couldn’t resolve by monitoring clocks and temperature alone. I couldn’t see the throttling, but its effects were there. The 3.3GFLOPS run was with the case on, the subsequent 5.7GFLOPS run was when I took off the case and blew on the SoC throughout the benchmark.
My config.txt lines now have
arm_freq=1000 over_voltage=-5 sdram_freq=550
The Raspberry Pi 3 is the best Pi ever, featuring even more performance, newer more modern 64-bit CPU and instruction set, with integrated Wi-Fi and Bluetooth capabilities. It makes it an excellent candidate for IoT applications as a hub for Bluetooth sensors or devices, or as a direct reporting platform connecting over Wi-Fi, requiring only power. Its price is fairly similar, and it has the same footprint allowing for older cases to be reused. The software has also improved, and setting up has become a little easier than before, which I am glad to see.
It does seem, however, that they may have been a little too ambitious in pushing the envelope and the unit appears to run into power and thermal constraints under high-stress loads. These are not that common, however, it would be nice to see it be unconditionally stable to avoid any chance of failures in the field.
A home remedy is to underclock and undervolt (where possible) with-or-without modifications to the board. It is also advisable to use a good heatsink and thermally conductive adhesive, and a more “open” case for ventilation to maintain error-free performance. Maybe they should begin shipping them with the boards as a low-cost way of maintaining good performance?