Arduino Nano Failed to Power Backlight via USB

It was fun to look at a revived LED backlight module, salvaged from a LG laptop display panel model LP133WF2(SP)(A1). It was controlled from a breadboard Arduino, and powered by my bench power supply. I’m still unsure what input voltage it was originally designed for, but it seemed to run well at 5V. When I turned brightness up to maximum, the bench power supply reported 1A of current draw. As a 5W LED light, it does feel approximately in the same ballpark as the 7W LED bulbs serving as 60W incandescent bulb replacements. But with the key and very valuable difference of the fact its light is evenly distributed across a much large area for a softer more diffuse light.

While I’m at it, I measured the electrical behavior of these LED strings. This is mostly for reference since the TPS61187 chip handles adjusting these voltage values to keep electricity flowing at the target current. When it sees a very minimal PWM signal, I measure the voltage drop from anode to ground to be roughly 15V and the panel is not visibly illuminated at this low level. When I turn the duty cycle up high enough to see just a little bit of visible illumination, the voltage differential has climbed to 24V. At max power, I measured about 28V. This was all generated by the onboard boost converter from a 5V input signal. In my experience white LEDs drop roughly 2.7-3V at full power, so these values are consistent with parallel LED strings of either nine or ten LEDs per string.,

Since this circuit seemed to run at 5V, I thought it would be fun to convert this to run on USB. The Arduino Nano was designed to run on 5V and already had a handy USB jack, and most portable USB power banks can supply 5V@1A or at least they claim to. When I hooked up the wires, it was able to illuminate up to a certain level. But beyond that level (roughly 1/4 to 1/3 brightness) the lights started flickering in a classic sign of power instability. Oops. What went wrong?

Whenever I see potential sign of power instability, my first reaction is always to perform the Big Honkin’ Capacitor test. Find the biggest capacitor I have handy, connect it across the power input terminals, and see if that solves the problem. In this case, the big capacitor failed to soothe the system.

Digging into schematics for an official Arduino Nano, I see that the VUSB line is not directly connected to the +5V output pin. There are a few components in the way, relating to power control and regulation. The Arduino Nano could be powered via its VIN pin. Following Arduino Uno barrel jack precedence, the input voltage is usually recommended to be 9V. When this happens, there’s a diode presumably to make sure that 9V does not feed back into the USB +V line. There are also several capacitors in parallel with VUSB but they should help rather than interfere with any instability.

Mystified as to why I couldn’t power the backlight via this Arduino Nano’s USB jack, I wanted to isolate the problem. See if the problem lies within the Arduino Nano or with my USB power bank. I took a USB cable and cut off its a damaged micro-B connector. Splaying out the wires, I found VUSB and GND wires, and I connected that to the Arduino Nano circuit. With this arrangement, my backlight module is happy all the way up to full brightness with no flickering problem.

Something about this particular (non-genuine) Arduino Nano module is causing interference, and I don’t understand why, but at least I have a workaround. That’s enough for me to ignore this weirdness today and proceed with my backlight project, even if there was a temporary setback.

A Closer Look at LED Backlight Panel

I’ve successfully interfaced with the existing TPS61187 driver chip on the circuit board of a LG laptop display panel LP133WF2(SP)(A1), and brought the backlight module back to life. Given all the new territory I had to explore to get this far, I was very excited by a successful initial test. After I was able to calm down, I settled down to take a closer look at its physical/optical behavior.

Since I tested it face-down, the easiest thing to look at first are the backsides of the LED strip. Most of it is hidden by the sheet metal frame from this side, but from earlier examination I knew there was even less to see from the front. Once illuminated, we can see the structure inside the light strip. The yellow flexible segment that connects to the green circuit board isn’t a separate piece like I thought earlier, it is actually all a single sheet of flexible circuit. All the LEDs are mounted on it, and they are located at the very bottom edges of the screen. I knew the lights themselves had to be very thin and well hidden right up against the bottom edge, but I couldn’t figure out where the wiring would go. Now we can see all electrical wiring runs above the LEDs, and when we look at it from the front we can see it as a thin strip of light gray along the bottom.

I had been worried that the illumination would be compromised because it is working without some of the friends it had earlier. The backside used to have a laptop lid that would have helped reflect and diffuse light. And the front used to be up against the LCD pixel array, which was backed by a mirror finish that would have also helped reflect light around.

I need not have worried. It was quite evenly illuminated and, as seen in the wire shadow picture above, there are no distinct spotlights marking location of individual LEDs.

I also wondered if the surprisingly complex four-layer diffuser required precise alignment with the LEDs in order to do their light distribution magic. They are no longer pressed by the LCD pixel array into a tight space, but happily they still worked quite well. While they worked visibly best at certain positions, the falloff is graceful. Not like aiming a laser at precision optics. Now I’m even more impressed by this stuff performing magic with light in ways I don’t understand.

But one thing I do understand is that they look thin and quite fragile. Designed to sit behind a LCD panel of multiple glass layers and without that, these layers of magical optical sheets flap around. I looked around and found a piece of 3mm clear acrylic that is nearly the perfect size and taped it to the metal backing chassis. The acrylic is far thicker than the LCD glass sandwich used to be, but it is also more rigid, so that’s a good tradeoff.

The final comparison I wanted to make before moving on is: how bright is the backlight alone compared to the full backlight plus LCD screen? I placed this backlight, turned brightness all the way up high, and set it side-by-side with the intact replacement screen still serving display duty in the Chromebook. I then turned on the Chromebook and increased its screen brightness to maximum setting.

I don’t have light level measurement instruments to obtain an objective number, but this picture makes it quite clear there is a dramatic difference in brightness. I knew some light would have been lost within the layers of a LCD panel, but it’s fun to see firsthand it’s far more than I had expected. This really drove home why alternate display technologies with self-illuminating pixels (OLED, micro-LED, etc.) can offer much brighter pictures than a backlit LCD could. My salvaged backlight is plenty bright running on just 5V, but running it on USB took more effort than expected.

Arduino Nano PWM Signal for TPS61187 LED Driver

Trying to revive the LED backlight from a LG Lp133WF2(SP)(A1) laptop display panel, I am focused on a TPS61187 LED driver chip on its integrated circuit board. After studying its datasheet, I soldered a few wires to key parts of the circuit and applied power, checking the circuit as I went. Nothing has gone obviously wrong yet, so the final step is to give that driver chip a PWM signal to dictate brightness.

This is where I am happy I’ve added Arduino to my toolbox, because I was able to whip up a controllable PWM signal generator in minutes. Putting an Arduino Nano onto a breadboard, I wired up a potentiometer to act as interactive input. 5V power and ground were shared with the panel, and one of the PWM-capable output pins was connected to the TPS61187 PWM input line via a 10 kΩ resistor as per datasheet. I found that my enable line already had a 1 kΩ resistor on board, so now I wired enable directly to the 5V line.

Since I wanted some confidence in my circuit before plugging the panel into the circuit, I also wired a test LED in parallel with the PWM signal line. I had originally thought I could use the LED already on board the Arduino, but that is hard-wired to pin 13 which is not one of the PWM-capable pins, so the external LED was necessary for me to run my PWM-generating test code, which thanks to the Arduino framework was as easy as:

int sensorPin = A0;    // select the input pin for the potentiometer
int ledPin = 3;        // select the pin for the LED
int sensorValue = 0;   // variable to store the value coming from the sensor

void setup() {
  // declare the ledPin as an OUTPUT:
  pinMode(ledPin, OUTPUT);
}

void loop() {
  // read potentiometer position
  sensorValue = analogRead(sensorPin);

  // map analogRead() range to analogWrite() range
  sensorValue = map(sensorValue, 0, 1023, 0, 255);

  analogWrite(ledPin, sensorValue);
}

My external test LED brightened and dimmed in response to potentiometer knob turns, so that looked good. My heart started racing as I connected the panel to my Arduino breadboard, which is then connected to my benchtop power supply. Even though I’m powering this system with 5V, I used a bench power supply instead of a USB port. Because I didn’t know how much the panel drew and didn’t want to risk damaging my computer. Also, by using a benchtop power supply I could monitor the current draw and also set a limit of 120mA (20mA spread across 6 strings) for the first test.

I powered up the system with the potentiometer set to minimum, then slowly started turning the knob clockwise…

It lit up! It lit up! Woohoo!

I was very excited at this success, jumping and running down the hallway. It was a wild few minutes before I could settle down and calmly take a closer look.

Finding TPS61187 LED Driver Interfaces

I want to reuse the TPS61187 LED Driver IC already on board the display circuit board of a LG LP133WF2(SP)(A1) laptop LCD panel. Driving the backlight that used to shine from behind the now-cracked LCD screen. After studying the datasheet and probed around the circuit board to understand how the chip is configured, I am now probing to see where I can solder wires to interface with the chip.

There are two major concerns here. The first is that I’m learning to work with modern consumer electronics, with circuit boards populated by very small surface mount components. Most of the resistors and capacitors I probed earlier are barely larger than the tip of my soldering iron’s finest tip. The “normal” tip is comically large next to these things. If I continue with experiments like this I will need to buy my own hot air station and learn to use it well.

The second concern are the other components on this control board. If I supply voltage and ground to the TPS61187, the rest of the circuit will probably come alive in some way I don’t understand. I’m not worried about them draining a bit of battery, that’s the best case scenario. I’m more worried about them interfering with the backlight control signals for enable (EN) and brightness (PWM).

First target is to find a place to inject power. The datasheet told me where the power pins are on this chip, but it’s far too small for me to hand solder myself. I’m not saying it’s impossible to hand solder to them, I’m just saying it’s very difficult and unlikely to succeed with my current skill level. So I went poking around nearby components looking for a decoupling capacitor. Because this driver IC uses a boost converter circuit to raise the voltage to drive the backlight LEDs, I expect to find a sizable decoupling capacitor nearby to isolate the rest of this board from the electrical noise of boost conversion. I found one adjacent to the inductor. For a surface-mounted component, it is large and thankfully big enough for me to feel confident I could solder to its two ends for VIN and GND.

I found a resistor and capacitor nearby connected to the enable pin. But even though they are larger than the corresponding TPS61187 pin I couldn’t solder to them. I was able to connect to one side of the small capacitor, but an intended-to-be-gentle test tug ripped off the wire taking a corner chunk of the capacitor with it. Oops, not so gentle after all.

I had even less luck finding a PWM signal connection near the TPS61187. I could see its pin connection on the circuit board, but it instantly sank out of sight to one of the other layers of the board and I found no place nearby where it surfaced.

After some thought, I decided to look for these signals near the largest chip sitting on the other end of the board, labelled “LG Display ANX2804”. I reasoned that EN and PWM are probably controlled from this chip and perhaps I could find something. There was nothing obvious near the chip itself, but I struck gold on the backside of the board. Sitting effectively under the ANX2804 are several labelled and accessible test points, and I was happy to see “LED_EN” next to one pad and “PWM” next to another. (There’s also VLED visible further left I didn’t notice until later, which should be better than soldering to the VIN end of a surface mount decoupling capacitor.)

Continuity test confirmed these do connect all the way across this thin strip of circuit board to the TPS61187, I think we are in business! Time to do some soldering.

Probing TPS61187 LED Driver Configuration

I’ve read through the datasheet for a TI TPS61187 LED driver chip and I think I have a fair (if not perfect) grasp of how to use it. Specifically I want to use one I found on the integrated driver board of a LG laptop LCD panel I’ve taken apart, there to drive the backlight module I wanted to salvage as a LED light. Armed with the datasheet and a multimeter, I started poking at the driver board to understand how it uses the chip. Since most of the chip’s configuration are done via resistors connected to certain pins, I could use the ohmmeter to decipher configuration. I enlarged and printed out my picture of that area of the circuit board so I could scribble down notes as I went.

Here’s what I found on this board, listed in order of their corresponding datasheet sections:

7.3.1 Supply Voltage

For applications that are always-on, it is valid for the enable (EN) pin to be connected to the chip’s internal regulator output pin VDDIO. Since a laptop would want to put a screen to sleep, I did not expect EN to be tied to VDDIO and my meter confirmed it was not. Which means I’ll have to go hunting for my own connection to EN later.

7.3.2 Boost Regulator and Programmable Switch Frequency (FSCLT)

The internal boost converter can operate at a range of frequencies, giving the designer an option to tradeoff between efficiency, inductor component size, etc. I probed the selection resistor on this board to be 822 kΩ. Plugging this into datasheet formula I arrive at a switching frequency of 608 kHz. Table 1 lists a few recommended values, and 833 kΩ is one of the recommendations for 600 kHz. I suspect this was indeed the intent and this 822 kΩ resistor is pretty good at less than 2% off nominal value.

7.3.3 LED Current Sinks

This is arguably the core parameter of driving LEDs. I traced the circuit and found two resistors in series. ~20 kΩ and ~31 kΩ but they added up to about 58 kΩ so there’s obviously something else I missed. Nevertheless, plugging 58 kΩ into datasheet formula says it’ll sets the target at 20mA. Typical for driving LEDs.

7.4.2 Adjustable PWM Dimming Frequency and Mode Selection (R_FPWM/MODE)

There are two ways to control brightness of the backlight. Either they can be blinked directly by an external PWM signal, or they can be blinked with an internal signal generator. One advantage of using the internal signal is that the phase for each of six strings are offset, so they blink in turn instead of simultaneously, which I expect to give smoother dimming. Another advantage of separating the two signals is that the external PWM can run at a far slower frequency, even one that would otherwise cause visible flicker, but it wouldn’t matter. Because once its duty cycle is read, it is copied for use by the internal generator running at a far faster flicker-free rate.

Probing the configuration resistors proved this board uses the internal high speed PWM signal. The resistor is 3.9 kΩ which works out to about 46.6 kHz. This is not one of the Table 2 recommendations, in fact it is over twice the speed of the highest recommended value. at 9.09 kΩ / 20 kHz. Higher switching frequency usually mean smoother behavior but lower power efficiency, I wonder what design meeting decisions at LG led to this value. Though of course it’s possible I’ve misread the value somehow.

7.4.4 Overvoltage Clamp and Voltage Feedback (OVC/FB)

These resistors configure how the boost converter works, and there’s an ideal formula in the datasheet mapping input voltage to LED output voltage. I was able to measure Rdown as 20 kΩ, but Rupper did not converge. My ohmmeter’s initial reading was in the 370-400 kΩ range, but the value continued to increase as I kept the probes in place. Eventually it would read as off-scale high. I think this means there’s a capacitor in parallel?

Out of all the configurations I had hoped to read, this was the one I really wanted to get because it would inform me as to the best voltage level to feed into this system. With this ambiguous reading, I’m sadly no wiser.

But at least I have some idea of how this chip has been configured to run, so I could continue probing this circuit board looking for places where I can interface with this LED driving circuit.

My TPS61187 LED Driver Startup Plan

I wanted to see if I could power up just the LED backlight portion of a broken LG LCD laptop screen, model LP133WF2(SP)(A1). It was cracked and couldn’t display images, but the backlight still worked before I took it apart. Does it still work? I wanted to find out and I still had the screen’s integrated driver circuit board and will try that first. The biggest question mark here is how the rest of the circuit board will react if I try to power up the TI TPS61187 LED driver chip in-place on the circuit board. My fallback position is to bypass the chip and power the LED strings directly, but that wouldn’t be as energy-efficient and I lose out on cool features. The one most novel to me is the phase-shifted PWM dimming control, where the six LED strings are dimmed round-robin instead of all at once for a smoother display. It’s not something I would likely do if I had to power the LEDs directly with my own cricuit.

To see if I could get the original circuit running, I plan to do it in steps based on this excerpt from the datasheet:

7.3.4 Enable and Start-up

The internal regulator which provides VDDIO wakes up as soon as VIN is applied even when EN is low. This allows the device to start when EN is tied to the VDDIO pin. VDDIO does not come to full regulation until EN is high. The TPS61187 checks the status of all current feedback channels and shuts down any unused feedback channels. It is recommended to short the unused channels to ground for faster start-up.

After the device is enabled, if the PWM pin is left floating, the output voltage of the TPS61187 regulates to the minimum output voltage. Once the device detects a voltage on the PWM pin, the TPS61187 begins to regulate the IFB pin current, as pre-set per the ISETH pin resistor, according to the duty cycle of the signal on the PWM pin.

This translated to the following plan:

  1. Put minimal voltage across VIN and GND. If it doesn’t go up in smoke, probe VDDIO to see if it has some voltage.
  2. If that works, check the Enable pin. If I am to drive the chip, I will need to control the state of the Enable pin. This is where an interaction with existing components might cause headaches: something else on the board might be trying to keep it high or keep it low, and if I put voltage on that pin the opposite state, I might damage that component unless I cut a trace somewhere to disconnect it.
  3. I might also have to find and cut a trace for the PWM pin for the same reason.
  4. Send the Enable signal, and check the voltage level across a LED string for the “minimum output voltage” mentioned by the datasheet.
  5. If all of the above works, then I’ll work on how to generate the PWM dimming signal.

Plans rarely survive intact upon their first contact with reality, but I wanted to have one before I got started. It will guide me as I probe the circuit board to understand how it uses a TPS61187.

TI TPS61187 Circuit’s Boost Converter

I had a broken LG laptop screen, model LP133WF2(SP)(A1), which I’ve disassembled and now I’m digging into its backlight module. I want to see if it I could make it work as a standalone diffuse light panel. I could probably wire up the LEDs directly with a voltage source and current-limiting resistor, but I also have its original integrated driver circuit board which still worked as far as I knew. I’m sure most of it were concerned with moving pixels which are no longer relevant, but there is also a TI TPS61187 chip on the board to drive the backlight section.

The PWM control signal is 3.3V friendly with a logic high threshold of 2.1V, so I could use either a 5V ATmega328 Arduino or a 3.3V ESP32. The part I didn’t understand was the power input. The datasheet says input voltage can range anywhere from 4.5V to 24V, and that it has a built-in boost converter to send up to 38V to the LED strings. I had expected to see a separate output pin for this higher voltage, but in the Typical Application schematic, the LED’s common anode is connected to the input voltage plane via a diode and an inductor. This combined with the following quote in the datasheet confused me:

there must be enough white LEDs in series to ensure the output voltage stays above the input voltage range

With the common anode seemingly tied to voltage input, I didn’t understand how the anode voltage could be higher than the input voltage. The next hypothesis is that instead of different voltage supply planes, perhaps there are separate ground planes at different levels. I saw there was a PGND pin for logic that is separate from AGND pin for the LED strings so the hypothesis had potential. But when I probed the circuit board, my meter said PGND and AGND pins are tied together on my board, eliminating the “separate ground levels” idea.

With a distinct sense that I have misunderstood something, I went to Wikipedia to learn more about boost converters and how they work. As soon as the diagrams came onscreen for that page, I realized that inductor and diode I saw earlier WAS the boost converter. I just didn’t recognize it as I was only aware of a block diagram representation and didn’t know it when the core components of a boost converter were staring at me in the schematic. Now it all makes sense how the LED string common anode voltage will be higher than the input voltage, and I feel confident enough to devise a plan.

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.

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

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.