Notes on Commodity DRV8833 Breakout Board

Having read through the datasheet for DRV8833 DC motor driver IC, I was optimistic that they would be a good choice to control DC motors on the TT gearmotors I have installed on Micro Sawppy Beta 3 (MSB3) rover. DRV8833 operating voltage range of up to 10V is a much better fit for these 3-6V motors. Compared to the classic L298N motor controller with its 4 to 45V range. The lower voltage handling requirements, as well as being a much newer design using modern power management techniques, means a DRV8833 breakout board is far more compact than a L298N breakout board. Something clearly visible in this side-by-side picture. Physical volume is an important consideration when fitting electronics inside a little rover.

Side by side size comparison of L298N and DRV8833 motor control IC breakout boards.

For my first round of experiments, I bought a batch of 5 DRV8833 breakout boards from the lowest bidder of the day on Amazon (*) I’m sure a different day will have a different lowest vendor when we issue a query for DRV8833(*), because these breakout boards seem to be commodities offered by many different vendors. We also see this particular design from many vendors on AliExpress. I noticed two or three very popular designs for a DRV8833 breakout board. I have no idea where this particular design came from. If the same factory is supplying all of these vendors, or if the design has been cloned by multiple manufacturers. Whatever the history, I see enough quantity to give me confidence these boards won’t disappear overnight. We’ll see if I’m right!

Incorrect instructions shown on some DRV8833 product listings.

In this particular product listing, one of the pictures serve as a rudimentary reference manual for the board. I was suspicious of these instructions so I probed this board to determine the circuit for myself as I did for the L298N board. I’m glad I did! The instructions had swapped the “FAULT” and “SLEEP” pins for reasons unknown. Fortunately, those pins are optional so most users (including my intended use) won’t be affected.

There are only a few supporting components on this board. From the DRV8833 datasheet I expected three capacitors and they are clearly visible. I also see two resistors and a LED. The LED was not on the datasheet, it was a bonus feature to indicate power supply is present, along with its 4.7kOhm current-limiting resistor. The final resistor is a 47kOhm pull-up resistor for the SLEEP pin, by default pulling it high to enable the board and giving us the option to leave the breakout board’s (SL)EEP pin unconnected.

Back side view of a DRV8833 breakout board, showing the J1 trace that can be cut to disconnect pull-up resistor and allow control over sleep functionality.

For applications that want to assert control over sleep/enable themselves, there is a provision on the back side of this breakout board. Cutting the trace on J1 will disconnect SLEEP from the pull-up resistor, opening up the pin to external control. If we should change our minds afterwards, we can solder across J1 pads to reconnect the pull-up resistor.

No such provisions exist for current chopping control. DRV8833 offers the option to limit maximum current by putting current-sensing resistors on the AISEN and BISEN pins, but this particular breakout board design connected those pins directly to ground without any provisions to add current-sensing resistors back in. Applications that want current chopping will have to go elsewhere.

Remainder of the board was fairly straightforward, once we figure out the pin rename mapping. This board labelled its pins IN1-4 and OUT1-4 following precedent of L298N, instead of the names in the DRV8833 datasheet of pins 1 and 2 for channels A and B. For those that prefer this information in schematic form, here’s what I drew up after my probing session for this board to guide my first experiment putting one to use:

Schematic diagram for a popular type of DRV8833 breakout board.

Window Shopping DRV8833 DC Motor Control IC

It was a pure accident that I stumbled across the DRV8833 DC motor control IC. After a quick comparison against my original candidate TB6612 I think some DRV8833 modules might actually the better choice for my micro Sawppy rover project. Its required control signals are an ideal fit for the MCPWM peripheral on the ESP32 I planned as my rover brain. Though note not all models of the ESP32 line has MCPWM peripherals, for example it appears to be absent from the ESP32-S2.

The DRV8833 is less capable than the TB6612 in some ways. For example, the maximum voltage is listed as 10.8V which is lower than the 15V listed for TB6612, and far short of the 45V listed for a L298. But TT gearmotors are typically listed with a maximum voltage of 6V, so I should be fine. I was surprised that the amperage rating isn’t much lower, with 1.5A typical and 2A peak that should suffice for TT gearmotors. And if I need additional current carrying capacity, the DRV8833 is explicitly stated to be capable of both output stages working in parallel to double the maximum current. The L298 datasheet also explicitly listed parallel operation as an option, but the TB6612 did not.

Like the L298, the DRV8833 has provisions for current-sensing resistors between AISEN and BISEN pins to ground. But unlike the L298, the DRV8833 will actually read their voltage to limit maximum current output. The current-sensing resistors are a whole world into themselves. They work best when placed close to the IC because that minimizes variation introduced by PCB traces. But if they are close, they will be in close proximity to heat generated by the IC, which will change their resistance. Quite a few variables need to be juggled for it to work right, so I’ll probably choose to opt out of current limiting and connect those pins to ground. Fortunately the chip’s own overcurrent protection circuit works independently and will activate with or without external current-sensing resistors.

All four control pins, two for each stage, have internal pull-down resistors. Thus this chip is always in a defined state and we don’t have to worry about any particular startup sequence. Whether power arrives first or control signals arrive first, the chip will work in a known way. There are two more input pins, one to control sleep and another to signify fault. The fault signal is open-drain which would make it compatible with a lot of different circuits, but I might not have ESP32 input pins to spare for detecting fault conditions. I won’t worry about low-power sleep (at least not yet) for micro Sawppy, and in that case the recommended procedure is to pull it up with a 25-75kOhm resistor.

In addition to that optional resistor, there are three required capacitors, but no external diodes are required. Looks like the diodes to handle back-EMF from inductive loads are built in which is great news. It makes for a pretty short list of external support components, but I still don’t plan to use the chip directly. The first reason is that I have many options for breakout boards. From high quality Adafruit #3297 to the lowest bidder of the day on Amazon.(*) For low quantities it’s worth a few extra bucks to pay for an already-assembled breakout board.

The second reason is that I can’t meet proper installation requirements for the more capable DRV8833 variants. As is typical, the DRV8833 is available in several chip package formats. I was surprised to see that one of them had a much lower rating for typical amperage, a third of the others. However, peak rating stayed the same, so I suspected it’s not a limitation of the chip itself. Further reading (section 10.3.1) confirmed that maximum current of a DRV8833 is a direct function of heat dissipation and the lower-rated chip package lacked a heat conduction pad present in the others. (TI calls it PowerPAD.) Thus soldering a DRV8833 correctly requires reflow soldering. I would have to pay someone else to handle it, or buy my own reflow setup, but that’s a concern for the future. Right now I can start with some cheap breakout boards.


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

TB6612 Vs. DRV8833 DC Motor Driver ICs for ESP32 Micro Sawppy

While researching TB6612 DC motor driver IC breakout boards on Amazon, my results list actually had more breakout boards built around the DRV8833 (and claiming TB6612 compatibility) than actual TB6612 boards. So I tried performing an Amazon query for DRV8833(*) and saw I had far more options in that category. This may change in the future as worldwide silicon supply & demand varies, but that’s the situation as I type this. I didn’t explicitly set out to find yet another candidate to replace my L298 motor driver, but since I stumbled across it, I decided to spend a bit of time to take a closer look at the DRV8833 by Texas Instruments.

First things first: the claim of TB6612 control logic compatibility is wrong. Well, technically they are compatible for applications that are only interested in powering their motors only in full forward or full reverse, but that is not realistic. Such applications would not bother with a motor control IC and would directly use some MOSFETs or even relays instead. For real motor control applications, I’ve seen two different methods to interface with the classic L298 motor control IC. TB6612 is logic compatible with one method, DRV8833 is compatible with the other method, and they are not compatible with each other.

TB6612 requires three pins: two digital pins to control behavior (forward, backward, brake, or coast) and a PWM pin to control magnitude of that behavior. DRV8833 only accepts two pins to control behavior and modulation is done by rapidly pulsing one of those pins to switch between states. Partial throttle forward, for example, is done by rapidly switching between forward and coast states. DRV8833 does not have a dedicated PWM pin like the TB6612, and the closest counterpart to a L298’s ENABLE pin is the nSLEEP pin on a DRV8833 but that pin is unsuitable for modulating velocity. The first problem is that there’s only a single nSLEEP pin for both motors, and secondly waking up from sleep requires ~1ms making smooth motion difficult if not impossible.

In general, using two pins instead of three is an advantage when we are constrained by the number of pins available, and the ESP32 certainly has that problem. However, the tradeoff is that DRV8833 requires two pins capable of generating PWM signals per motor, whereas TB6612 only requires one. This would be a concern for microcontrollers with limited PWM peripherals, but the ESP32 literally has more PWM peripheral outputs than it has usable pins.

Looking specifically at my micro Sawppy rover application, the picture of pin allocation is not quite that straightforward as (2 pins * 6 wheels = 12 pins) versus (3 pins * 6 wheels = 18 pins). In typical operation, all the wheels on one side of the rover will be traveling in the same direction, so it is possible to share the direction control pins across three wheels on the same side of the rover, cutting it down to 10 pins instead of 18. Plus if I make the rover front-back symmetric I have an additional option to share the PWM control signal across front and rear wheels, which cuts pin count down to 8. But while DRV8833 can’t share pins across wheels on the same side, it can also benefit from front-back symmetry cutting its requirements down to 8 pins as well. A tie!

Clearly there are many tradeoffs I can make with motor driver arrangement and control, depending on how many PWM peripherals are on a particular microcontroller and how many pins it has to spare. For my first iteration I like the idea of having independent control over each wheel, even though right now I’m not sure how it would be useful. Once I get that working (or learn why I can’t) I’ll look into trading off independent control for reduced pin count. So the current plan of record is to use two PWM pins for each of six wheels, driving DRV8833 DC motor control ICs.


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

Window Shopping TB6612 DC Motor Driver IC

The cardboard backing for my latest experiment was never going to be the final arrangement, and neither are the L298 motor driver mounted using twist ties. I started experimenting with them because they were the classic, a known quantity, and widely available. But I would have expected technology to move on, and I found confirmation in this Hackaday article talking about the TB6612 motor driver IC as a replacement for those venerable L298.

I pulled up the data sheet published by manufacturer Toshiba because I wanted to learn where its specifications differed from the L298. As the article stated, this chip is not a direct drop-in replacement. In some respects this is good, for example the diodes to absorb back-EMF from inductive loads. The L298 required external support diodes, but the TB6612 has them built in, reducing parts count in our projects. In other respects the differences were limiting, such as a voltage range that only went up to 13.5V maximum which is far lower than the L298’s 45V. But since I’m looking to drive TT gearmotors which have a recommended voltage range of 3-6V, this limitation is not a problem here. And the smaller size of TB6612 would be quite welcome in a micro rover.

Examining the control signals, I see TB6612 allows us to specify motor direction using IN1 and IN2 pins. To control velocity, we send PWM signal to a pin explicitly named PWM. For applications that control a L298 using its IN1 and IN2 pins to control direction and control velocity by PWM controlling the enable (EN) pin, the TB6612 would be a direct logical replacement. However, my L298 breakout board tied EN to high by default implying speed control by PWM pulsing IN1 and IN2. I guess this is also valid for L298 but such a control scheme would not be compatible with TB6612.

Looking around, I can see the TB6612 used in a few other maker-friendly products including Adafruit product #1438 which is an Arduino motor shield built around this motor control chip. SparkFun #14451 offers it in a more compact breakout board instead of the Arduino shield form factor, Adafruit #2448 is another similar option. I haven’t built up my own equipment and skill to work with surface mount components directly, so I will need such breakout boards or pay someone else to assemble a board with it.

Examining my options on Amazon (*) I was surprised at how slim my selections were. Perhaps this is a temporary thing due to the current worldwide semiconductor shortage? Whatever the reason, the majority of my search results today were actually breakout boards for a different chip, the DRV8833, while claiming TB6612 compatibility. Since I’m in the research stage, I might as well take a look at that chip, too.


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

Circuit Schematic of Generic L298N Driver Board

As a learning exercise, I decided to generate my own documentation for commodity L298N motor driver modules available wherever hobbyist electronics are sold. The first step was to catalogue all the components mounted on board, and now I analyze the circuit board layout to see how they are connected together. And as much as I like to do things digitally, for projects like this I really appreciate the flexibility and immediacy of a sheet of paper to scribble on.

I could probably do it with the actual device in hand and a blank sheet of paper, but this time around I decided to create my own visual guide. I took photos that are as directly square-on as I could front and back. I scaled them to the same size, and printed them side by side on a sheet of paper leaving room for me to write notes. Once printed, I folded the paper in half while holding it up to a light source so I could line up the front and the back. Then I started following copper traces and scribbling my notes.

Fortunately this was a relatively simple circuit that mostly followed data sheet recommendations. I quickly confirmed the eight diodes were present to dump excess power into the +12V and GND planes. The two electrolytic capacitors are there for the +12V and +5V power planes respectively. IN1 through IN4 and OUT1 through OUT4 are straightforward direct routes. I also confirmed the optional current sensing resistors were absent, those pins were tied directly to ground. Furthermore, there was no provision to make adding current sensing resistors easy. People who want to perform current sensing are probably better off using another module.

A few traces were buried under components so their paths had to be teased out via probing with a continuity meter. The jumpers on ENA and ENB do indeed tie them high to the +5V power plane. The third jumper enable/disable the onboard 78M05 regulator. When the jumper is in place, it connects the +12V power plane to the input pin of 78M05. Which can then supply 500mA of current to +5V plane. Since the L298 itself draws less than 100mA, the remainder capacity can be tapped via the +5V screw terminal to perhaps drive a microcontroller. When the jumper is removed, regulator input is disconnected from the +12V plane and the +5V screw terminal becomes an input port to accept external power. The LED and current-limiting resistor is connected to the +5V plane and will illuminate when +5V power is present.

Aside from the silkscreened text proclaiming +12V, I found nothing to limit motor power supply to +12V. As far as I can tell it can be anywhere from 7 to 35V when using the onboard 78M05 regulator. If the regulator jumper is removed and L298N is running on external logic power, the lower limit is dictated by the L298N which can function with as low as 4V. The upper limit of a L298N is 45V with peaks of 50V, but the capacitors and 78M05 used on this module are listed with 35V maximums. Personally I’m unlikely to use anything higher than two 12V lead-acid batteries in series, which would be 28.8V fully charged and comfortably under that limit.

As a part of this self-assigned exercise, I also practiced drawing a schematic using the electronics design component of Autodesk Fusion 360. I think I’ve captured all of the information above, though I’m sure this schematic violates a bunch of conventions and make electronic engineer eyes twitch. (I’ve had to read software code written by electrical engineers so I have some idea what the mirror image is like.) And while I try to put lots of comments into my software source code, I haven’t learned how to best document a schematic. Until I learn more about that world, this blog post represents my best effort for this round.

Armed with this knowledge, I felt confident enough to embark on designing a micro rover to use TT gearbox with its DC motor, leading to Micro Sawppy Beta 3.

Components of Generic L298N Motor Driver Module

The internet is a great resource, but sometimes I want the experience of doing something on my own. This is why after buying a batch of generic L298N motor driver modules, I decided to sit down and understand what I have on hand instead of just downloading someone else’s documentation.

The main attraction with the big heat sink is the L298 itself, specifically the L298N variant. Flanking it, four on each side, are small modules labelled “M7”. Since the datasheet said an array of four diodes each are required for A and B sides, seeing eight of something on the board makes them candidates for those diodes. A search for “M7 Diode” indicates they are 1N4007 diodes.

A single rectangular package is etched with ST logo and designation 78M05. Its datasheet describes it as a voltage regulator delivering 5V at nominal 500mA. Input voltage can be up to 35V, but must be at least 7V. Two cylindrical assemblies are likely electrolytic capacitors. The numbers indicate 220uF at up to 35V, matching the maximum limit of 78M05. L298 datasheet required a capacitor between motor voltage supply and ground, and another capacitor between logic voltage supply and ground, so that fits.

Two blue screw terminal blocks on either side are motor output connections. They are labeled OUT1 and OUT2 on one side and OUT3 and OUT4 on the other, designations straight from the L298N data sheet. Also straight from the data sheet are control signals IN1, IN2, IN3, and IN4. There are jumpers on ENA and ENB. My hypothesis is that they are tied to +5V to stay in the enabled state by default, allowing motor direction control going full speed forward, full speed reverse, and brake stop. If an application wants control over enabled state, we can remove jumpers and connect the enable lines for PWM speed control.

The third screw terminal block has three posts labeled +5V, GND, and +12V. GND is obvious enough, and given the presence of 78M05, my first guess is that the +5V terminal gives the option of tapping its output to drive our microcontroller. But it is also possible it is a +5V input to bypass the 78M05. There is a jumper nearby to disconnect something, possibly the 78M05? A small surface mount LED and accompanying current limiting resistor probably indicate power on one of the power rails. Finally the +12V label is mysterious, since everything I see with a voltage limit can go up to +35V and I see no reason to constrain it to +12V.

Looking over the list of expected components, I am left with two missing: there are no candidates for current sense resistors. Time to trace through this circuit and see if I can find them.

Trying Generic L298N Driver Board

I started researching using a L298 as motor driver because it is an established known quantity. After looking over its specifications, I realized it is not the best match for the TT gearbox DC motors I plan to use: the L298 is specified to work anywhere from 4 to 45 volts, but the little 130 DC motors used in a TT gearbox are usually listed with a nominal operating voltage of three to six volts. I should be able to avoid damaging the little motors as long as I keep the PWM duty cycle low. So I’ll continue investigation. Even if these aren’t the best drivers to use for my micro Sawppy, they might be useful for larger motors in larger Sawppy rovers.

During my research of L298 I came across reference to an Arduino motor control shield built around one of those drivers. It looks great, but a single shield with a single L298 can only drive two motors at different speeds. A six-wheel drive rover will have six motors. I could pair up front and back wheel motors if my rover chassis is front-back symmetric, but that still requires four different speed controls. I looked to see if the Arduino shield is stackable, but unfortunately the motor control pins are fixed so stacking them would only result in more motors running at the same two speeds.

Both Adafruit and Sparkfun appears to have moved beyond the classic L298 for their motor driver boards. I’ll look at those drivers modules later, for now I’m focusing on L298 so I headed to the cutthroat market of lowest-bidder generics, just as I looked there for my micro-servos and TT gear motors. A query for L298 on Amazon (*) returned many vendors all selling what looks like clones of the same product. A pattern repeated on AliExpress as well. I purchased from the Amazon lowest bidder du jour (*) for a closer look.

And just like with micro servos and TT gear motors, I couldn’t find much on the history of this particular driver module design. Somebody must have built and sold the first one, but now that it has since been copied infinitely I had no luck finding the source. Since this has become a generic fungible item, none of the vendors I checked bothered to supply documentation. They probably assumed a people can find it online somewhere and I’m sure I could. However, I’ve made a conscious decision not to. As an educational exercise I’ll try to decipher this module on my own.

Alrighty, what’s on this thing?


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

Notes on L298 Dual Full-Bridge Driver

My little rover project switched away from modified servos with unpredictable motor drivers to pure DC gear motors. The good news is that this switch allows me to take control of the motor driver. The bad news is that… well, now I have to control motor drivers myself.

For this exploration, I’ll start with a classic the L298. These are featured in countless tutorials for turning digital logic into physical motion with motors and solenoids. It is not the latest technology, it is not compact, it is not efficient, but I expect L298 (or clones) to be available anywhere maker electronics are available. It’s such a classic that in the official ST Electronics datasheet PDF, diagrams are blurry as if scanned from paper instead of generated directly. At least the text is clear, but it is also amusingly dated “Jenuary 2000” so maybe we’re looking at a document with OCR-enhanced text (with OCR errors) and old scanned diagrams.

When used to control DC motors like my current project, a L298 is usually put to work running two motors. There are two sides “A” and “B” each with its own control signals and output pins, though both share common power supply and ground pins. Motor can be driven at up to 45V with occasional spikes are allowed up to 50V. Electrical current is up to 2A with occasional peaks of 3A. Steady state, that multiplies out to 45V * 2A * 2 motors = 180 Watts, a respectable chunk of power which explains why there is a big metal tab for heat dissipation and datasheet says operating temperature may rise to as high as 130°C.

The chip itself requires 5V input for internal logic, separate from the motor power supply. For digital logic purposes, anything under 1.5V is treated as logic low. This is relatively high threshold and is intentionally done to to mitigate electrical noise coming from motors next door. Fortunately that should not present problems for newer 3.3V microcontrollers like ESP32, Teensy and newer Arduinos. Data pins draw up to 100uA which shouldn’t be a problem to pair it with modern chips with far less amperage capacity than old school 8-bit chips.

Figure 6 explains how our microcontroller controls motor behavior. Direction is commanded by raising one input high and pulling other low. If they are equal, we get motor brake which we are warned must still not exceed 2A. If enable is low, the motor coasts independent of input values. Reading this chart, I understand that proportional motor speed control is accomplished by putting a PWM signal into the enable pin, alternating between applying power and coasting. However, I don’t see a recommendation on what my PWM frequency should be.

A web search found this electronics StackExchange answer that claims single-digit kilohertz would be sufficient. However, there’s also a contradiction in an answer that first claims PWM is done on the control input lines and enable is simply tied to high (always enable), but then links to the Arduino motor shield with L298N where the schematic clearly has PWM input lines going to the enable pins. Strange! I’ll follow Arduino precedent and send PWM control to the enable pin.

Another use for the enable pin is in the power up/down sequence. Enable pin should be pulled low before motor supply is turned on, and should be low before motor supply is turned off. Speaking of power, when driving inductive loads (and motors certainly are) a 4-diode network is required to dissipate power that might feed back to the circuit from these coils.

I saw several mentions of a current sensing resistor, and I see a “Rs” in all the schematics, but there’s no specification for resistance value or any other information beyond that they should be grounded as close to L298’s GND pin as possible. No reference for how L298 interprets current as a function of ohms resistance. Eventually I figured it out: the current sensing pin is only a provision for those that want to add a current sensing circuit to their design elsewhere. The L298 itself doesn’t care, and that’s why ohms are not specified in this datasheet. It’s going to be implementation-dependent so time for me to get my hands on an implementation.

Micro Sawppy Beta 1 Electronics

The past several posts have described various aspects of Micro Sawppy Beta 1 (MSB1) that are explorations of new ideas for a little rover. Since there were already many new ideas piled onto the little guy, I decided the control electronics and software should step back and reuse known quantities. Even though I don’t intend this to be the final approach, I wanted to reuse existing components here just to keep things from going too wild and confused if the little rover should encounter problems.

Hence the onboard electronics of MSB1 is very close to those used on Sawppy, which was in turn adapted from code written for SGVHAK Rover. Not from the official JPL Open Source Rover instructions, but the hack I hastily slammed together for its world premier at Southern California Linux Expo. Back then we faced the problem of a broken steering gearbox a week ahead of the event, and it would take over a week for replacements to arrive. So while Emily hacked up a way for a full-sized RC servo to handle steering, I hacked up the rover software to add option to control a servo via what I had on hand: the Adafruit PWM/Servo HAT.

Years later, I still have that same HAT on hand and now I have a rover full of micro servos. Putting them together was an obvious thing to try. My software for that servo steering hack turned out to be very easy to adapt for continuous rotation servos powering the wheels. (Only a single bug had to be fixed.)

There was another happy accident: since the SGVHAK rover software already had software provisions for steering trim, it was easy to use that for throttle trim as well. This was useful to compensate for the fact that the converted continuous rotation servos in the six wheels aren’t necessarily centered like they theoretically were. Resistors with identical markings don’t actually offer perfectly equal resistance, and the control circuit of a cheap micro servo isn’t very good about precise voltage measurements anyway. If I didn’t have this software throttle trim control, it might have been much more difficult to get MSB1 up and running.

For power supply I had a small 2-cell Lithium Polymer battery on hand, previously seen on these pages in exploration of a thrift store Neato. Dropping its voltage (8.4V when fully charged) down to something that wouldn’t fry the micro servos was the job of MP1584 buck converters. I had discovered these worked well for powering a Raspberry Pi and one of them is again enlisted into that role. In order to reduce the chances of a power sag causing the Raspberry Pi to reset, I added a second buck converter to give the micro servos an independent power plane. Both buck converters are soldered onto the little prototyping area Adafruit provided on their HAT. Once I had the electronics circuit stack assembled, I could start wiring up all the components.

A Delight for the Button Connoisseur

Yesterday I documented my quest to track down a button I saw on a prop used in the movie Sneakers which premiered 28 years ago. Eventually learning that they were Omron B3J-2100s, and they are still available for purchase from Digi-Key. Given the age of the movie, plus the fact this little detail was not important to the plot, plus the fact the rows of buttons were on screen for only roughly five seconds, I expected my blog post to quickly disappear into footnotes of the internet. Like everything else on this blog it was just a note from my personal explorations. Maybe it’ll receive an occasional a visitor, here to learn how to get these buttons for themselves.

Judging by web traffic, I was quite mistaken. I knew that the movie made impressions on others like myself, but I underestimated how many of us were out there. And even more surprisingly, these buttons made an impression on people as well. I had no idea there were so many button connoisseurs out there whose appreciation for a switch goes beyond whether it can reliable close and open a circuit. My blog post and associated Tweet were picked up by Adafruit blog and someone even submitted it to Hacker News where it was as high as #13 for a brief time. Amazing.

Its popularity also received feedback from many others. I found the prop in the movie was a Sequential Circuits Prophet 2002, but several people brought up the Roland TR-808 and there was also a mention of the Oberheim OB-X. They all used similar looking buttons for similar purposes: select options and an associated LED to indicates the active item. However, despite the similarity (and the TR-808 uses color to great effect) they are not the same Omron B3J buttons of a Prophet 2002.

I started posting a few corrections, but then I stopped. I realized that people were just sharing their own fond memories and there is no particular reason I have to point out they weren’t Omron B3Js. If someone is fond of a stylish button, what’s the point of taking away their joy? For the sake of pedantic correctness? Nah, we’re all connoisseurs of our own favorites. They have theirs, and I have Omron B3J.


Thanks to [garrettlarson] on Hacker News, we have a link to a YouTube clip where we can see the Prophet 2002 and its row of Omron B3J-2100s. (Go to ~1:20 if embedded time offset isn’t working.)

Quest for the Whistler Button

I’m a fan of physical, tactile buttons that provide visual feedback. I realize the current trend favors capacitive touch, but I love individual buttons I can find by feel. And one of the best looking buttons I’ve seen was from the 1992 movie Sneakers. When the blind character Whistler used a Braille-labeled device to add a sound effect representing the “thump” sound of a car going over seams of a concrete bridge.

They were only on screen for a few seconds, but I was enamored with the black buttons, each with a corresponding red LED. The aesthetics reminded me of 2001, like the eye of HAL in a mini monolith. Or maybe Darth Vader, if the Sith lord were a button. When I first watched the movie many years ago, I thought they were neat and left it at that. But in recent years I’ve started building electronics projects. So when I rewatched the movie recently and saw them again, I decided to research these buttons.

The first step is to determine if they were even a thing. All we saw was the front control panel of an unknown device. It was possible the buttons and LEDs were unrelated components sitting adjacent to each other on the circuit board, and only visually tied together by pieces of plastic custom-made for the device. So the first step was to find that device. There was a label at the bottom of the panel below Whistler’s hand, but due to the shallow depth of field I could only make out the end as “… 2002 digital sampler”. Time to hit the internet and see if anyone recognized the machine.

The first step is the Trivia section of the movie’s page on Internet Movie Database where people contribute random and minute pieces of information. Firearms enthusiasts can usually be counted on to name specific guns used in a film, and automotive enthusiasts frequently contribute make and model of cars as well.

Sadly, the electronics audio enthusiasts have not felt fit to contribute to this page, so I went elsewhere on the internet trying various keyword combinations of “Sneakers”, “Whistler”, “sampler”, etc. The answer was found in a comment to a Hackaday post about the movie. I’ve complained a lot about the general quality of internet comments, but this time one person’s nitpicking correction is my rare nugget of gold.

Whistler’s device is a Sequential Circuits Prophet 2002 Digital Sampler rack. As befitting the movie character, the sampler’s control panel had Braille labels covering the default text. But otherwise it appears relatively unmodified for the movie. I wish the pictures were higher resolution, but their arrangement strongly implies the button and LED are part of a single subcomponent. The strongest evidence came from the presence of four vertical axis buttons, rotated 90 degrees from the rest.

Aside: On the far right of the control panel, we can see a sign of the era, a 3.5″ floppy drive for data storage.

Encouraged by this find, I started searching for Prophet 2002 buttons. I quickly found an eBay community offering replacement parts for Sequential Circuits products including these buttons. What’s intriguing to me is that these are sold in “New” condition, not surplus or salvaged from old units. I’m optimistically interpreting this as a hint these buttons might still be in production, decades after the Prophet 2002 was released in 1985.

Thanks to those eBay listings, I have seen a picture of the component by itself and it is exactly what I hoped it would be: the button’s exterior surface, the electric switch itself, and the LED are integrated into a single through-hole component. Given the tantalizing possibility it is still in active production and something I can buy for my own projects, I went next to electronics supplier Digi-Key.

Digi-Key carries 305,212 components under its “Switches” section, not practical for individual manual review. Fortunately there are subsections and I first tried “Tactile Switches” (5721 items) because those buttons look like they’d give a good tactile response. In the movie we also heard a satisfying click when the button was pressed, but I don’t know if that was added later by the film’s sound mixer.

Within the “Tactile Switches” section, I aggressively filtered by the most optimistic wish they are active and in stock:

  • Part Status: Active
  • Stocking Options: In Stock
  • Illumination: Illuminated
  • Illuminator: LED, Red

That dropped it to 76 candidates. Almost all of them carried their illumination under the button instead of adjacent to it. The closest candidate is a JF Series switch by NKK Switches, the JF15RP3HC which has a Digi-Key part number 360-3284-ND.

It is a more modern and refined variant of the same concept. The button is sculpted, and the illuminated portion sits flush with the surroundings. This would be a great choice if I was updating the design, but I am chasing a specific aesthetic and this switch does not look like a monolith or Vader.

So that wasn’t too bad, but I’m not ready to stop. Peer to “Tactile Switches” are several other subsections worth investigating. I next went to “Pushbutton Switches” (175,722 items) and applied the following filters. Again starting with the optimistic wish they are active and in stock:

  • Part Status: Active
  • Stocking Options: In Stock
  • Type: Keyswitch, Illuminated
  • Illumination Type, Color: LED, Red

That filter cut the number of possibilities from 175,722 down to 21 which felt like an overly aggressive shot in the dark, and I expected I would have to adjust the search. But it wouldn’t hurt to take a quick look over those 21 and my eyes widened when I saw that list. Most of the 21 results had a very similar aesthetic and would make an acceptable substitute, but that would not be necessary because I saw the Omron B3J-2100.

Yes, I’ve hit the jackpot! Even if that isn’t precisely the correct replacement for a Prophet 2002 sampler, it has the right aesthetics: a dark angular block with the round LED poking out. But now that I’ve found the component, I can perform web searches with its name to confirm that others have also decided Omron B3J is the correct replacement.

Omron’s B3J datasheet showed a list of models, where we can see variations on this design. The button is available in multiple colors, including this black unit and the blue also used by the Prophet 2002. The number and color of LEDs add to the possible combinations, from no LEDs (a few blue examples on a Prophet 2002 have no lights) to two lights in combinations of red, green, or yellow.

Sure, these switches are more expensive than the lowest bidder options on Amazon. But the price premium is a small price to pay when I’m specifically seeking this specific aesthetic. When I want the look that started me on this little research project, only the Omron B3J-2100 will do. And yeah, I’m going to call them “Whistler buttons”.

[Follow-up: This post became more popular than I had expected, and I’m glad I made a lot of fellow button enthusiasts happy.]

OpenCV AI Kit

For years I’ve been trying to figure out how to do machine vision affordably so I could build autonomous robots. I looked at hacking cheap LIDAR from a Neato robot vacuum. I looked at an old Kinect sensor bar. I looked at Google AIY Vision. I looked at JeVois. I tried to get a grounding in OpenCV. And I was in the middle of getting up to speed on Google ARCore when the OpenCV AI Kit (OAK) Kickstarter launched.

Like most Kickstarters, the product description is written to make it sound like a fantastic dream come true. The difference between this and every other Kickstarter is that it is describing my dream of an affordable robot vision sensor coming true.

The Kickstarter is launching two related products. The first is OAK-1, a single camera backed by hardware acceleration for computer vision algorithms. This sounds like a supercharged competitor to machine vision cameras like the JeVois and OpenMV. However, it is less relevant to a mobile autonomous robot than its stablemate, the OAK-D.

Armed with two cameras for stereoscopic vision plus a third for full color high resolution image capture, the OAK-D promises a tremendous amount of capability for (at least the current batch of backers) a relatively affordable $149. Both from relatively straightforward stereo distance calculations to more sophisticated inferences (like image segmentation) aided by that distance information.

Relatively to the $99 Google AIY Vision, the OAK-D has far more promise for helping a robot understand the structure of its environment. I hope it ships and delivers on all its promises, because then an OAK-D would become the camera of choice for autonomous robot projects, hands down. But even if not, it is still a way to capture stereo footage for calculation elsewhere, and only moderately overpriced for a three-camera peripheral. Or at least, that’s how I justified backing an OAK-D for my own experiments. The project has easily surpassed its funding goals, so now I have to wait and see if the team can deliver the product by December 2020 as promised.

Ubuntu 18 and ROS on Toshiba Chromebook 2 (CB35-B3340)

Following default instructions, I was able to put Ubuntu 16 on a Chromebook in developer mode. But the current LTS (Longer Term Support) release for ROS (Robot Operating System) is their “M” or Melodic Morenia release whose corresponding Ubuntu LTS is 18. (Bionic Beaver)

As of this writing, Ubuntu 18 is not officially supported for Crouton. It’s not explicitly forbidden, but it does come with a warning: “May work with some effort.” I didn’t know exactly what the problem might be, but given how easy it is to erase and restart on a Chromebook I decided to try it and see what happens.

It failed failed with a hash sum failure during download. This wasn’t the kind of failure I thought might occur with an unsupported build, download hash sum failure seems more like a flawed or compromised download server. I didn’t understand enough about the underlying infrastructure to know what went wrong, never mind fixing it. So in an attempt to tackle a smaller problem with a smaller surface area, I backed off to the minimalist “cli-extra” install of Bionic which skips graphical user interface components. This path succeeded without errors, and I now have a command line interface that reported itself to be Ubuntu 18 Bionic.

As a quick test to see if hardware is visible to software running inside this environment, I plugged in a USB to serial adapter. I was happy to see dmesg reported the device was visible and accessible via /dev/ttyUSB0. Curiously, the owner showed up as serial group instead of the usual dialout I see on Ubuntu installations.

A visible serial peripheral was promising enough for me to proceed and install ROS Melodic. I thought I’d try installation with Python 3 as the Python executable, but that went awry. I then repeated installation with the default Python 2. Since I have no GUI, I installed the ros-melodic-ros-base package. Its installation completed with no errors, allowing me to poke around and see how ROS works in this environment.

Looping Video Advertisement Player Module

While I was at Costco for grocery shopping and checking out rechargeable batteries, I walked through the electronics section. For certain items, the actual merchandise is not available in the shopper-accessible warehouse. Instead the warehouse pallet hold sheets of cardboard that shoppers take to the cashier. Once paid, the receipt is shown to a secure caged area attendant who delivers the actual merchandise.

Familiar with this system, I was not surprised to see pallets stacked full of cardboard sheets in the camera section and didn’t think much of it until my peripheral vision reported unexpected motion. GoPro camera packaging always advertise with beautiful people having amazing adventures, but one of these was moving. Cardboard doesn’t do that.

Bluefin Ad Player 20-3000-1232

Stopping to investigate, I found one of the cardboard sheets has been modified. A rectangular hole was cut, and a video-playing LCD screen complete with associated electronics was inserted. A USB flash drive presumably held the GoPro promotional video, and that was the extent of the modification. There was no rear enclosure so it was easy for me to take a picture for further research once I returned home.

Given the information visible, I searched for Bluefin Technology “Ad Player” Model 20-3000-1232. This led to the manufacturer’s website and some minimal specifications. While the product label clearly labeled the device as made in China, the web site lists an office in Georgia that I presume was their USA distributor. So I was surprised that I couldn’t seem to find this module for purchase online, the only units I found for sale were secondhand on eBay. Most surprisingly, typing the model number into Alibaba and AliExpress also came up empty! I infer this to mean the company only sells to other businesses and there’s no retail sales channel.

I had thought this device would make a promising platform for hacks depending on price. Second hand eBay Buy-It-Now price of $70 is not terribly promising, I had been hoping for something closer to $30. But until I find a retail source or decide to buy in bulk directly from the manufacturer, none of that matters.

Projects Using Brushless Motors Must Account For Controller Start Up Behavior

Today I learned brushless DC (BLDC) motor controllers might tailor their motor start up procedure for their designed use case. This is notable because depending on the specialization, it might make them unsuitable for repurposing to other projects. This is not something I had experienced as my own projects have used either stepper motors, brushed DC motors, or self-contained modules like RC hobby servo motors. But another local maker tried to repurpose some brushless motors for a project, and made a discovery worthy of writing down for future reference.

The motors were sold as electric skateboard motors, similar but not identical to this Amazon item. (*) The rubber wheel was removed, and the motor mounted inside a 3D printed gearbox in a similar manner to the brushed DC motors inside SGVHAK rover wheels. The resulting assembly worked well enough on a workbench when driven by the controller module that came with the motor. But when placed under load, the motor was unable able to start from standstill. It was stuck in an endless loop of try, fail, wait, repeat. We had to give the mechanism a push and start it moving before the skateboard motor controller could take over.

Unsatisfied with this behavior, the project moved on to a dedicated brushless motor control chip purchased from Digi-Key and a circuit board was designed around it. This custom BLDC controller module replaced the default unit. When starting under load, it would twitch for a few seconds, then give up and stop. It was only able to run the motor in open air or after a push. So while the actual behavior was different, for practical purposes the two controllers were equally useless for the project.

If it was just one controller, we can blame a faulty unit. But two completely different controllers exhibiting similar behavior in different ways tell us something else is going on. After some investigation, the conclusion is that both controllers are behaving by design. Neither controller were capable of starting a loaded brushless motor from standstill because neither were intended to.

The first controller was tailored for electric skateboards. It does not need to be able to start moving a heavy load from standstill, because skateboard riders usually start off with a kick as they engage their electric throttle. In fact, its inability to move until the skateboard is already moving can be argued as a safety measure to ensure a board can’t take off unexpectedly.

The second controller, after some digging, was discovered to be designed for fans. Unsurprising, then, that it was able to start the motor spinning in air. And again the inability to start under load might even be a safety measure: an air moving fan encountering resistance on startup indicates an obstruction that must be removed.

While instructive, learning this lesson has put the project no closer to a solution. Motor start up behavior isn’t something typically stated up front when shopping for BLDC controllers, as seen in this Amazon “brushless motor controller” query result. (*) More research is required.

But at least we now know it is a factor.


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

Salvage Surface Mount Switches For Homing Test

After I managed to destroy a stepper motor during experimentation, Emily graciously donated another one to the cause. Hooking it up to my A4988 test board, I can tell this optical drive carriage had more power than the one I salvaged from a laptop drive. At least this one could win a fight against gravity. However, I was dismayed to find it is still quite weak in absolute terms, and this time I’m wary of cranking up the power in fear of destroying another motor.

So in order to set up something to learn how to wire up a homing switch for Grbl, I need to find switches that take less force to activate than the switches I already have on hand. Where might I find tiny switches that take tiny force to activate? The recently disassembled laptop optical drive!

SMD switches

Its control board had a few tiny surface mount switches. They were connected to small mechanical linkages throughout the drive so this control board can determine various states of the eject mechanism and such. There were a total of four switches and I put them under a heat gun in an effort to remove them.

This was a tricky procedure, as I had to melt the solder without melting the plastic. I put too much heat into two of the switches and destroyed them in the process. Fortunately, two of them were removed relatively undamaged. I put one of them under a meter to check for continuity, and it appeared to still work as a switch.

And soon, if all goes well, it will be a homing switch.

Panasonic UJ-867 Optical Carriage (Briefly) Under A4988 Control

Once I extracted the optical assembly carriage of a Panasonic UJ-867 optical drive, the next step is to interface it with a Pololu A4988 driver board. And just as with the previous optical drive stepper motor, there are four visible pins indicating a bipolar motor suitable for control via A4988. However, this motor is far smaller as befitting a laptop computer component.

Panasonic UJ-867 70 stepper motor connector

The existing motor control cable actually passed through the spindle motor, meaning there were no convenient place to solder new wires on the flexible connector. So the cable was removed and new wires soldered in its place.

Panasonic UJ-867 80 stepper motor new wires

Given the fine pitch of these pins it was very difficult to avoid solder bridges. But it appeared to run standalone so I reinstalled into the carriage. Where it still ran – but was very weak. Hardly any power at all. When I tilted it up so the axis of travel is vertical, the carriage couldn’t win its fight against gravity. Since the job is only to move an optical assembly, I didn’t expect these carriages exert a great deal of force. But I’ve seen vertically mounted slot loading optical drives. I thought it should at least be able to fight against gravity.

A Dell laptop charger delivers 19.2V. I’m not sure how many volts this motor intended to run at, but 12V seemed reasonable. Then I increased current beyond the 50mA of the previous motor. Increasing both voltage and amperage seemed to help with more power, but it remained too weak to overcome gravity.

As I’m tilting the metal carriage assembly in my hand, I started noticing it was warming. Oh no! The motor! I checked the temperature with my finger, which was a mistake as it was hot enough to be painful to human skin. I shut down my test program but it was too late, the carriage never moved again.

Lessons learned: don’t get too overzealous with power and check temperature more frequently.

And if I want to continue these experiments, I’ll need another stepper motor assembly.

Examining Pixelblaze Sensor Expansion Board

With my RGB-XYZ 3D sweep test program, I’ve verified my LED helix is fully set up with a Pixelblaze controller programmed with its geometry wound around a 3D printed chassis.  I have a blank canvas – what shall I create on it? A Pixelblaze by itself is capable of generating some pretty amazing patterns, but by default it has no sense of the world around it. It can only run a programmed sequence like my sweep test. I could focus on writing patterns for spectacular LED light shows, but I decided to dig deeper for sensor-reactive patterns.

There are a few provisions on board for analog and digital inputs, so patterns could react to buttons or knobs. Going beyond such simple input is the Sensor Expansion Board. It is an optional Pixelblaze add-on board which provides the following:

  • A microphone specifically designed to continue function in loud environments
  • An ambient light level sensor
  • 3-axis accelerometer
  • 5 additional analog inputs

A Pixelblaze fresh out of the package includes a few sound-reactive patterns that work with the microphone. They are fun to play with, but that ground has been covered. Seeking fresh under-explored territory and an opportunity to write something useful for future users, I looked at the other sensors available and was drawn to the accelerometer. With it, I could write patterns that react to direction of gravity relative to the sensor board. This should be interesting.

The sensor board is fully documented on Github, which included description of the protocol used to send data to a Pixelblaze. Or actually any other microcontroller capable of decoding 3.3 volt serial data at 115200 baud which should be all of them! In my case I’ll be using it with my Pixelblaze, and the first lesson here is that we only really need 3 pins out of its 7-pin expansion header: 3.3V power and ground obviously, and since the protocol is unidirectional, only one of two serial transmit pins is used by the sensor board. The remaining pins are pass-through available for other purposes. I’ll explore those possibilities later, for now it’s time to get set up to experiment with the accelerometer.

Examining Adafruit AT42QT1070 Capacitive Touch Sensor Breakout

The Death Clock logic is built around user action to trigger its little show for amusement. While we could easily incorporate a micro switch or some such simple mechanical input, Emily felt it would make more sense to have a capacitive touch sensor. This fits into the theme of the clock, sensing and reading a person’s body instead of merely detecting a mechanical movement. So we’ll need something to perform this touch sensing and she procured an Adafruit #1362, AT42QT1070 5-Pad Capacitive Touch Sensor Breakout Board for use. Inside the package was a set of leads for breadboard experimentation, so we soldered them on, put the works on a breadboard, and started playing with it.

Initially the board worked mostly as advertised on Adafruit product page, but it is a lot more finicky than we had anticipated. We encountered frequent false positives (signaled touch when we haven’t touched the contact) and false negatives (did not signal touch when we have touched the contact.) Generally the unpredictability got worse as we used larger pieces of conductive material. Either in the form of longer wires, or in the form of large metal blocks we could touch.

Digging into the datasheet linked from Adafruit’s site, we learned that the sensor runs through a self calibration routine upon powerup, and about a “guard” that can be connected to something not intended as touch contact in order to form a reference for intended touch contacts. The calibration routine explains why we got wild readings as we experimented with different touch pads – we should have power cycled the chip with each new arrangement to let it recalibrate.

After we started power-cycling the chip, we got slightly better results, but we still needed to keep conductive material to a minimum for reliable operation. We played with the guard key and failed to discern noticeable improvement in touch sense reliability, perhaps we’re not using it right?

For Death Clock implementation we will try to keep the sensor board as close to the touch point as we can, and minimize wire length and electrical connections. Hopefully that’ll give us enough reliability.

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.