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’m looking for and preparing for my next career opportunity. My school and work experience are listed on LinkedIn.
I’m not one to just let the wind blow me to the next place. I want to put in some thought, so I can apply my efforts to move toward something that is going to continue to be relevant.
Where I am
My chosen career is computer engineering. To me, that’s designing computer systems that people and businesses need to get their tasks done. The design discipline has two main aspects: computer hardware (electronics) and computer software. I’ve gained lots of experience in both, and I definitely want to keep close to my experience base. Relevant experience will be what’s most useful to my employers in quickly getting their project completed.
Lots of my hardware designs have required software or firmware to complete the product, and most of them have required me to write some kind of functional test software before hand-off to other teams or the customer. Here is a subset of my skills that I see as being useful to employers going forward:
There’s been a shift in consumer hardware that has already affected my career. I took a while for it to sink in, but the shift to a smaller set of mass produced mobile platforms (phones and tablets) instead of individually engineered devices has translated to a smaller number of hardware products being developed. The smartphone is the hardware “hammer” that gets applied to most problems today. The phones take over as the general purpose computer and it’s chosen as the ready-made solution in lots of cases.
Where to next?
Being involved in the engineering of phones and phone chips has been good for me in the last few years. That might continue for a while longer, but the competitive field is narrowing. It does appear that there is increased interest in IoT hardware to connect to those phones. The devices are medical, industrial, and some home products.
So with the changes, I’ll probably have to shift focus a little. These are some adjacent engineering specializations that are in demand and appealing to me:
Cloud hardware and software
Blockchain and network security
Software defined radio
Finally, there are things that I’ve been interested in, but require a complete shift out of the computer engineering field, but hopefully not too much additional training:
3D mechanical design
Drone 3D surveys
I’ve been looking into inexpensive ways to train in all these fields and I’ve progressed well into a few of them. I’m not concentrating on any one thing too much as I’m not really sure where I’m going to get traction. My future posts to this blog will detail my progress. If you have any suggestions, or know anyone who is blogging about the same things, I’m open to hearing about it!
I took the image for this blog post at George Washington’s Mt. Vernon home in 2006.
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.