Palo Verde High School in Tucson, Arizona had an excellent Industrial Arts program. Years before, in the early sixties, the Tucson Independent School District had the foresight to offer training in many industrial trades, building our school with an external set of buildings for shop classes. We had auto, wood, welding, sheet metal, machine, and electronics shops. They didn’t call it a “magnet” school back then, they just started building them that way.
At registration, in the onset of my freshman year, I rushed across the cafeteria to trade computer punch cards with a teacher and enroll in the rotating program of courses that in my case started with electronics.
The semester began with lots of training on basic circuits followed by experiments at the school’s Lab-Volt benches. Near the end of the quarter, with all the basic stuff accomplished, it was time to construct our final project: An LED digital clock. Our teacher, Mr. Reynolds, explained that after our parents ponied up the cash, he’d order a clock module kit for each student from Digi-Key. Mom agreed to fund my endeavor, and I agreed to build her a digital clock!
I knew about Digi-Key already. Back then, the electronics magazines like Popular Electronics had mail-in cards inserted in them where you’d circle a few numbers, send them back to the publisher, and the corresponding companies would send you their catalog or information on. Free stuff in the mail! Yes, I was already getting the Digi-Key catalogs, but this would be the first of many components I’d actually receive from them.
The kits themselves were pretty basic. You’d get a National Semiconductor MA1023 clock module, a transformer, and four pushbutton switches. What you did from there was up to you. Assembly involved soldering and wiring the switches and transformer to the module and then wiring the transformer to an AC cord. My personal customization was to add a speaker and volume pot to make it an alarm clock.
Mr Reynolds required that we make or modify some kind of enclosure for the project. I think most students used the standard plastic enclosures with metal lids that they drilled, cut, and filed to suit.
For my enclosure, I chose to bend some yellow sheet plastic into a three sided C-shape. First I drilled the holes and made the cutout for the display bezel. Then I used a plastic bender/folder fabricated by our sheet metal and drafting teacher, Mr. Mentzer. That was made from a refrigerator defroster heating element and some heat retardant panels. At home, I hand crafted the pine sides using a jigsaw, router, and belt sander.
I was pretty proud of the work I did on that early project. Mom used it for years, and it still works great today.
Yep, I go both ways. My penchant for hardware was fostered in the 3rd grade. My uncle got me a “crystal” radio kit for my birthday.
I also spent many after school hours at a friend’s house working on the Radio Shack electronic X-in-one kits. The first being his 100-in-1.
Many others followed: My own 10-in-1, then a 150-in-1, and so on.
At the time, software was not a thing for kids my age. My interest in electronic circuits did get me looking at Popular Electronics magazine at the city and Jr. high school libraries. Eventually, I convinced my mom to get me a subscription for myself. I’d read those monthly issues in great detail, and I’d pick up old issues at bargain book sales.
Next came the subscription to Radio-Electronics.
My freshman year in high school finally provided me access to a TRS-80 Model I after school. The data processing classroom had two, and certain respectful students were allowed to learn on them until the janitor came to clean the room and lock the door at the end of his shift. I went out and plunked down $5.95 plus tax to get this manual so that I could start learning BASIC.
I learned BASIC at home, with the computer, but then came into the classroom to try my programs. I also tried some programs out at Radio Shack, but would usually get shooed away by the sales team before I got very far.
It wasn’t too long before I started hearing about the ZX80, and then the big price drop happened at the introduction of the ZX81. I ordered an assembled unit and 16K memory expansion for about $150. I had my first computer.
From there, I got into the computer magazines: Compute! and Byte.
At that point, I was of both worlds: Hardware … and Software.
I still tend to work right there, right at the bare metal interface of the two worlds. That duality always comes up in my job interviews. When I saw the following video for the first time, I realized that I’d forever remember it in every interview going forward.
I designed it in high school. I was working on some electronics projects and wanted to put a logo on them. This is what I came up with. The idea is basically an M for Mulanax with motor commutators around it. I was also thinking sturdy robot “hands”. The original color scheme was green and yellow.
I designed it so it could be stenciled in one or two steps. I also concentrated on using unit based layout and line thickness. At some point I reduced the outer radius by one unit, and narrowed the M. I remembered hearing that concentric circles and arrows emanated precision.
When I was working to upload it for the blog site today, I realized it looked a lot like a stove burner. Hey! Some custom colors to match the site palette, and here we are.
Each pixel includes three internal LEDs (a red, a green, and a blue), along with a built-in controller. The controller can set each of the three LEDs to one of 256 brightness levels.
The 2812s operate from a 5 volt supply, and each has a data-in and data-out pin for the serial control protocol. The components are daisy chained by their ins and outs with only 3 wires needed between each pixel. I think less wiring means less chance for wiring problems.
I picked BTF-LIGHTING‘s IP65 strips due to their low cost and waterproof design. I really like the simplicity of the flexible strip.
I’m not sure if the components they use are actual 2812s, but they are compatible with the protocol. I’m using the black, 30 pixels per meter variety in this project. The strips can be cut at the pads and have a thin, double sided tape backing.
The layout was carefully planned with a few constraints from the old display. I wanted to keep a similar star size, have pixels at the tips, and avoid overlapping pixels in the middle of the star. I used a quick Scratch program to verify my layout ideas using “turtle” or “pen” graphics. I decided on a strip of 45 pixels, and cut it into five 9-pixel sections. Each section forms part of a ten pixel chord that includes the start of the next strip.
The BTF strips need a support structure to hold them in the star shape. I decided to design my own plastic strip that could be 3D printed, then assembled into the star shape. The ends of the strips snap together and have slots to accept zip-ties that securely hold the pixel strips in place.
I found a mail-order supplier on TreatStock and had my parts printed in ABS plastic. I unexpectedly specified 20% infill on the order, but that worked out OK with the strips being somewhat flexible for the woven assembly I wanted.
There are plenty of choices for LED pixel controllers. For me, the Raspberry Pi works great. I have a Raspberry Pi model 3 B, so I’m using it.
I’m running Raspbian (AKA Debian Stretch) Linux. The Pi is inexpensive, and out of the box, it offers a bunch of learning opportunities with free, open source software and development suites. Included HDMI, USB ports, WiFi, and Bluetooth make this a stand-alone computer that runs from a 5V wall-wart.
I’m using Maniacal Lab‘s awesome BiblioPixel light programming system to run the display. Their open source Python3 code library is hosted on GitHub. The package supports multiple pixel types, is portable to multiple operating systems, and comes with a lot of example animations. They support pixel layouts for one-dimensional strips, two-dimensional matrices and disks, as well as three-dimensional cubes. The animations are customizable via project files written in YAML or JSON. I was able to start with their animations very quickly using their built in strip layout. I had my own animation ideas for this star, and was able to program my own animation in Python. More on that later.
There’s one more component between the Raspberry Pi and the pixel strips. That’s Manaical Labs’ AllPixelMini.
It’s a USB device that handles the serial protocol that updates the pixel colors. This frees the Raspberry Pi of that CPU overhead and allows other real-time event driven software to co-exist on the system (audio, mouse, GUI, etc.)
In my setup, the AllPixelMini provides just the data signal (green wire) to the pixel strips (ignore the red wire above). A ground connection (white and black wires) is also required to make sure all the ground levels are common between the power supply, LEDs, and AllPixelMini. The All PixeMini gets it’s power (and ground) via the USB cable.
I plan on using the same connectors to daisy chain the stars and other display components when I scale this up.
Each 9-pixel strip is wired to the next with a 3-wire connection for 5 Volts, ground, and data.
The strips have solder pads on the back that let you keep the waterproof covering stuck to the LED side.
I also added adhesive lined heat-shrink tubing after soldering to keep the connections waterproof for outdoor use.
Each star of 45 pixels draws 1.66 Amps at 5V with all the LEDs of each pixel at full brightness, and 32mA in the quiescent “off” state. I’m using a 60 Amp, 5 volt supply driving the 5V rail of the LEDs directly (black and red wires connected to power supply above) without feeding power through the AllPixel Board. There’s plenty of power left for expansion, and the fan on the supply does not turn on with this light load.
When I first imagined the star display, I was thinking of the way firework streamers looked. You’ve probably seen animations that use particle systems to simulate fireworks. The firework explodes with glowing particles being emitted from a point. The particles stream down, flicker and fade before they burn out. This animation is similar.
The Emitter() animation is a one dimensional particle system for BiblioPixel. The animation is written in Python. My Emitter() class inherits from BiblioPixel’s Strip() animation class. You can find my GitHub repository here. Manaical Labs has also included it in their repository.
The Emitter() class has lots of parameters to control the particle effects, and the source code contains docstrings describing the parameters. Definitely check that out. The parameters can be overridden in BiblioPixel’s YAML or JSON project files. Here’s emitter_demo.yml for the demo in the video.
Each strip can have multiple emitters with programmable positions and velocities. Particles can be emitted in either or both directions. Moving emitters and particles can wrap at the end of the strip. The emitters can be invisible or have color.
Emitted particles move away from the source starting at the full brightness of a color that’s randomly selected from a palette. The brightness then varies in a random manner. The random variations are chosen from a list built at class initialization. The default settings should make the particles “sparkle” and fade. The distribution of brightness variations is adjustable.
The Python code for plotting the histogram is here.
Individual particle velocities are random with adjustable constraints. Particles have a range and won’t go beyond a specified distance in pixels. from their emission point. At a given frame step, an emitter can start multiple particles. The starts_at_once parameter controls how many can start. The starts_prob parameter controls the probability that a particle will actually start. The variance in particle velocities lets particles overtake each other as they travel down the strip. Particles can hold a brightness level below zero and then randomly come back up above zero becoming visible again. Another effect is flares. The flare_prob parameter specifies the probability that a particle can immediately return to full brightness before resuming random brightness variations.
The particles are rendered onto the strip “screen” at each animation step. A loop goes through all the strip’s pixels and sees what particles or emitters are visible from that spot. If no particles are visible, the background color is used. The aperture parameter controls the “visibility” distance. If the distance to a particle is outside the aperture distance, it does not contribute to the pixel. The colors of the visible particles are then blended based on their distance to the given pixel. Particle positions, distances, and apertures are all floating point values. Small aperture values can cause blinking when a particle or emitter becomes invisible between the pixel locations. Larger aperture values will spread a particle’s color across multiple pixels.
Check out this part of the star display demo to see all the parameters in action:
I spent a bit of time this morning trying to locate my copy of Forrest Mim’s Engineer’s Notebook. I was intending to write about that excellent publication being influential in my decision to become an engineer. I never did find its hiding spot. While I was hunting, I got to thinking about something else:
What do I really want to concentrate on for this new blog?
Do I want to detail my engineering history? i.e. just make a beefed up resume? Or, do I want to concentrate on the new stuff? I think I ought to lean toward the new stuff.
That said, the history of “me” really does pertain to what I’m working on now. The skills I’ve honed over time always lead me to believe I can approach a new task borrowing at least a little from what I already know. So it’s easy to say: “I can do that!” or, “I want to do it differently this time”. I’m sure I’ll get to talk about the old stuff as it comes up. That’s in my nature. I just don’t want to write only about history. I want make sure to write about now.
P.S. There is a nice write-up on the Mims notebooks over here.