Creating a health dashboard by hacking intelligence into an AOpen (the ‘A’ for ancient) monitor; with metrics aggregated by Graphite and beautifully displayed with Grafana.
I’d like to say that the build went on without a hitch, but I ran into two issues. Not project critical issues, but troublesome nonetheless.
Let’s talk about them, and how I’ve managed to successfully resolve some dastardly slow performance, and fail to resolve high static audio issues.
Troubleshooting poor processing performance
Super excited to get the system going, I dd’d Rasbian Buster (desktop) onto a 16 GB card, and completed setup for my Pi Zero.
Immediately after boot, I noticed how sluggish the system was. Some symptoms I’ve experienced include:
- Desktop environment input lag (mouse movement, key presses)
- Long time to load applications
- SSH authentication takes abnormally long (reached 10 seconds at one point)
- SCPing at a rate of 10 kb/s over Ethernet
- CPU always at 100% utilization
Half of me thought it had something to do with my configuration.
However, these symptoms were prevalent since the first boot into Raspbian.
Furthermore, a majority of my configuration was network related, nothing that would cripple other system components.
The other half of me thought it had to do with my Pi Zero. I’ve done some reading online and found others also experiencing poor system performance with Raspbian Buster (desktop) on the Pi Zero. Perhaps a full desktop environment image of Raspbian was asking too much?
Well, I didn’t let that stop me, and took to exploring a wide breadth of light-weight OSes for the Pi, including PiCore, Raspup, and DietPi.
I’ve wiped this MicroSD card enough times to give it an identity crisis.
I eventually got tired of testing out different distributions, and defaulted over to Raspbian Buster Lite, where I installed LXDE along with Midori, Epiphany, and Chromium to decide which would serve as my kiosk browser.
The final image after setup served to be the most responsive but browsing a single page was still taking forever (>60 seconds to load alvinr.ca) – and even then, the load wasn’t complete.
The more numbers I put together, the stranger the situation looked.
It was here when I put software aside, and started looking at some hardware specifications
The Pi Zero runs a 1GHz single-core CPU with 512MB RAM.
My CPU utilization on a fresh installation of Raspbian Lite was always near 100%, while RAM usage on my own image never exceeded ~200 MB.
The entire unit remains quite cool while operating, barely deviating from room temperature – it wasn’t like I was giving it a reason to, nor the means to with a 5V/1A supply.
Huh.
Taking a look at the power requirements for the Pi Zero made me realize I was using a supply below recommended. This was taking into account my ‘desktop’ setup, with a USB/Ethernet hub housing a wireless keyboard/mouse dongle.
Could it be? The Pi was throttling CPU to prevent brownout?
I’m telling you – if there’s anything I’ve learned as a FIRST alumni from 4 years of competitive FIRST Robotics, it’s to know your power draw, and always charge your damn batteries.
As for our system here, we know the power draw.
Some further research for the Raspberry Pi yielded the following documentation – recommending a supply of 2.5A.
I’ve got something close enough – a Samsung S7 5V/2A charger.
I swear, if I plug in this supply and it turns out that was the problem all along…
Well.
After an hour of playing around with it (and several sanity-driven reboots later), I now experience U N P A R A L L E L E D performance.
Really though, performance has improved drastically.
CPU utilization with Chromium running sits at around 60%, and it only takes 20 seconds to complete load alvinr.ca.
Network performance was better as well, managing to perform an SCP transfer at ~8 MBps – close enough to the 10/100 Ethernet adapter capabilities.
All that’s left now is to replace the existing 5V/1A adapter with this one.
Before; featuring the 5V/1A generic USB power supply I’ve got from god knows where… 
After; featuring the S7’s 5V/2A power supply secured down with wire
Sweet – let’s move on.
Troubleshooting high static on the Raspberry Pi
It’s the end of the final assembly – we’ve got a better power supply, wires and components have been neatly organized, and everything is secured down.
Let’s perform one more test – except instead of loading alvinr.ca, let’s load SoundCloud and listen to a cover by Anson Seabra – Love The Way You Lie by Rihanna.
I couldn’t even make it 10 seconds in – the sound was absolutely jarring, a rough mix of tones and high static.
Not the song mind you – I’ve definitely broke something along the way.
Let’s get this out of the way – I haven’t resolved this yet, nor have I pinned down an exact cause. I’m moving forward with the project, considering all the time invested into troubleshooting (and since audio was an optional feature).
However, if you manage to run into something similar, here are some things I’ve tried:
- Re-seat connectors
- Use a shielded vs. non-shielded AUX cable
- Ground Raspberry PI
- Different audio output device
- Different audio track, different audio player, even different Linux distros
At the least; I’ve narrowed it down to a hardware fault, either with the Pi, or more likely, the Mini HDMI to VGA adapter (since it splits audio to AUX output).
A little light and some hot glue digging eventually led me to finding a possible fault, present in this very adapter.
While I don’t know what purpose this wire serves, I’ll leave the blame on it for now, until I find the time to either investigate it further, or purchase another adapter.