Casualty In Debugging 5V Supply for Prototype VFD Driver

Once we had functionality of our prototype VFD driver figured out, we turned our attention to the other problem that cropped up earlier in our initial integration with the original power supply transformer: our 5V rail could support the PIC microcontroller and associated chips, plus putting a voltage bias on the filament. But when put a Raspberry Pi on the circuit, our 5V sagged low enough to put our Pi into a power brown-out reset loop.

Since the MP1584 voltage regulator we used has proven capable of powering a Pi in the past, this was puzzling. So we started quantifying our system starting with measuring the amperage draw of our 5V circuit. It was well within the 3A maximum draw supported by the regulator, so our next thought was a dirty output wave. Putting the output on an oscilloscope, the 5V line looked pretty clean so that was not the explanation.

The next experiment was to isolate the 5V supply chain. Instead of supplying the MP1584 voltage regulator with power from the rectified output of a transformer rail, we’re going to use a two-cell lithium polymer battery. If this worked, we’ll know the problem is upstream in the transformer or rectifier. If it doesn’t, we’ll know the problem is the regulator or further downstream.

Unfortunately the experiment failed due to a wiring error, which destroyed the MP1584 voltage regulator. The title picture shows the entire regulator module with a U.S. quarter dollar coin for scale.

And here’s a close-up of the dead MP1584 chip. The glossy blob in the upper left is plastic that has melted and resolidified. The bump in the middle was a tiny volcano where smoke pushed up through the casing and escaped.

MP1584EN chip with melted hole

Looking on the bright side, we are no longer suspicious of the MP1584 chip’s functionality. We now know for sure it doesn’t work!

Debugging continued with help of a benchtop power supply delivering 5V. Probing with a volt meter through the circuit, and seeing voltage drop along the supply path, we decided our problem wasn’t any single wiring errors in the circuit. We just had too many thin wires and connectors involved in the 5V supply path. We had put our Raspberry Pi at the end of the chain of 5V parts, and it couldn’t draw enough power to run. Not because of any single large obstacle but because of the cumulative effect of lots of little obstacles.

To test this hypothesis, we reversed the chain so our 5V supply entered the system at the Pi then propagated to the rest of the circuit. With this change — and no other change in the circuit — everything started working. This is a valuable lesson to a software person who is used to thinking in terms of digital logic: It’s easy to think 5V rail is 5V as long as there are wires connecting them. This simplification creates a blind spot: the real world is analog and our 5V rail will degrade to a 4V rail when too-thin wires are used!

With that problem solved, we can now start playing with VFD patterns. See what works and see what doesn’t.


Google AIY System Image Still Fragile

After exploring a Google AIY Voice kit’s capabilities and found it promising for future projects, I thought it was a pretty good deal at the clearance price of $15. Sadly for Google and Target, I still think its original price of $50 is high for what we get in the box. And that’s before I ran into what appears to be a recurring problem with the Google AIY kits: their customized build of Raspbian is very fragile and has a history of failing after system updates.

Google AIY Voice Bonnet

Of course, I didn’t realize the root cause immediately. When I initially booted up my box, with USB keyboard+mouse and HDMI cable attached, I ran through its initial setup procedure which helped me log on to my local network, change the default password to something other than ‘raspberry’, tasks of those nature. One of these steps was whether I wanted to download and install updates. Even though I followed instructions to download the latest system image, as of right now the “latest” is still from this past November and missing quite a few security patches since. I had continued playing with the hardware while updates installed, fiddling with things as I went. Eventually I had to reboot the box and when it came back up, everything has fallen apart.

I was in the middle of playing with aplay and arecord so my first symptom was a complaint of missing sound hardware. Since by then I had already established that they are standard Linux sound devices under ALSA (Advanced Linux Sound Architecture) I started looking up resources online to debug ALSA sound hardware running on a Raspberry Pi. This, I have since found out, is a huge bag of hurt best summarized by the following passage from this StackExchange thread:

However, at no time in history has mankind produced such an amount of useless and dysfunctional diagrams, as for trying to explain ALSA.

That’s just one man’s opinion, of course, but after several hours of banging my head against ALSA brick walls I saw nothing to contradict that opinion. Even Adafruit, typically the benchmark of clear concise tutorials, could only offer this mess which falls far short of their typical standards.

I was almost ready to give up on the whole works when I remembered to run a LED test and found that also failed with an error message Leds are not available on this board. That’s when I finally realized it’s not just the sound hardware, everything on board Voice Bonnet has gone offline. I’m not enough of a Linux expert to understand the details of what went wrong, but apparently certain types of system upgrades would wipe out all the customization required to support Voice Bonnet hardware.

This comment on a Github issues discussion thread suggested running a whole bunch of sudo dpkg-reconfigure commands to bring them all back. This might be worth trying some point later. But for today’s experimentation I re-imaged my microSD card and set up the box again – this time declining to download and install all updates. It’s a very insecure workaround, but today I only need to continue experimenting with the hardware. I’ll have to see if this problem is updated when I want to use this hardware for an actual project.

Bottom line: it’s very disappointing to have Google’s custom AIY version of Raspbian stop working on Google AIY hardware after certain system updates. I’m sure some number of these incidents resulted in the product getting returned to Target under their generous refund policy, which wouldn’t be very helpful to retail success at all.

Examining Google AIY Voice Bonnet LED and Pins

The default demo for a Google AIY Voice kit turns a Raspberry Pi Zero in a cardboard box into a Google Voice Assistant. I wasn’t terribly interested in that at full price, but at clearance discount they were interesting enough to purchase. I had fun looking over its “Voice Bonnet” audio accessory board to verify it is easy to re-purpose to sound-based projects of my own choosing. Once that primary goal was complete, I looked at some of the auxiliary features on that accessory board to see what’s going on.

Google AIY Voice Bonnet

First up is aiy.board which interfaces with the big plastic button. It looks like the kind of button found on an arcade console and I would expect it to be durable for many cycles. The source file has all the code dealing with the messy realities of dealing with a physical button, including logic to handle debouncing.

Next is aiy.leds. When assembling that button, I noticed it had more pins than strictly necessary for a button and it turns out the button also incorporates a RGB LED array. While aiy.board has code to deal with that LED array, comments indicate there’s a better API available elsewhere for the RGB LED in the aiy.leds source file. Indeed there appears to be better support for lighting effects like blinking, pulsing, and color blending.

Finally aiy.pins allows access to the GPIO pins exposed by Voice Bonnet. I had originally thought these were passed through from the Raspberry Pi GPIO bins, but further reading indicates I was wrong. These pins are controlled by the SAM D microcontroller on board the bonnet, and aiy.pins expose them for use in a way compatible with Raspberry Pi’s gpiozero library.

This looks like a pretty decent set of auxiliary functionality available on the Voice Bonnet, certainly enough to handle some simple projects without pulling in additional hardware. Also, the RGB button and auxiliary pins are apparently shared between the Voice and Vision bonnets so common code can drive both. This may prove useful somewhere down the line.

Google AIY Voice Bonnet Will Be Easy To Repurpose

Google’s AIY products were an experiment to bring a hands-on building experience to retail storefronts. It’s the kind of thing one would expect to find at Radio Shack, if Radio Shack were still alive. Sadly, with the AIY Voice kit marked down for clearance at my local Target, the experiment did not appear to be a resounding success. Still it means I now have a Google AIY voice kit to play with.

Just for the sake of seeing how it was supposed to come together, I followed assembly instructions even though I had no interest in building my own Google voice assistant for my home. Or at least, I got it set up far enough to have the mechanical box on my home network. I stopped before completing the steps to sign up for Google Assistant API access and enrolling this piece of hardware.

What it means is that I now have a Raspberry Pi Zero on my home network, coupled with “Voice Bonnet” audio hardware that I can now learn more about.

Google AIY Voice Bonnet

It appears all the code to interface with this Voice Bonnet is documented and available online. I went straight to the APIs to see how one interacts with the audio capabilities. I had expected to find code interfacing with device drivers and hardware registers, I didn’t expect that the source file mostly consists of code that calls out to standard command-line audio utilities arecord and aplay.

I then looked into the default text-to-speech capabilities inside aiy.voice.tts and found much of the same: text is sent out to a command-line utility pico2wave which does all the hard work. It generates a sound file, which is then sent to aplay for playback.

This is great news: this meant it will be trivial to use the audio recording and playback capabilities of this Voice Bonnet for purposes other than interacting with Google voice assistant platform.

Hello Google AIY Voice Kit

As someone who have played with electronics modules purchased online for a wide variety of projects, I was fascinated by Google’s AIY projects a.k.a do it yourself artificial intelligence line of products. Here in the United States, Google is not doing it alone. The products themselves are not enough if it isn’t in front of people’s faces, so there was also a partnership with the retail giant Target to have these kits on the shelves of Target stores. I didn’t think there is large enough of a market for these products willing to pay the prices it would take to justify a retail presence, but I admire the willingness to put up the money for an experiment to find out.

There were two kits: the AIY Voice kit and the AIY Vision kit. The vision kit costs roughly double that of the voice kit ($90 vs. $50) but it was far more interesting with an onboard Pi camera and a TensorFlow processor designed to accelerate machine vision tasks. When the vision kit became available at my local Target, I immediately purchased one so I could play around with its default demo software. Sadly my TensorFlow knowledge is still too weak for me to make the vision kit do my own bidding.

As for the voice kit, I knew it was also built around a Raspberry Pi Zero with a hardware accessory board, but that board was focused on audio capture and playback not significantly different from a sound card. I was not aware of any audio processing capability on board, so I expected the audio to be recorded and uploaded to Google for processing. This capability was not interesting enough for me to buy one at $50.

It’s been over a year since the retail experiment began, and my local Target has marked the AIY Voice kit for clearance sale at $15 each. (I later found out Micro Center was even more aggressively clearing them out at $5 each.) I guess this means we have an answer to that experiment. I’m a little sad to learn of this, because I would have loved to be proven wrong. If there was indeed a market for a successful product in this area that would have meant more interesting products for me to purchase locally. Alas, it looks like I’ll continue to buy esoteric little electronics gadgets online.

Still, right now I could pick up an AIY Voice kit for $15. The Raspberry Pi Zero at the heart of the device has a retail value of roughly $10 all by itself. Add in the microSD card and we’re pretty close to $15 before considering the rest of the kit. I passed on the AIY Voice kit at $50, but I’m willing to buy them at $15. Worst case scenario, I will have a Raspberry Pi Zero W and matching microSD card.

Here’s what I saw when I opened the box:

Google AIY Voice Kit

There were no surprises. Aside from the expected Raspberry Pi Zero W and microSD card, we have the hardware accessory called a “Voice Bonnet”.

Google AIY Voice Bonnet

The remaining hardware components are a single speaker and a big button (that turned out to have LEDs in it) and they plug into this bonnet.

Let’s see what this kit has to offer.

Adafruit Spooky Eyes On Raspberry Pi

[Emily] and I were first exposed to Adafruit’s “Spooky Eyes” in the context of their HalloWing given out to all Superconference 2018 attendees. We think it looks like a lot of fun and thought it would be nice to make it available on other hardware platforms. We looked under the hood to see how it has been packed tightly for low power microcontrollers, but as a result of its simplicity it was a fairly simple task to translate encoded Spooky Eyes data into PNG image files. This would make the image data more easily usable on less constrained hardware like a Raspberry Pi.

But as it turned out, Adafruit was way ahead of us. They already offer Spooky Eyes running on a Raspbbery Pi! I thought I had looked for this earlier but if so I had missed it.

Adafruit Raspberry Pi Eyes

Reading the details of that tutorial, a few interesting items of note:

  • Just like the HalloWing, there’s provision for light reactivity. However, a HalloWing has an onboard light sensor but a Raspberry Pi does not. The user would have to install a photocell.
  • By default the eyes move randomly, but there’s also provision for a joystick to steer their gaze direction. Again this is an analog joystick the user would have to install.
  • By default the eyes blink at random intervals, but there’s also the option to add buttons to trigger eyelid blinks.
  • Even though the product image shows a Raspberry Pi zero, the documentation says A Raspberry Pi 3 or Pi 2 is highly recommended. The code will run on a Pi Zero or other single-core Raspberry Pi boards, but performance lags greatly.
  • It is designed for Adafruit’s little display units, but the code could just as happily render to a Raspberry Pi’s standard HDMI output. Bypassing all the Adafruit hardware is possible as described in the Using Just the Software section.

Browsing through the source code repository, I see it uses quite a few Raspberry Pi specific code libraries. In addition code dealing interfacing the Adafruit display units, there’s also GPIO code to handle the joysticks and buttons above. And lastly, rendering is handled by the pi3d library to take advantage of a Raspberry Pi’s GPU. If I wanted to make Spooky Eyes run on, say, my Linux laptop, all those pieces of code would require modification.

Detecting Raspberry Pi Thermal Throttling From Console

Raspberry Pi over temperature 80 85While in the process of obtaining proof that a Raspberry Pi 3 is under-powered for certain ROS processing tasks like mapping, I took a little side trip into the world of Raspberry Pi thermal management. Anyone who has pushed the limits of a Raspberry Pi would have seen a thermometer icon in the upper right corner. A quick search finds that it is put on-screen by firmware and not visible to the operating system. So when a Raspberry Pi is mounted on a robot and not attached to a monitor, we can’t see this icon. However, it is still possible to detect high temperature condition by using the command line tool vcgencmd.

raspberry-pi-logoThis tool appears to be specific to the Raspberry Pi hardware and wraps a collection of tools to query hardware information. Official documentation seems pretty slim, not even an official name. Raspberry Pi forum users hypothesize it stands for “VideoCore General Commands” which is good enough for me.

Raspberry Pi over temperature 85The first useful tool is to measure temperature. vcgencmd measure_temp will return a temperature in Celsius. This internal number is more useful than attaching an external physical temperature measurement because this internal number is what the firmware will use to decide what to do. When temperature rises above 80°C, a thermometer icon overlay with a half-full bar of red is shown on-screen and the system starts pulling itself back. When it hits the target ceiling of 85°C that icon is replaced by one with full bar of red, and the firmware becomes more aggressive throttling things down to stay below 85°C.

It’s possible to keep an eye on temperature by running the tool continuously at a regular interval, something like watch -n 0.5 vcgencmd measure_temp. But once it gets into the 80-80°C range, we can’t tell if the Pi is approaching its limits, or if those limits had been exceeded and the chip slowed itself down to stay in temperature range. For that information, we’ll need a different command.

Running vcgencmd get_throttled will return a hexadecimal number representing a set of binary flags. There is no official documentation of these bits, but a lot of Raspberry Pi user documentation link to this post as reference. If any of the throttling bits are set, the Pi is working at less than maximum potential on account of overheating.

Knowing throttling occurred was enough for my experiment, but if I ever need to go one step further and find out how much throttling has occurred, there are tools for that, too. It’s possible to retrieve CPU clock frequency via vcgencmd get_config arm_freq and also by looking at /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq. But that’s beyond the scope for today.


A 3D-Printed Enclosure to Take My LED Project On The Go

For the Connect Week event put on by Innovate Pasadena, the Hackaday LA group is hosting the “Bring-A-Hack” event where attendees are encouraged to bring projects (in any stage of completion) for show and discussion. Since I’ve been building my LTC-4627JR driver board as a learning project, I wanted to bring it in for show-and-tell.

Now I could just bring the assembled circuit board and pass it around as an inert object, but what fun would that be? I wanted to bring in something that shows it doing something, and provide some way for people to interact with the whole contraption. Looking at my parts on hand, it seemed easiest to rebuild my thermometer test project. I can have a simple Python program run on the Raspberry Pi, reading temperature from the Tux-Lab Si7021 breakout board, and sending it out to my display. That makes 3 circuit boards, plus they’ll need portable power. I will enlist my Amazon purchases: the 3-cell lithium ion battery pack protected by a S-8254A IC, and the MP1584 buck converter to translate the battery pack’s power into Raspberry Pi friendly voltage.

They present a logistics challenge. There are many parts and while it’s fine to just connect them with wires on my work table, it’s too unwieldy to carry on the Gold Line to Pasadena. I’m going to need some kind of enclosure to carry the whole thing.

To Fusion 360 we go! I just needed a simple enclosure so it was pretty fast to draw up. The bottom tray is for power: it holds the battery cells, their protection board, and the buck converter to 5 volt output. The upper tray holds the Raspberry Pi. The lid of the tray holds my custom LED circuit board, and a few clamps holds it all together. The clamps should be easily removable so I could disassemble the box to show people what’s inside.


I had originally intended to mount the Si7021 breakout board as well, but ended up deciding it would be more fun to have it dangling out for people to play with it. Here are the layers without the clamps, so they can be taken apart and show off the insides.


And here’s the “travel configuration”, with clamps holding the pieces together.


This setup worked well. I was able to carry it in my backpack without worrying about tangling up or shorting out wires. Once I arrived, the project was fairly well received and lots of people had fun playing with the thermometer.

Qt Quick with PyQt5 on Raspberry Pi

QtLogoThe prime motivation for me to go through Qt licensing documentation and installing Qt Creator IDE was to explore the new UI infrastructure introduced in Qt 5 under the umbrella of “Qt Quick“. As far as I can tell, this is an entirely different system for creating user interface of a Qt application. Built with modern ideas such as OpenGL graphics acceleration for animation effects and UI layout declared with a text-based markup language QML (probably stands for Qt Markup Language.)

Up to this point my experience with building graphics user interface in Qt was with the QWidget-based infrastructure, which has a long lineage in past editions of Qt. Qt Quick is new for Qt5 and seem to share nothing in common with QWidget other than both a part of Qt5. Now that I’ve had a bit of QWidget UI work under my belt I wanted to see what Qt Quick has to offer. And this starts with a smoke test to make sure I could run Qt Quick in the environments I care about: Python and Raspberry Pi.

Step 1: Qt Creator IDE Default Boilerplate.

Once the Qt Creator IDE was up and running, I followed the Qt Quick tutorial to create a bare bones boilerplate Qt Quick application. Even without any changes to the startup boilerplate, it reported error messages complaining of missing modules. Reading the error message, I looked at the output of apt list qml-module-qtquick* and installed the ones that sound right. (From memory:qml-module-qtquick2qml-module-qtquick-controls2, qml-module-qtquick-templates2, and qml-module-qtquick-layouts)


Once the boilerplate successfully launched, I switched languages…

Step 2: PyQt5

The next goal is to get it up and running on Python via PyQt5. The PyQt5 documentation claimed support for QML but the example on the introductory page doesn’t quite line up with the Qt Creator boilerplate code. Looking at the Qt Creator boilerplate main.cpp for reference, I translated the application launch code into This required sudo apt install python3-pyqt5.qtquick in addition to the python3-pyqt5 I already had. (If there are additional dependencies I forgot about, look for them in the output of apt list python3-pyqt5*)


Once that was done, the application launched successfully on my Ubuntu desktop machine, albeit with visual appearance very different from the C++ version. That’s good enough for now, so I pushed these changes up to Github and switched platforms…

Step 3: Raspberry Pi (Ubuntu mate)

I pulled the project git repository to my Raspberry Pi running Ubuntu Mate and tried to run the project. After installing the required packages, I got stuck. My QML’s import QtQuick 2.7 failed with error module "QtQuick" version 2.7 is not installed The obvious implication is that the version of QtQuick in qml-module-qtquick2 was too old, but I couldn’t figure out how to verify version number is indeed the problem or if it’s a configuration issue elsewhere in the system.

Searching on the web, I found somebody on stuck in the same place. As of this writing, no solution had been posted. I wish I was good enough to figure out what’s going on and contribute intelligently to the discussion!

I don’t have a full grasp of what goes on in the world of repositories ran by various Debian-based distributions, but I could see URLs flying by on-screen and I remembered that Ubuntu Mate pulled from different repositories than Raspbian. I switched to Raspbian to give that a shot…

Step 4: Raspberry Pi (Raspbian Stretch)

After repeating the process on the latest Raspbian, the Qt Quick QML test application launches. Hooray! Whether it was some configuration issue or out of date binaries we don’t know yet for sure, but it does run.

That’s the good news. Now the bad news: it launches with the error:

JIT is disabled for QML. Property bindings and animations will be very slow. Visit to learn about possible solutions for your platform.

And indeed, the transition between “First” and “Second” tabs were slow. Looking on the page that it pointed to, it looks like the V4 JavaScript engine used by Qt for QML applications does not have JIT compilation for Raspberry Pi’s ARM chip. That’s a shame.

For now, this excludes Qt Quick as a candidate for writing modern responsive user interfaces for Raspberry Pi applications. If I want to stick with Qt and Python, I’m better off writing Qt interfaces in the old school QWidget style. We’ll keep an eye on this – maybe they’ll add JIT support for Raspberry Pi in the future.

(The source code related to this blog post are publicly available on Github.)

Raspberry Pi Pin Initial States are a Consideration For Machine Control

As an intermediate step towards controlling the thermoforming machine with the Raspberry Pi, we populated a breadboard with some components we planned to use. A Raspberry Pi could only source a total of 50mA of power across all the IO pins, so we had it switch circuits on/off via opto-isolators that required far less current to activate. We started by using these opto-isolators to control power to LEDs. Just to see how it works and make sure nothing unexpected occurs before we start hooking up bigger things.

This proved to be wise, as it exposed some Raspberry Pi behavior we did not expect. When the Pi was powered-up, some of the LEDs glowed dimly. They’re not full bright, but they’re definitely not dark, either. Once the control program starts up and all pins are initialized to off, they go dark as expected. But there’s something going on between initial power-on and when the control program starts running.

This was important to chase down because we don’t want the machine relay to close when we’re not expecting them to close. Even worse if it occurs while the system is powering up and components are not yet in known good states. Making this an important consideration in designing our system.

A bit of web searching confirmed this startup behavior was noticed and investigated by a lot of people looking at various parts of the system. The answer was most succinctly answered by a post on the Raspberry Pi subsection of StackExchange: In the peripherals manual for the BCM2835 chip at the core of the Raspberry Pi, the power-on initial states are explicitly stated: All IO pins are configured to be input and not output. Furthermore, pins 0-8 are set with pull-up to 3.3V and pins 9-27 are pulled-down to 0V.

Looking back on the breadboard, we could confirm the explanation matches the observed behavior. The dimly lit LEDs were controlled by opto-isolators that were, in turn, connected to Raspberry Pi pins 5 and 6. None of the other isolators were controlled by pins in the 0-8 range. Since opto-isolators required so little current to operate, the weak pull-up on a pin set to input was sufficient to partially activate the circuit.

Once the cause was determined the solution was simple: move all output control out of the 0-8 range of pins. These pins would be fine for input, so the task of reading the position of a limit switch was moved to pin 5.

The resulting breadboard is visible in the attached image, and the code was changed to match the new pin assignments in this commit. After these changes, we observed no partially lit LEDs which also hopefully means no unexpected relay activity when we hook it up to the machine.


Setting Up Raspberry Pi GPIO Pins For Device Control

A rough draft of the thermoformer touchscreen control panel application, witting in Python with the Qt UI framework, is now up and running. Now it is time to see how it works controlling some physical hardware. We’re going to build up to this in steps on the way towards actually controlling the thermoform machine. The first step is to have the Pi light up some LEDs as commanded by the control panel application.

I had been playing with a Microchip PIC16F18456 earlier, which can drive LEDs effortlessly. Each pin can handle 50mA which is more than enough to drive LEDs as they typically require no more than 20mA each. I had assumed the Pi would be even more capable with its onboard voltage regulators, but I thought it’d be better to check just to be safe. I’m glad I did! It turns out the pins on the Raspberry Pi has significantly lower power capability than the pins on the PIC16F18345.

The consensus on the Raspberry Pi forums says the limit is 16mA per pin, and 50mA total across all pins. A bunch of LEDs would quickly exceed the 50mA total cap. Given this, we’re going to take two baby steps at once.

We’ve known we couldn’t drive the thermoforming machine directly with Pi. And even if we could, a direct connection is not the best idea. The plan had always called for the use of opto-isolators to keep some separation between the delicate low-power circuitry on the Raspberry Pi chip and the high-power components of the machine. I just didn’t expect that bright LEDs to qualify as “high power” in this context. But since they are, we’re going to use opto-isolators to build the LED proof of concept.

The current design for the control has 9 outputs to relays, and 1 input from a limit switch. For the outputs we’re starting with the Vishay 4N32 chip to see how they work. For input, we wanted a chip that works in the reverse direction, and we’re starting with the Toshiba TLP2200. With the help of a Raspberry Pi I/O breakout board we could hook everything up on a breadboard for the first test.


Learning Timers: Qt QTimer and Python threading.Timer

QtLogoWhen I interfaced my PyQt application to the Raspberry Pi GPIO pins, I ran into a classic problem: the need to perform input debouncing. The classic solution is to have the software wait a bit before deciding whether the input change is noise to be ignored or not. A simple concept, but “wait a bit” can get complicated in the world of GUI programming. When writing simple programs, we can probably get away with a literal wait by “going to sleep” for a little bit. But we don’t have that luxury in the world of GUI programming – going to sleep would freeze everything in the program. In general, users do not appreciate their UI becoming frozen and unresponsive.

Python LogoThe solution: a timer. In a Windows application, the programmer can use the operating system timer and do their “after waiting a bit” tasks in response to the WM_TIMER message. I went looking for the Qt equivalent and found several timer-related features. QTimer, QBasicTimer, and QObject::startTimer(). Thankfully, the documentation also provided an overview describing how they differ. For debounce purposes, the most fitting mechanism is a single-shot timer.

Unfortunately, when I tried to use it, I received an error message telling me I could only use Qt timer objects from code launched with QThread. Which apparently wasn’t the case with code running under the context of a QWidget within a QApplication.

I had hoped the Qt timers, working off of the QApplication event queue, would stay on the UI thread. But it appears they have to have their own QThread. I could put in more time to figure out how to get Qt timers to work, but I decided to turn to Python library instead. If I have to deal with multi-threading issues anyway, there’s no reason to avoid Python’s Timer object in the threading library.

It does mean I had to review my code to make sure it would be correct even if called from multiple threads. Since the important state are the status of the GPIO pins, they are handled by the pigpio library and the code in my app should be fairly safe. I do set a flag to avoid creating multiple Timer objects in the case of input bounce. If I cared about making sure I only ever create a single Timer, this flag should be protected against cross-thread access. But reviewing the code I decided it was OK if a few Timer ends up being created – the final result of reading the GPIO pin should still be the same even in the case of multiple Timers doing duplicate work.

(The project discussed in this blog post is publicly available on Github.)

Qt + Python = GUI for Raspberry Pi Project

Since the mission of the Raspberry Pi foundation is to “put the power of digital making into the hands of people all over the world” there is no shortage of options for programming the Pi. We have at our disposal many choices in programming languages, each with multiple application frameworks, and a large community of Raspberry Pi users for support.

QtLogoFeeling overwhelmed with options, I chose the one that best lines up with my long-term goal of getting up and running on ROS. The ROS plug-in architecture for operator GUI is rqt, based on Qt. And like much of ROS, the user has the option of working with rqt in either C++ or Python. Since I had started dabbling with ROS in Python before getting distracted, I thought the combination of Qt and Python would be a good direction to go.Python Logo

The Qt framework itself is aimed at C++ developers, and its documentation is written accordingly. Fortunately there are translation layers (language bindings) for Python. The one that seems to be the most mature is PyQt with a long list of resources, books, and online tutorials.

The next decision to make is which version to start learning. Browsing through the resources, it looks like Qt 4 is the mainstream version and Qt 5 is the new shiny. Since ROS is still in the midst of transitioning from Python 2 to Python 3, I assume rqt would be relatively old school as well. No matter which one I choose, there’ll be differences I have to tackle whenever I get around to diving deep into ROS. On the assumption that the latest and greatest versions are also the most polished (an assumption based on how Python 3 cleaned up a lot of architectural messiness of Python 2) I thought I’d start learning with the latest releases and make adjustments later as I need to.

So: Qt 5 and Python 3 it is, with the help of PyQt5 binding. Which is easily installed on a Raspbian Stretch system by installing the packages “pyqt5-dev” and “pyqt5-dev-tools”.

Si7021 Sensor to Raspberry Pi to PIC to LED

I started this I²C project by creating a simple I²C-controlled LED display using a PIC micro controller. Then I found an I²C Python Raspberry Pi library to communicate with my PIC. The next addition to the mix should be an I²C device I did not create, to verify my code plays well with others.

While talking about I²C at Tux-Lab, one of the past projects came up: a breakout board for the Si7021 temperature and humidity sensor. A unit was brought out for show during this conversation. This particular unit was built a few years ago and has yet to be incorporated into a project.

A web search confirmed this is quite a popular sensor. Lots of sample code and projects. Both Adafruit and Sparkfun sell breakout boards similar to the one Tux-Lab created. And the sensor is also part of the popular Sense HAT. I looked at the data sheet and thought it looked like a good place to start. Best of all, a search for existing code found one in the “Examples” section of the Pi GPIO library I wanted to learn anyway.

I asked to borrow that unused breakout board and added it to my bread board. (Visible in the lower-left of the attached picture.) The additional wiring was trivial, most of the work was on the software side learning Python basics. It didn’t take terribly long to create a rudimentary thermometer. My Python code running on the Pi uses I²C to query the Si7021 for temperature, converted that data for display, and sent that data out the same I²C bus to the PIC.

With the work and learning I’ve put in, I now have an overly complicated contraption that tells me my work space temperature is 75.18 degrees Fahrenheit.

No decimal point on the LED because I ran out of pins on the 18-pin PIC16F1847 chip.


Exploring Options For Raspberry Pi I²C Programming

i2cbuslogoNow that I have a rudimentary I²C implementation up and running on my PIC, it’s time to figure out how I’ll control it from code running on a Raspberry Pi. Which means it’s time for this novice to go bumping around in the dark looking for a place to start.

The first thing I looked at was the Raspberry Pi Sense HAT. I bought one along with my Raspberry Pi and it was a fun little thing to play with, learning some basic Python along the way. The Sense HAT communicates with the Pi via I²C. I found the Github repository where the source code for the SenseHat module is published, but my Python knowledge is too thin to trace to their low-level I²C communications code.

The next thing I thought of was the Adafruit PWM/Servo HAT, which I also purchased for experimentation. Looking at that HAT’s tutorial and the Adafruit I²C tutorial, I found their I²C library which worked well enough for me to do rough tests of my I²C code running on the PIC. Adafruit code seem to be Python 2 specific with no Python 3 version. This is not an immediate problem because I intend to use ROS which is also on Python 2, but I wanted something with broader (more than Adafruit) support and more future-proofing.

On the logic of “If there’s something on Adafruit, there’s probably also something on Sparkfun.” I found the SparkFun Raspberry Pi I²C tutorial which uses the wiringPi library to access the Pi’s GPIO pins. This library looks pretty popular, and it includes an I²C library. The downside is that wiringPi is focused on C programs. A Python interface layer exists but not maintained by the owner.

raspberry-pi-logoI felt there must be another way since the Raspberry Pi is focused on education and making technology accessible. A little more web searching paid off: The pigpio library. It is the default option for GPIO control in Raspberry Pi documentation. Built into recent builds of Raspbian so it is a part of the stock Raspberry Pi. I can interface with it in C, Python 2, Python 3, or even the command line utility. Source code is public if I ever wanted to dig deeper.

This looks like the best option. I’ll start using it and see how far I get.

Powering the Raspberry Pi 3 With MP1584 Voltage Step-Down Converter

The Raspberry Pi 3 is a very impressive piece of hardware for the price, but it has its flaws. One challenge is supplying power to a Pi 3. Like all the Pi boards, power is supplied via a standard micro USB plug. This implies the Pi only needs USB level power with its specified maximum of 0.5 amp @ 5 volts = 2.5 watts. In reality, this USB port is abused beyond the specified range. The Raspberry Pi foundation recommends the power supply for a Pi 3 should supply up to 2.5 amp @ 5 volt = 12.5 watts. Five times the USB specification maximum.

None of the USB power sources I already had could handle this workload. I originally had ideas about running a Pi 3 off of a portable USB charger, but that failed under the vastly greater power draw. I went looking online for solutions.

I needed an efficient DC to DC voltage regulator that can handle the maximum power draw of a Raspberry Pi 3 without consuming a lot of power itself. Since the voltage of a battery changes as it drains, the converter needs to handle a range of input voltages while holding the output voltage steady.

The MP1584 chip from Monolithic Power Systems fit the bill, but I didn’t want to deal with a tiny surface mount IC, nor do I have the skill to design the supporting circuit required. Consulting with a few electronics hardware hobbyists, I got the recommendation to take the reference design out of the datasheet and build that.

And then, an even better recommendation: If it’s a popular chip, and its reference design is good enough, somebody would have mass-produced it and put it on Amazon. And indeed, they have. A lot of vendors, in fact, from all around the world.

I scrolled through a few of the listings but didn’t really have a good feel on how to judge one vendor against another. So I took the easy way out: I clicked on the “Amazon’s Choice” link to this offering.

Once the module arrived, I soldered battery connectors to the input and a micro USB plug to the output. I adjusted the output voltage to 5 volts, and connected everything to power up my Raspberry Pi 3.


So far it has worked very well. The Raspberry Pi 3 stayed running through tasks that demanded extra power, that would previously trigger a low-power brownout with my existing USB power sources. The output voltage held steady as the battery drained.

Functional, inexpensive, and I didn’t even have to deal with surface mount components! This was a win.


Fusion 360 vs. Onshape: Raspberry Pi

raspberry-pi-logoAnd now for something completely silly: let’s look at how our two competing hobbyist-friendly CAD offerings fare on the hobbyist-friendly single-board computer, the Raspberry Pi.

(Spoiler: both failed.)

Raspberry Pi

I have on hand the Raspberry Pi 3 Model B. Featuring a far more powerful CPU than the original Pi which finally made the platform usable for basic computing tasks.

When the Raspberry Pi foundation updated its Raspbian operating system with PIXEL, they switched the default web browser from Epiphany to Chromium, the open-source fork of Google’s Chrome browser. Bringing in a mainstream HTML engine resulted in far superior compatibility with a wider range of web sites, supporting many of the latest web standards, including WebGL which is what we’ll be playing with today.

Autodesk Fusion 360

Fusion 360 is a native desktop application compiled for Windows and MacOS, so we obviously couldn’t run that on the Pi. However, there is a web component: Fusion 360 projects can be shared on the Autodesk 360 collaboration service. From there, the CAD model can be viewed in a web browser via WebGL on non-Windows/MacOS platforms.

While such files can be viewed on a desktop machine running Ubuntu and Chromium, a Raspberry Pi 3 running Chromium is not up to the task. Only about half of the menu bar and navigation controls are rendered correctly, and in the area of the screen where the actual model data should be, we get only a few nonsensical rectangles.


Before this experiment I had occasionally worked on my Onshape projects on my desktop running Ubuntu and Chromium, so I had thought the web-based Onshape would have an advantage in Raspberry Pi Chromium. It did, just not usefully so.

In contrast to A360’s partial menu UI rendering, all of Onshape’s menu UI elements rendered correctly. Unfortunately, the actual CAD model is absent in the Raspberry Pi Chromium environment as well. We get the “Loading…” circle and it was never replaced by the CAD model.


Sorry, everyone, you can’t build a web-based CAD workstation with a $35 Raspberry Pi 3.

You can, however, use these WebGL sites as a stress test of the Raspberry Pi. I had three different ways of powering my Pi and this experiment proved enlightening.

  1. A Belkin-branded 12V to 5V USB power adapter: This one delivered good steady voltage at light load, but when the workload spiked to 100% the voltage dropped low enough for the Pi to brown out and reset.
  2. A cheap Harbor Freight 12V to 5V USB adapter: This one never delivered good voltage. Even at light load, the Pi would occasionally flash the low-voltage warning icon, but never low enough to trigger a reboot. When the workload spiked to 100%, the voltage is still poor but also never dropped enough to trigger a reset. Hurray for consistent mediocrity!
  3. An wall outlet AC to 5V DC power unit (specifically advertised to support the Raspberry Pi) worked as advertised – no low-voltage warnings and no resets.