Author: Roger Cheng

Roger Cheng

Household Light Switch Teardown

As a change of pace from tearing down consumer electronics, today’s teardown is a simple single-pole, single-throw household light switch. This specific switch has been in service for many years and failed with the following symptoms: mechanically, the switch now moves freely without the tactile feedback it formerly had. Electrically, the switch is always closed leaving the attached ceiling light fixture illuminated. These switches are simple and failures are rare, so it was interesting to find out what the weakest point was in such a simple thing.

The top mounting bracket appears to be made from stamped sheet metal, and held to its body with a few bent metal fingers. A pair of pliers released those fingers and we could see the next layer.

Light switch 2

We see a sheet of something that feels like paper. The most obvious purpose is for electrical insulation, but it may have some fire resistant properties as well. This sheet was easily removed.

Light switch 3

As soon as that sheet was removed, we had our first hint: a loose spring sitting in the lower left corner which probably should be sitting somewhere else.

Light switch 4

Lifting the switch lever showed us the nub that used to be that spring’s home. The spring served as an elastic connector between the the plastic lever flipped by the user and the metal contact beneath which closes the electrical connection. When the spring broke, there is no longer any physical connection between these two parts, and the metal contact stayed closed due to gravity.

Light switch 5

The spring broke off leaving approximately 2mm on the swinging metal contact. There’s a chance that, if we removed the small tail, we could reassemble the switch and it will work again. However, by this time a replacement had already been purchased from the local Home Depot for $0.88 USD and installed. The replacement is not exactly identical due to literal decades separating them, but the basic principles are the same. It’s amazing all of the following could be manufactured, built, shipped and stocked locally for retail sales all for just $0.88.

Parts list:

  • Sheet metal:
    • Mounting bracket.
    • 3 ~1mm thick metal pieces for electrical contacts.
    • 2 thin sheets keeping the two static electrical contacts inside body.
  • Fasteners:
    • 2 screws to mount wire to electrical contact.
    • 1 screw to mount ground wire.
    • 2 screws to mount bracket to electrical box.
    • 2 screws to mount cosmetic faceplate.
  • Misc. metal pieces:
    • 1 spring (the part that failed)
  • Paper:
    • 1 insulator
  • Plastic:
    • 1 switch toggle
    • 1 switch body
Roger Cheng

Evaluating Microchip HV5812 For VFD Projects

[Emily] and I started our vacuum fluorescent display (VFD) project because there was an interesting unit available, with a look distinctly different from modern LED. We just had to salvage it out of an obsolete piece of electronics and figure out how to make it work. We now have a prototype VFD driver circuit up and running, and we can command it to light up arbitrary combinations of segments at arbitrary times from a Python program running on an attached Raspberry Pi. This is a satisfying milestone marking completion of our first generation hardware allowing us to transition to focusing on what to actually put on that display.

The first few experiments with VFD patterns confirmed that we really like how a VFD looks! As people who love to take things apart to see how they work, we enjoy all the components of a VFD visible through its glass case. Their intricate internals qualify them as desktop sculpture just sitting there, making them light up is just icing on the cake.

With this early success and desire for more, chances are good that we’ll embark on additional VFD projects in the future. For our first VFD project we chose to stick with generic chips for the sake of learning the basic principles, but if we’re going to start building more we should look at using chips designed for the purpose.

According to Digi-Key’s online catalog, there are dedicated vacuum fluorescent drivers available from Maxim and Microchip. None of Maxim’s chips are available in hobbyist-friendly through-hole designs, but two of Microchip’s three lines are. HV5812P-G is the 20-channel model in 28-pin DIP format, and HV518P-G is the 32-channel counterpart in 40-pin DIP format. Curiously, for ~50% more pins, the HV518P-G costs over double the price. So it made sense to start with the HV5812.

With data and clock pins for straightforward serial data input, it was designed to be easy to drive from pretty much any microcontroller. The only thing that caught my attention is that logic input lines are expected to be 5V input with a minimum of 3.5V required to be interpreted as logic high. This meant we couldn’t drive it directly from 3.3V hosts like a Raspberry Pi or an ESP32. We’d need level shifters or a 5V capable part like a PIC to act an intermediary.

It looks promising enough — and priced cheaply enough — to be a consideration for potential follow-on VFD projects. So we’ll add that to the Digi-Key shopping cart and see where things go from there.

Roger Cheng

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.

 

Roger Cheng

Prototype VFD Driver PCB Debugged

We now pick up where we left off narrowing down a problem with our prototype vacuum fluorescent display (VFD) driver board. We had determined that segment H was the key. When segment H was illuminated, everything else works as expected. But when segment H was dark, segments A-G all became dark as well.

ULN2003Since segments A-G were all controlled by a single ULN2003 chip, we started looking closely at every solder joint on that chip. We were looking for an undesirable solder bridge or other electrical connection to any wire relating to segment H, which was managed by another ULN2003 chip.

The two ULN2003 chips were immediately adjacent to each other, meaning A-G were pins 1-7 on one chip, and segment H was pin 1 on the next chip. The densely packed nature of these chips meant pin 1 of segment H was immediately adjacent to the emitter (E) and common (COM) pins of the ULN2003 controlling A-G.

When describing the symptoms, [David] correctly diagnosed the problem must be an electrical connection between segment H pin 1 of one ULN2003, and pin COM of the adjacent ULN2003. Using a probe we verified this was indeed the case – those two pins should have no connection but they are electrically connected. However, we could not find where this connection was taking place. No solder bridges were found and no accidentally soldered wires were found.

Eventually [Emily] devised a hack: because a VFD is not an inductive load, we didn’t really need the COM pin at all. It was only soldered to the board for physical mounting, that solder joint has proven to be more trouble than it was worth. To bypass the undesired connection, wherever it might be, it is easiest to clip off the COM pin from that ULN2003. Maneuvering a cutter within the packed space, [Emily] snipped off the leg.

After that, every aspect of our prototype VFD driver was fully functional as planned. [Emily]’s hack was totally unconventional, but very effective!

Roger Cheng

One Year Of Daily New Screwdriver Posts

When asked how to be a better writer, many successful writers give the same advice: start writing and keep writing. It doesn’t matter the topic or the length. It doesn’t matter if there is only an audience of one (yourself). Write. As much and as often as you can, write. There’s no guarantee that writing more will necessarily lead anywhere, but it is certain that not writing will not lead to success.

On a parallel front, I had been worried about my chosen path of independent study. Without an established curriculum or schedule, it was all too easy to lose track of what I’ve tried, what I’ve learned, and how I’ve improved as a result. To prevent this, and to keep myself motivated and accountable, I decided to start recording my progress in the format of blog posts.

Hence was born this blog site, NewScrewdriver.com. Named after an offhand reference made by Dr. Who about “inventing a new type of screwdriver” this was a record of my adventures and also a long term and continuing writing exercise. The very first post was about WordPress itself, because that’s obviously what I had to learn to set up this blog. The adventures went on from there. I described projects big and small. I documented significant advances and useless distractions. I wrote about new discoveries and popular knowledge that were nevertheless new to me. Some posts were packed with useful information, some were just mindless rants of a flailing man. But they had one thing in common: it’s what I had been doing with my time.

I eventually settled on a target length of 300 words – any shorter and it’d be difficult to have a whole story with a clear beginning, middle, and end. Any longer, and we see diminishing returns on the time it took to write and read. 300 words takes about an average of a half hour to write, and less than five minutes to read. It seemed like a practical size for the project.

A distressing number of internet blogs start with a few strong posts, then trail off into inactivity. (Sometimes they have only a single post!) I was determined not to let this happen to my own blog, but it took a conscious effort to keep things going. After some pauses and restarts, eventually I could keep up the pace of a post every three days, then a post every other day, then a post every single day. I was content with that pace. Some days I have successes that took multiple ~300 word posts to write up, and they will fill in the days when I was either struggling and had little to talk about, or fully occupied and unable to write.

Today I celebrate a milestone marked by a screenshot from WordPress blog dashboard: there has been a blog post every single day for the past twelve months. I expect that at some point in the future I wouldn’t be able to keep up the daily pace, but today I’m writing down a reminder for myself: I was able to stay with the program for a whole year. Hooray!

Roger Cheng

Obsolete Arduino Board Is Alive And Reading Analog Joystick

Learning Arduino has finally moved from a back burner to the front, and as a first step I finally unpackaged a years-old purchase of an Arduino Uno compatible board. Enough years have passed that particular board has become obsolete, but the Arduino ecosystem is still going strong so chances are good that I can still use the board to learn.

The first step with new hardware is always testing out some sort of a “Hello World” demo program to make sure the basics are working. When it comes to playing with electronics hardware, the popular choice is to blink a LED. This is such an entrenched thing that Arduino has designed a LED into their boards perfectly suited for the purpose, and my Arduino-compatible board has copied that arrangement.

Following the “Getting Started” guide for an Arduino Uno, I installed Arduino’s Desktop IDE. The basic example blink program was only a few clicks away, and an Arduino Uno was already selected as the target board type. Once I selected the serial port to use for communication, I was able to click on “Upload”. After a few seconds, I could see the test LED blinking on my board. It lives!

Success of that fundamental test gave me confidence to move on and add some hardware. I had bought some small joystick modules (*) for this purposes of building my own Arduino based controller. Like most joysticks, they are built around a pair of potentiometers which made them an easy match for Arduino joystick tutorial.

OSEPP Uno R3 Plus with joystick

As many reviewers warned in that Amazon product listing, these joystick modules are very sensitive to movement. Their electrical range of motion is a surprisingly small subset of their actual physical range of motion. In other words, the potentiometers reach their minimum/maximum electrical values when the stick has only moved barely a third or halfway into its physical range of motion. This will be good for quick reaction movements but not as good for fine pitched movement.

These joysticks might not be the best ones for the job of rover control, but they will work well enough for continued Arduino exploration.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

Finally Opening My Arduino Compatible OSEPP Uno R3 Plus

With my newfound motivation to get rolling in Arduino programming, I am finally going to open up the plastic blister pack of my OSEPP Uno R3 Plus. I must have bought this item when it was on sale somewhere, thinking I would get into Arduino programming but ended up letting it sit on a shelf for years.

OSEPP Uno R3 Plus blister pack

Today the product web page lists it as a discontinued product whose production ended almost three years ago in June 2016. The packaging backside pointed buyers to the url www.osepp.com/boards which is not even a valid URL anymore and returns a HTTP404 error page instead.

OSEPP Uno R3 Plus specifications

If this had been a proprietary product I would have been worried if I could even use it anymore. But since it was based on Arduino, an open source product, I was not as worried. Based on its name and physical appearance I guess it was a derivative of the Arduino Uno, which is still an active part of the Arduino product line in Rev3 form.

OSEPP Uno R3 Plus PCB

The exterior dimensions of the circuit board look identical, as are the mounting holes, in order to be compatible with the Arduino shield ecosystem. Comparing it against the standard Arduino Uno I see a few modifications elevating this product above a mere clone. The power jack looks the same but the USB connector is different. Its reset button has been moved to make way for a connector labelled I2C. I see four surface mounted LEDs in the same place as the standard Arduino Uno, which will be useful as I recall the Arduino “Hello World” blinks one of them.

The only thing I’m not terribly thrilled about is the fact the processor is a surface mounted chip instead of socketed DIP of the standard Uno. A socketed chip would be easy to replace if I should damage it in some way, with this surface mounted chip I’m pretty confident I’d need to buy a new board.

I see a little bit of manufacturing residue on the circuit board, possibly solder flux that was not completely cleaned off. That and a few other cosmetic blemishes did not worry me in regard to board functionality. It looks ready to go, so let’s plug it in and see what happens.

Roger Cheng

I Found My Motivation To Enter World of Arduino: Make Sawppy Easier

When talking to people about fun electronics projects, it has come to people’s surprise that I have yet to do anything with an Arduino. It is the platform of choice for introduction to hardware computing and how many people got started in this hobby, but for one reason or another I never went through that phase.

Generally, if I need something with computing power or network connectivity, I use a Raspberry Pi 3. If I need low-level control over precision timing, I use a PIC. Sometimes those two are paired up, like our VFD driver board project. An Arduino’s capabilities fit in between those two platforms, but as I already have proficiency in coding for a Pi and for a PIC, it doesn’t leave much motivation for me to learn Arduino. But it’s something I kept in mind, expecting that one day an Arduino’s beginner friendliness will be an asset for me to build a project with one.

That opportunity has surfaced!

backyard sawppy 1600

As I took Sawppy around to various events, I had many opportunities to talk with people who show interest in a DIY motorized Mars rover model. My own personal ambition is to make Sawppy autonomous, but not everyone shares that goal. I learned that many people would be content with a remote controlled rover. Furthermore, I’ve seen a lot of interest in parents who wanted to gauge if Sawppy is a good project to build with their children. And in this scenario, my SGVHAK rover software running on a Raspberry Pi is far more complex than strictly necessary.

For this audience, a simple Arduino-based rover control system would fit a niche separate from that of a Raspberry Pi rover control scheme. It will be less powerful, but will also be lower cost and more approachable as a learning exercise for beginners.

So for the sake of making Sawppy more accessible to everyone, I’m going to start investigation into an Arduino-based control scheme.

Roger Cheng

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.

Roger Cheng

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.

Roger Cheng

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 aiy.voice.audio 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.

Roger Cheng

A Close-Up Look At VFD Internals

When we first pulled the vacuum fluorescent display (VFD) from an old Canon tuner timer unit, we can see a lot of intricate details inside the sealed glass. We had work to do that day – probing the pinout and such, but part of its overall allure comes from the beauty of details visible within. It is still something of interest, I just had to remember to bring my camera with a close up macro lens to take a few photos.

VFD under macro lens off

One of the reasons a VFD is so interesting to look at is the fact the actual illuminating elements sits under other parts which contribute to the process. Closest to the camera are the heating filaments, visible as four horizontal wires. This is where electrons begin their journey to trigger fluorescence.

Between these filaments and individual illuminating segments are our control grids, visible literally as a very fine mesh grid mostly – but not entirely – built on a pattern of hexagons.

And beyond the control grids, our individual phosphor coated segments that we control to illuminate at our command using our prototype driver board. (Once it is fully debugged, at least.) These phosphor elements are what actually emits light and become visible to the user. The grid and filament are thin which helps them block as little of this light as possible.

Fortunately an illuminated VFD segment emits plenty of light to make it through the fine mesh of grids and fine wires of filament. From a distance those fine elements aren’t even visible, but up close they provide a sophisticated look that can’t be matched by the simplicity of a modern segmented LED unit.

VFD under macro lens on

Roger Cheng

Salvaged VFD Power Supply And Debugging

Our first system integration test of a salvaged vacuum fluorescent display (VFD) and our prototype driver PCB was a success. At least going by our initial target of having our VFD segments illuminated and cycling through a test pattern to verify things are not stuck always on or off.

Once we had that basic level of functionality, [Emily] started working on the power supply side of the system. We have an original transformer salvaged from the same device which outputs multiple AC voltages. The first is a 2.5V AC line we could use directly on VFD filament. After that, Emily salvaged a few more components to deliver the ~30V DC we need for control grid and segments, and the ~24V DC we fed into a MP1584 buck converter to get 5V DC for filament bias and micro controller logic power.

VFD on transformer

We’re very close to a complete power solution for a VFD project, but not quite there yet. When we added a Raspberry Pi 3 to the mix, its power demand was too high for this system to handle. Power sagged to 4.2V and the Pi entered a power brown-out reset loop. We’re not sure what’s wrong with this setup yet, but in the meantime we connected an alternate 5V DC power source to look at how the rest of the system behaves.

This allowed us to see a problem in our prototype driver board. I had a new test pattern generated with the help of my tool created in Google Sheets, but the test program did not display as I expected. After some time sending various diagnostic patterns to the VFD, we figured out the key to the situation is segment H.

NEC VSL0010-A VFD Annotated

Whenever segment H is illuminated, everything else functioned as expected. But if segment H is dark, segments A-G are all dark regardless of commanded pattern. Segment I and J are unaffected.

Once this was determined, we ran a test pattern where H is commanded to be dark and everything else should illuminate. The test pattern is the same for every segment, so the circuit would be at a steady state for us to probe with a meter as the PIC cycled through segments.

Using segment A as an example, we probed to verify its output pin from PIC (RC0) is low as expected. We then traced that signal to the ULN2003, whose corresponding input pin is low as expected. With input low, the corresponding ULN2003 output pin should not be tied to ground. Which means we expect VFD pin for segment A to be sitting at near 30V DC due to a pull-up resistor.

This is where we went off script, for VFD pin A has been pulled low. Unplugging the wire between ULN2003 and VFD allowed the segment to illuminate. This narrows down the scope of our problem: it has something to do with that ULN2003 chip, but we ran out of time for tonight’s SGVHAK session before we could narrow it down any further.

To be continued!

Roger Cheng

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.

Roger Cheng

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.

Roger Cheng

Create VFD Bit Pattern With Help Of Google Sheets

With a successful integration test of our salvaged vacuum fluorescent display (VFD) we proceed to a few other tasks. On the hardware side, we’ll need to simplify our power supply situation. Our test had three separate AC plugs, we only really need one. We’ll also need to transfer what’s on the breadboard to a prototype circuit board.

On the software side, things are less clear because we’re still coming up with ideas on what to do with a salvaged VFD. Our very simple PIC driver code merely controls a pattern of bits, each bit representing a segment to be illuminated. This gives us a lot of flexibility but so far these bit patterns have been created using pencil and paper and quite time consuming. Once we have a project in mind we can write code specific to a theme, but until then it’s wide-open bits.

Well, at least we can streamline the pencil and paper system somewhat. The logic is not difficult, just time consume, and should be easy to automate. I started by creating a HTML form and laying out checkbox controls. I got as far as designing a JavaScript structure for checkbox click events when I realized everything is on a grid and looks a lot like a spreadsheet.

That realization led me to put my basic HTML and JavaScript on hold and switch to investigate what I can do in Google Sheets. The key that made it all possible is the BINTOHEX() function that reads a number, interpret it as binary, and translate to hexadecimal. This is the core functionality for my pattern generation and I was able to build everything else around it.

Here’s the initial build, with a fully populated grid of checkboxes and a test pattern for me to verify things were working.

VFD Pattern tool - full checkboxes

Once verified, I deleted the checkboxes that didn’t have a corresponding segment. This array now properly corresponds to our specific VFD.

VFD Pattern tool - customized checkboxes

Now creating a bit pattern is as simple as checking on the segments I wish to have illuminated. Here’s the pattern for “12:00”, the canonical Hello World for a time-based VFD display.

VFD Pattern tool - 12.00

I thought it would be fun to make this available for anyone to play with, but that requires keeping the sheet and its formulas fixed while allowing people to check and uncheck boxes. Unfortunately “view only” sharing does not allow checkbox manipulation, and “editable” sharing also allows modifying the sheet formula. Until I figure out how to do what I want, it was shared as “View Only” to the general public.

 

Roger Cheng

Integration of Salvaged VFD and Prototype Driver PCB

The time has finally come to put our salvaged vacuum fluorescent display (VFD) together with the prototype driver printed circuit board (PCB) we built for it. First we gave our VFD a little layer of protection. The individual pins of the VFD are small and seemed rather fragile. And as they went into a vacuum sealed chamber we had no means to repair, if one pin should break that would mark the end of our fun.

Fortunately, when we salvaged it from its previous home we noticed that those pins were quite strong in union. A single pin is fragile, but all twenty pins together was pretty strong. So we’ll solder up one of our cheap prototype boards to these pins just for the sake of holding them together. It was a bit tedious getting all the pins to line up. Two more boards were used as spacers to give us the desired distance.

VFD pin alignment

Once lined up, the VFD was soldered in place.

VFD pins in perf board

As anticipated, the assembly is now much more robust. Now we can work with this module with a lot less trepidation: if we should break a pin now, the break should stop at this PCB where we could still recover, not break all the way to VFD glass where we couldn’t.

We still had a lot of usable pin length remaining, so we left this unionizing PCB alone and soldered another one where we’ll actually attach wires and headers.

VFD second PCB

While this soldering work was underway, a breadboard was populated to test our design for interfacing our driver PCB and the VFD. Each VFD grid and segment wire received a 10 kilo-ohm pull-up resistor to the 30V line, and path cords were installed to map pins from our generic driver board to this specific VFD as per the pinout diagram we drew up earlier. Now the VFD, with its new more robust pins, should plug right in.

VFD interface breadboard

Finally, power delivery which is far more complex than what a LED project requires. This initial integration test had three different power sources. The power transformer we salvaged alongside this VFD delivers (among other voltages) the ~2.5V AC we need for our filament. With a few rectifier circuits, it should be able to deliver the other DC voltages we need as well, but we weren’t going to worry about it until we got this test working. In the meantime, a HP inkjet printer power supply delivered the 30V DC for grids and segments, and a Raspberry Pi delivers the 5V logic power as well as I²C control signals.

VFD integration test rig

We plugged everything in and… it lives again under our control!

Roger Cheng

Prototype VFD Driver Tested With Placeholder LED

PIC16F18345 VFD driver PCB

Once I had assembled our first prototype vacuum fluorescent display (VFD) driver circuit board, it’s tempting to connect it right up to our salvaged VFD and bask in its glow. But that would have been premature: there were bugs still to be ironed out with potential for fatal errors to damage or destroy our one and only salvaged VFD.

The first tests were what we used to test our bread board prototype: drive a 4-digit 7-segment LED, a Lite-On LTC4627-JR from my earlier PIC display driver project. From there I could verify 8 of 11 segments on this driver board functioned as expected by a demo program that constantly flips between two patterns, one spells “Hello” and the other “Ahoy”.

I then tested the I²C capability with a small update, changing the second pattern from “Anoy” to a very mutilated “MLE”. (It’s hard to do “M” on 7 segments.)

These experiments exposed a few minor bugs, just as tests were supposed to. After they were fixed I expanded my test with a second LTC4627-JR for eight total segments. I also expanded my use of I²C by continuously updating all digits from Raspberry Pi to create a text marquee. This experiment exposed some timing issues that is visible as a slight lag just as the “u” in “thank you” came up on screen.

That lag was diagnosed to my code inside a timer interrupt service routine (ISR). On a simple chip like this PIC, a hardware interrupt signal could not interrupt another ISR already in progress. So when my code inside a timer ISR grew beyond a certain point, it started interfering with timely response to hardware interrupts necessary for I²C communication. The solution is to put my timer ISR on a severe diet, moving almost all of its bulk elsewhere so that I²C handlers could run with minimal interference.

Once the software problems were sorted out, I started experimenting with the flexibility given by this project’s design decision to keep PIC code simple. It meant I could play with patterns that have nothing to do with displaying letters or text. I decided to try a pattern that keeps a single lighted segment running through the display in a figure 8. When cycled through all digits like a text marquee, it gave us a neat looking wave. I look forward to more experiments in driving a multi-segmented display in unusual ways.

Roger Cheng

Assembling Prototype VFD Driver PCB

PIC16F18345 VFD driver PCBIn addition to exploring the idea of aggressively packing chips densely, there were a few other design considerations in building our prototype driver PCB.

Why I²C?

When I was tearing my hair out trying to figure out why a tried-and-true piece of template code has stopped working, I was sorely tempted to move to some communication protocol other than I²C… good old TTL Serial always looks good whenever I run into a problem.

The answer is voltage compatibility: I want my driver board to be capable of running at either 3.3V or 5V, which is easy to do with an old 8-bit chip like the PIC16F18345 I’m using: give it power anywhere in its specified range (and probably a bit beyond that range) and it’ll happy run. But this doesn’t necessarily apply to whatever my driver board will accept commands from. Fortunately, I²C was designed from the start to accommodate devices that work off different VCC levels. So something like a Raspberry Pi (3.3V) can communicate with my PIC. (5V).

Pin Assignments

In addition to moving the decoder output pins so it could be placed immediately adjacent to my PIC, I also took advantage of my particular PIC’s feature of Peripheral Pin Select (PPS) by moving the I²C pins (handled by Master Synchronous Serial Peripheral – MSSP) from their default to RA4 & RA5 for easier routing on the PCB and easier data writes in my code.

Pin Isolation

This is the first time I planned to use pins RA0 and RA1 on a PIC16F18345 project. I usually avoid them because they are used as in-circuit system programming data (ICSPDAT) and clock (ICSPCLK) pins. They’re perfectly usable outside of this scenario, but they must be disconnected from the rest of the circuit during programming. In this case, it meant I had to put in two jumpers that are removed during programming. The jumpers are installed exactly where my PICkit 3 programmer would attach, so there’s no way for me to forget to remove them when reprogramming this chip.

Wires From CAT-5E Network Cable

Even with all these concessions to easier routing on a prototype PCB, there will still be an unavoidable nest of wires. In order to keep things tamed, I harvest my spool of CAT-5E network cable for wires that are thin and rigid. Thin wires help me fit more wires in a small volume, and rigid wires stay where I’ve put them. In addition to being affordable and easily available, the four twisted pairs of wires give me eight different insulation colors to help me keep track of which wire goes where.

Roger Cheng

Chip Packing Experiment On Prototype VFD Driver PCB

While we were building a breadboard prototype for our VFD driver, we weren’t terribly concerned with chip layout as it was largely constrained by the practicalities of a bread board anyway. Once we start thinking about transferring it to a PCB, however, we had more flexibility to be creative. The prototype printed circuit board is a grid of through-holes that we can use in any way we like. How shall we abuse this power?

While looking at how wires were run on our bread board, I noticed that there were a few pins that were perfectly aligned from one chip to the next. Placing the decoder output on PIC pins RB4, RB5, and RB6 lines them up perfectly with the input pins of 74138 decoder. As for the decoder output, six out of eight pins were directly lined up with a ULN2003.

Chip pin alignment

This allows some fairly straightforward wiring solder as these wires will not cross over each other and won’t tangle up and make a big mess. By itself that is valuable, but we were tempted to go one step further: how about we eliminate the wires entirely and jam those chips together? If they share the same PCB through-hole, that would eliminate wire soldering entirely.

It sounded good in theory, but in practice the chips are just a little too large for us to fit them three-abreast. I could push my decoder up against my PIC, but couldn’t push the Darlington array alongside the decoder as well. This is probably for the best – there’s value in having the ULN2003 lined up with its siblings.

Chips tightly packed on PCB

We may learn in the near future why this is a bad idea, but it’s all part of the fun: trying things and seeing how they work. (Or not, as the case may be.)