The best way to look at the Razzie is to paraphrase the infamous quote about Democracy which is usually attributed to Benjamin Franklin. Raspberry Pi sucks, but we have yet to come up with anything better. Though this is not entirely true. From the very beginning of the Pi mania Beagle Board and more recently LeMaker BananaPi series SOCs have proven to be significantly better than their Raspberry equivalents for most Pi use cases.

Raspberry's obvious advantages are cost, ubiquity, availability of pre-integrated designs and tutorials. It also has quite a few downsides (something its fandom hates to admit).

Setting things straight - the downsides

Limitations of the Closed Source Firmware

The RaspberryPi is not open source. As a matter of fact no Arm SOC is. The only truly Open Source SOCs out there are some of the MIPS ones. Arm ones - not so much. RaspberryPi is just one example. In order to boot it you need to load a couple of MEGABYTES of binary closed source Broadcom firmware. That by itself disqualifies any of its claims to Open Source fame. While most of the SOC and spec is now reasonably well documented because of so many people working with it, some of the internals remain proprietary and closed. This is a reality of life, no point to scream, shout or claim things that are simply untrue. It is not an "Open Source Computer".

So, does this affect us in any way. Well it does. There is are a couple of key features which are strictly under binary firmware control. One of them is power management. While the SOC can run at nearly arbitrary frequencies (for Model B+ and Model 3 - from 300MHz to 1200MHz) you can only run it at two speeds - slow (cool) and fast (hot). You cannot do any sane power management. Even a small load throws it into overdrive and in the case of Model 3 it starts running quite hot. Similarly, the load has to drop to virtually zero in order for the Pi to go back to the lower frequency. If we compare this to, for example to Mediatek, Exynos or modern low powered x86 chips, there you get 4-6 and sometimes even more frequencies to play with allowing for much better power consumption and more importantly - much better thermals.


The USB on the Pi has been buggy since its inception and the days of the early Model 1 and this has not changed as of Model 3. It is not alone in this - the USB on the BananaPi M2+ is similarly buggy. There are plenty of other IoT devices suffering from similar issues (it is, I guess, a case of "comes with the territory").

The key USB issue on the Pi is its vulnerability to overcurrent. It will kill the whole system if a device is misbehaving in terms of its declared versus actual power draw (a good example here will be a Huawei 220 modem - this ugly wart regularly draws more than it declares). It is however not the only one to do so - you can kill a Razzie with half of the USB devices out there.

USB issues are not limited to power. One of the key elements of the USB spec is being able to manage the coexistence of devices which demand high speed transfers. This is completely broken on the Pi. Hook up a camera, a USB disk and do some network IO. Watch the show. On a good day you will have the USB camera die. On a bad day you will end up killing the whole system. The root cause is most likely once again buried deep the binary firmware. As it is binary and as closed source as close source gets, there is very little that can be done here. All we can do is avoid using the system for more than one high speed over USB application (though we can crash it even with one).

Last, but not least. The USB bus power is not turned off during reboot. As a result a full and complete reset of the USB bus and the devices connected to it is absolutely impossible. The RaspberryPi is the only mass produced shipping computer which cannot reset its USB peripherals upon reboot - all x86, other Arm SOC, etc will flip the power on the bus guaranteeing a proper USB bus reset. It is a fairly standard practice in embedded engineering to have "whack it on the head and reboot it" as a final solution to everything. Because of the bus issues, you cannot apply this to RaspberryPi. If you are whacking it because a peripheral misbehaves, the most likely result will be a hang on reboot.


The original Pi was slow but fairly reliable and with a decent thermal design envelope. This went away with the model B, model 2 and especially model 3. You can kill 2 and 3 thermally with ease. The power management limitations of the firmware are not helping either.

Wi-Fi (Model 3)

Wi-Fi is beyond the pale if you use it for anything but a simple client. Trying to run hostapd on it results in 300ms+ pings and occasional hangs of the whole system. Do not even think of bridging it into the Ethernet. Any activity on the Ethernet at a moment when you have more than one Wi-Fi client connected will have disastrous consequences. The root cause is surprise surprise the "open source" (quotes needed and intended) nature of the Raspberry platform - it is once again my favourite 2MB+ binary firmware blob (and the Wi-Fi firmware therein).

A Recap of My Pi Trials and Pi Tribulations


I should probably have a look at more modern projects like iSpy, but the old "works, do no not f*** with it" mentality is preventing me from doing so. I also need to run it at several locations which are very remote and have Internet connectivity in the form of two tin cans and a string. Actually, worse - GPRS Edge. So I have to process, record locally and push via the Internet uplink only stuff which is considered important.

I am doing it via good old motion and a custom mix of event-triggered move scripts written in python using openvpn, NFS and autofs to move the files to a central NAS. I have built the set-up long before I used Pi. In the early days I used fanless Via EPIA motherboards and mini-ITX systems. My intention was to do a 1:1 migration to Raspberry Pi to improve power and reliability (or so I thought). The executive summary of Pi performance for this job is:

  • Built in camera - this just works (if you get the motion settings for it correctly) and if the Pi is not in an aggressive environment. If the environment is even mildly aggressive (f.e. kitchen or a dining room which has its door to the kitchen open most of the time) the micro SD card contacts will fail. It is not a question of if, it is a question of when.
  • USB (camera module and a tuner dongle)- not particularly reliable. Completely unusable if the Pi is responsible for one or more other functions like for example a DIY Time Capsule
  • DVR and motion analysis of IP cameras - unusable. IP cameras stream up to 3MBit per camera H264 and very few of them know how to do a frame rate different from 25 fps. The older models lack the performance needed to process this, the newer models run too hot even when dealing with just 1-2 cameras. While a model 3 usually runs under 50% loadavg while handling 4 HD cameras "downclocked" to 2 frames per second, it does so at 70C+ on the SOC. As a result it quickly starts to behave erratically (and crashes sooner or later). Analyzing the frequency stats shows that it is clocking under 2% at its low frequency limit and the rest of the time it is running at full throttle. The "textbook" solution to thermal management for a use case like this is to use a conservative governor and let it settle on some interim frequency. Unfortunately, that solution is unavailable as the binary firmware limits us to only running it slow or fast, nothing in-between.

So, rather unsurprisingly, I am slowly replacing all the key RaspberryPi in this function with BananaPi. The Banana actually works for all 3 use cases.

Encrypted Capsule aka Backup To The Shed

Abysmal failure. I tried to set up a Model 3 which was already running some small time CCTV and motion triggered lights control with a modern fast USB hard drive as a virtual "tape" library for amanda.

In theory, a Model 3 should have sufficient performance to handle writing to an encrypted LVM. It overheated and died on the first backup run. After downclocking it, I managed to keep it relatively stable, but I had to wrap the backup with scripts to turn off CCTV and any other functionality before backup and turn it on after that - in effect use the Pi in a "do not breathe on it, it will topple" mode. Heatsinks, downclocking, drilling holes in the case helped a little bit but not enough. It remained unstable.

So, sorry - no go. Any ideas to use a Raspberry as a storage system are in the realm of non-scientific fiction. It does not work - period.

For comparison purposes, I rebuilt the same setup using a Banana Pi R1. The Banana is running CCTV via USB cameras including motion analysis, provide a WiFi access point, controls lights and does a couple of other odds and sods. Despite being officially half of the performance of a Raspberry Model 3 it does the same job faster while running much cooler. It is still doing it without me even touching it half a year later.

Outbuilding Jack Of All Trades - Microserver for Summer House, Car, etc

Abysmal failure. I tried to set up a Model 3 to do basic CCTV (one camera), WiFi Access point using hostapd, mini-router/firewall, media server and squid proxy using a LTE uplink modem. The idea was that once it covers the "basics", I will look into using the GPIO to do various odds and sods like controlling irrigation, lights, HVAC, etc. Well, it failed miserably on the basics long before we got to the fancy IoT stuff:
  • CCTV - in the beginning - mostly worked. The moment the media server started transferring significant amounts of data it keeled over
  • Wi-Fi - the most abysmal of all failures. Worked fine in tests, because I was testing with one device so I actually deployed one of these. This resulted in a users' (family in this case) revolt. Using more than one Wi-Fi client device at the same time resulted in 300ms pings on the Wi-Fi. I have never seen a Wi-Fi in ap mode perform as badly as the built in Wi-Fi on the Raspberry Pi Model 3 and trust me, I have seen a lot - I had to work with residential CPE software for a couple of years..
  • mini-router/firewall - well that worked. Difficult to make a dog's breakfast of it on Linux. The only issue was that some of the older LTE/3G modems I tried brought the whole rig down due to power draw misreporting. Using a modern modem (my personal favorite nowdays is the Huawei E3372) just worked.
  • squid proxy - sooner or later the Raspberry SD Card IO bugbear showed its ugly head. Leaving it to run unattended for a couple of months (as intended) always resulted in IO errors on the card (even if the IO was minimized).

For comparison purposes - the same setup using a Banana Pi Pro is so far working flawlessly - I have several of them made to the same standard - for my summer house, for the car and as a travel media server/hotspot.

Conclusions and Going Forward

What makes the Razzie valuable is the GPIO and to a lesser extent a well supported onboard camera interface. While it has no DAC or ADC, these can be interfaced easily and are not needed for a lot of applications. If we stick to these and do not try to be very original it can be very useful.

Using it for anything you would expect to use a Linux system, even a severely underpowered one like the old pogo plugs is a NO GO. Its decrepit IO and buggy firmware is guaranteed to let you down sooner rather than later. If you want to do BOTH some level of home server functions and IoT you need to use a better SOC - Beagle, Banana or something from the MIPS or x86 family.

In any case, as a result of all my Raspberry trials and tribulations I have a whole bag of them and I have enqueued them for projects which are a good match for their design - controlling the irrigation in the garden, controlling lights, HVAC, etc. I will start adding these here as they get implemented:

-- AntonIvanov - 03 Mar 2017
Topic revision: r5 - 16 Apr 2017, AntonIvanov

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback