Once I completed a radiator (and radiator hose) replacement for my 2004 Mazda RX-8, I moved on to another item that has been sitting on the to-do list for many years. At one point I was excited to add a dashcam to my car, and thought I could do a clean job of integrating one because a wiring harness already exists high and center on my windshield for my fancy rearview mirror. At night it automatically dims in response to bright lights behind me, and it has a HomeLink remote control with three function buttons. (One of which is worn out because I use it for my garage opener.) I saw the same mirror installed across the Mazda lineup so it is not a RX-8 exclusive feature.
Many years ago I visited a RX-8 at a local salvage yard for an unrelated project and picked up an extra fancy mirror along with a segment of its wiring harness. I figured it would help me experiment with how to tap power from its counterpart in my car. It sat until today, when online resources included Mazda wiring diagrams for reference. I didn’t have to determine the pinout experimentally, I could just look it up.
Only four wires were used in this 10-position connector. All four had black insulation, but three of them had a thin color stripe for identification. The Mazda diagram labeled the wire positions A (upper right in picture above), B (lower right), through J. The four wires were:
Position B has a black wire with no color stripe. This wire provides +12V power only when ignition is in the “On” position. This ensures auto-dimming feature doesn’t waste energy when the car is parked.
Position D has a black wire with green stripe. This wire provides +12V power only when reverse gear is engaged. I’m not sure why this is here. Perhaps auto-dimming is disabled when I’m backing up? I never noticed one way or another.
Position F has a black wire with yellow stripe. This is the ground wire.
Position J has a black wire with red stripe. This wire always has +12V power for the HomeLink transmitter.
Whenever I get around to the dashcam installation, I would first try using the black (ignition on) wire for power. Unless the camera storage may get corrupted by abrupt shutdown. In that case, I will use black/red (always on) for power and use black (ignition on) wire as inverted signal to finish writing to storage and perform a proper shutdown. But honestly I don’t think it’s going to happen.
When I pulled the scanner image sensor bar from a partially disassembled Canon MX340 multi-function inkjet, I didn’t expect to understand very much of it. However, I was able to figure out the LED illumination subset of the scan head! Encouraged by this success, I felt more positive about trying to tackle the rest of the sensor bar. Which meant investing time to do a little bit of research.
When I set out to probe the electrical behavior of MX340 components, I did a brief search and found this type of sensor is called a contact image sensor (CIS). When searching for information online, getting the name is a big part of the battle. The Wikipedia page is sadly just a stub, and I don’t have the knowledge to expand it myself. (Yet?) The only source cited on that page is a ten year old link now dead, so I have to find something else.
When looking for information on electronics components at a hobbyist accessible level, I found it’s useful to search for the component and “Arduino”. Using that keyword distinguishes product sales pages from electronics details. Sadly I found nothing more helpful than the Arduino forum page that taught me the name. Searching for the name by itself found a lot of eBay listings selling replacement parts, which isn’t useful for my goal of learning about the sensors.
Scrolling through search results, my attention was caught by a link to the CIS section on Canon Components web site for businesses. This sounds like the current-day counterpart to the dead source link on Wikipedia. It is a page advertising Canon’s engineering prowess and aimed at companies that may build products around Canon CIS units. So the page exists to encourage these companies to contact the Canon sales team, which isn’t me.
Still, the page was informative. There’s a diagram breaking down the major components of Canon CIS technology, so I can get an idea of what parts I’m looking at and their names. Before seeing this diagram, I had thought the imaging sensor sits somewhere behind the clear optical lens. Now I know the clear optical lens is merely the light guide for the LED emitters I had just examined. The sensors actually look through a linear lens array adjacent to the light guide.
Armed with this knowledge, I went back to look at the sensor bar and found the row of small lenses that I had never noticed before. They are tiny, each lens is roughly 0.3mm across. As a rough approximation, that’s roughly 75 of them in an inch (~25.4mm). Scanners usually advertise their resolution as 300dpi or some multiple thereof (1200dpi, etc.) which means each of these lenses must correspond to more than one pixel in the resulting scan data. That process involves optical imaging magic out of scope of my current project: learn how they work electrically.
Clicking on the link for “Contact Image Sensor Product List” brought me to a sample selection of current Canon CIS products. I was most interested in the “Output form” column, specifying broadly how the sensor outputs its data. Possibilities include LVDS, which I have little hope of reading. Camera Link is also listed, and I had to go to Wikipedia to learn it is a protocol built on top of LVDS. And finally, there’s “analog output” which superficially seemed like the cheapest option. If I’m lucky, that’s what a cheap multi-function inkjet would have.
I don’t see any details on how image information is transmitted via Camera Link, LVDS, or analog. But I’ve learned a little more about contact image sensors today and maybe this is enough for me to recognize sensor image data when I see it under an oscilloscope.
Learning about Hall effect switches & sensors led to curiosity about more detailed detection of magnetic fields. It’s always neat to visualize something we could not see with our eyes. Hall sensors detect magnetic field along a single axis at a single point in space. What if we can expand beyond those limits to see more? Enter magnetometers.
I thank our cell phones for high volume magnetometer production, as a desire for better on-device mapping led to magnetometer integration: sensitive magnetometers can detect our planet’s magnetic field to act as a digital compass to better show a map on our phones. Since a phone is not always laid flat, these are usually three-axis magnetometers that give us a direction as well as magnitude for the detected magnetic field.
But that’s still limited to a single point in space. What if we want to see the field across an area, or a volume? I started dreaming of a project where I build a large array of magnetometers and plot their readings, but I quickly bogged down in details that made it clear I would lose interest and abandon such a project before I could bring it to completion.
Fortunately, other people have played with this idea as well. My friend Emily pointed me to Ted Yapo’s “3D Magnetic Field Scanner” project which mounted a magnetometer to a 3D printer’s print head carriage. Issuing G-code motion commands to the 3D printer control board, this allowed precise positioning of the sensor within accessible print volume of the 3D printer. The results can then be plotted out for a magnetic field visualization. This is a great idea, and it only needs a single sensor! The downside is that such a scheme only works for magnetic fields that stay still while the magnetometer is moved all around it. I wouldn’t be able to measure, say, the fields generated by an electric motor’s coils as it is running. But it is still a fun and more easily accessible way to see the magnetic world.
I thought it would be interesting to connect one of these sensors to an ESP8266 and display its results on a phone web interface, the way I did for the AS7341 spectral color sensor. I was almost an hour into this line of thought before I realized I was being silly: why buy a magnetometer to connect to an ESP8266 to serve its readings over HTTP to display in a phone browser interface? My Android phone has a magnetometer in it already.
Learning about brushless direct current (BLDC) motors, I keep coming across Hall-effect sensors in different contexts. It was one of the things in common between a pair of cooling fans: one from a computer and another from a refrigerator.
Many systems with BLDC motors can run “sensorless” without a Hall sensor but I hadn’t known how that was possible. I’ve learned they depend on an electromagnetic effect (“back EMF”) that only comes into play once the motor is turning. To start from a stop, sensorless BLDC motors depend on an open-loop control system “running blind”. But if the motor behaves differently from what that open-loop control expected, startup sequence fails. This explains the problem that got me interested in BLDC control! From that, I conclude a sensor of some sort is required for reliable BLDC motor startup when motor parameters are unknown and/or the motor is under unpredictable physical load.
Time to finally sit down an learn more about Hall effect sensors! As usual I start with Wikipedia for general background, then moving on to product listings and datasheets. Most of what I’ve found can be more accurately called Hall effect switches. They report a digital (on/off) response to their designed magnetic parameters. Some of them look for magnetic north, some look for magnetic south, others look for a change in magnetic field rather than a specific value. Some are designed to pick up weak fields of distant magnets, others are designed for close contact with a rare earth magnet’s strong field. Sensors designed to detect things like a laptop lid closing don’t need to be fast, but sensors designed for machinery (like inside a brushless motor!) need high response rates. All of these potential parameters multiply out to hundreds or thousands of different product listings on an electronic component supplier website like Digi-Key.
With a bit of general background, I dug up a pair of small Hall effect sensor breakout boards (*) in my collection of parts. The actual sensor has “44E” printed on it, from there I found datasheets telling me it is a digital switch that grounds the output pin when it sees one pole of a magnet. If it sees the other pole, or if there is no magnet in range at all, the output pin is left floating. Which pole? Um… good question. Either I’m misunderstanding the nomenclature, someone made a mistake in one of these conflicting datasheets, or maybe manufacturers of “44E” Hall switches aren’t consistent in which pole triggers pulling down the output pin.
Fortunately, the answer doesn’t matter for me right now. This breakout board was intended for use with microcontrollers like Arduino projects, and it also has an onboard LED to indicate its output status. This is good enough for me to start. I connected the 5V to center pin, ground to pin labeled “-“, and left the “S” pin unconnected. The onboard LED illuminated when I held it up against one pole. When held up against the opposite pole, or when there’s no magnet nearby, the LED stays dark.
I also knew there was a Hall sensor integrated into an ESP32. This one is not just an on/off switch, it can be connected to one of ESP32’s ADC channels to return an analog value. Sounds interesting! But ESP32 forums report the sensor is only marginally useful on the type of ESP32 development board I use. The ESP32 chip itself is packed tightly alongside other chips, under a metal RF shield, resulting in a very noisy magnetic environment.
Looking more into similar standalone sensors, I learned some keywords. To get more data about a nearby magnet, I might want an “analog” sensor that detects a range of values instead of on/off relative to some threshold. Preferably the detected output value changes in “linear” response to magnetic field, and to tell the difference between either pole or no magnet at all I’d want a “bipolar” sensor. Searching on Digi-Key for these parameters and sorted by lowest cost found the TI DRV5053: analog bipolar hall effect sensors with linear output. Available in six different levels of sensitivity and two different packages. And of course, there are other companies offering similar products with their own product lines.
They might be fun to play with, but they only detect magnet field strength at a single point along a single axis. What if I wanted to detect magnetic fields along more than one axis? That thought led me to magnetometers.
(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.
For curiosity and learning, I wanted to poke at a commercial brushless motor controller. Thanks to the current popularity of multirotor aircraft, the cheapest option on Amazon that day was a four-pack designed for small quadcoptor drones. Among the listing description is a string “BLHeli_S” that meant nothing to me at the time. Once I received the product and looked it over, I saw “BLHeli_S” written on the label as well, I thought I should at least do a web search to learn more.
BLHeli_S is a development of BLHeli motor control firmware, whose source code is on GitHub. From what I can understand, BLHeli_S is a port to SiLabs 16-bit microcontrollers offering higher performance than original BLHeli 8-bit hardware target. At first, I was thrilled there might be another brushless motor algorithm I could try to learn from, but my enthusiasm quickly cooled when I realized BLHeli_S was written in assembly language for maximum performance. That’s hard core. Understanding that codebase might take more work than I’m willing to put in.
I found additional information on Ardupilot website, which supports BLHeli_S and the even newer BLHeli32 motor controller firmware. In addition to standard RC servo control signal, these controllers also support a more advanced protocol called DShot. It allows higher bandwidth and lower latency, as well as digital checksum to detect and discard corrupted control signals. The most fascinating feature is bidirectional communication, which allows the motor controller to send back information like motor RPM. BLHeli_S also supports OneShot and OneShot125 protocols, but they offer neither the wide compatibility of RC servo style PWM nor the advanced features of DShot. I’m probably never going to touch those.
I could find scattered reviews of BLHeli_S like this one. The most interesting page I stumbled cross was What is DShot ESC Protocol which pointed me to Betaflight. Skimming through Betaflight’s GitHub repository, I found its DShot command driver. It was much easier than trying to find Ardupilot’s implementation. (This is as close as I got. [UPDATE: According to comment by David, the RCOutput_bdshot.cpp file I found handles telemetry coming back from the ESC. Outbound DShot control is handled by RCOutput_serial.cpp in the same directory.])
Looking for implementations outside of those large flight controller projects, I found several GitHub repositories of people taking a stab at it.
I also found an Arduino forum thread of someone asking about bidirectional DShot protocol, and the answer was a link to DShot – the missing Handbook. I doubt I would learn SiLabs assembly to dig into BLHeli firmware itself, but it might be interesting to talk to my new BLHeli_S brushless controllers via bidirectional DShot.
For my first experiment, though, I’m going with the tried-and-true RC servo PWM.
I want to learn how to control brushless motors and how to best tailor their control algorithms to different tasks. Most brushless motors I encounter are very tightly coupled to their associated controller. Occasionally I could examine how a particular pairing worked together, but I don’t know enough to mix and match salvaged motors/controllers to see how different combinations work together. I think I should start with a motor controller that has been designed to accommodate a range of different brushless motors.
The good news: recent popularity of multirotor aircraft (“drones”, “quadcoptors”, etc.) has spawned a product ecosystem of brushless motors and controllers marketed to drone owners. Whether they want to repair, upgrade, or build their own from scratch, many companies compete for their money. I just wanted something cheap as a starting point, so I went with Amazon’s lowest bidder of the day(*) for a four-pack of compact and lightweight brushless motor controllers. Obviously intended to match four motors in a quadcoptor, a pack of four works for me in the interest of redundancy. I may damage a few in my experiments.
Here’s one of the four, just removed from its packaging. I was impressed by its tiny size, the circuit board itself is only about 13mm x 23mm. Thicker red and black wires are for delivering battery power. The thinner wires led to 0.1″ pitch connectors for control signal and signal ground. There are no wires provided for the motor, just three solderable tabs.
I cut away its protective heat-shrink tubing to see inside. On the upper-left I see “S” for white control signal and “-” for signal ground. Probing with my meter indicates signal ground is connected to power ground. This isn’t usually a problem because drones tend to run everything off a single battery but would exclude this controller from circuits isolating logic ground from power ground.
In the center we see two microchips. Larger chip on the right has a logo I don’t recognize, and text SA6288 210. A web search found this SA6288, a gate driver chip designed to drive MOSFET/IGBT transistors to control power for three-phase motors. That fits. It’s probably taking orders from the other chip, then. A microcontroller makes sense given its proximity to the control input signal and four circular pads across the bottom that may be a way to reprogram the chip. I read its markings to be “dB21 F16C C01Q5K 2217”. Search engines clung on to “F16C” and wanted to tell me about the fighter jet, which wasn’t helpful. Maybe I’ve misread one or more characters.
Backside of the chip are all of the power control components, starting with red wire (VBAT) and black wire (GND) for battery power. Relatively large capacitors are visible, and I’m impressed it didn’t need larger electrolytic capacitors. Half of this side are taken up by an array of six modules. From my LX-16A teardown I recognize the logo for Alpha & Omega Semiconductors, but their website didn’t have any information on a 7544 chip. Arrow Electronics says there’s should be an AON7544 N-Channel “AlphaMOS” MOSFET. Two of them per channel would fit with my current understanding of brushless motors.
One of the remaining two chips should be a voltage converter to translate battery power to a lower voltage for the unidentified microcontroller and gate driver chip. But on the lower left, next to the ground wire, is an unexpected entity. It looks like a WS2812 or similar RGB LED module which is much fancier than the single LED I would have expected for an indicator light.
There’s a mysterious name “BLHeli_S” on the Amazon listing and also printed on the front label of this motor controller. A web search found this to be the name of motor control firmware.
(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.
I’ve purchased an AS7341 breakout board from Adafruit (#4698) and read through their guide (single-page view) on the board. It’s nice to see their library takes care of the complexity of this chip’s internals such as SMUX configuration. Examples that come bundled with a library is always a good overview of capabilities, and this is what I see from its examples directory:
basic_counts: “Basic Counts” is a concept described in the AS7341 calibration application note. A bit of math that takes raw sensor counts and compensates for gain and integration time. AMS recommends application logic work with “Basic Counts”. This lets us change gain and integration based on environment and still keep the rest of the application logic unchanged.
flicker_detection: Prime concern of flicker detection is with household AC power frequencies of 50Hz or 60Hz however this sensor is not limited to those rates. The datasheet says it can detect flicker frequencies up to 2kHz. This capability feels like a potential project all by itself, I’ll have to think more about it.
get_channel: Performs a read of all channels then iterates through 10 spectral sensing channels of 8 visible spectrum + clear + infrared to print their raw counts. (Flicker detection channel is ignored.)
gpio_example: Using the “GPIO” pin as a digital output. High for 3 seconds and low for half a second and repeat. Important note: according to board schematic published by Adafruit, the GPIO pin is brought out directly to the headers. There is no voltage level shifting or protection on this pin so be sure to consult datasheet and be nice to this 1.8V part.
gpio_input_example: Using the “GPIO” pin as digital input. Samples every half second and prints either “high” or “low” to serial console.
led_test: The canonical “blink a LED” test implemented with the LED Adafruit installed on the breakout board connected to AS7341’s LDR pin. Lights up at 4mA for 1/10th of a second, dark for half a second, light up to 100mA for 1/10th of a second, dark for another half a second, and repeat. Note while the AS7341 constant current control register goes up to 258mA, we shouldn’t go that far. According to board schematic published by Adafruit, the onboard LED is an EAHC2835WD6 with recommended ceiling of 150mA and absolute maximum of 180mA.
plotter_example: A clever variation on get_channel designed to work with Arduino IDE’s Serial Plotter feature. Five comma-separated sensor values are printed on a line so that when we turn on Serial Plotter, the plotter line drawing colors are close to the color wavelength of that sensor.
read_all_channels: This is almost identical to get_channel. The only difference is this sketch passes an array into the call to readAllChannels() and prints from sketch’s own array. get_channel does the exact same thing using the array stored in Adafruit library object.
reading_while_looping: Most of these examples call readAllChannels(), which is a blocking call that waits for sensor integration to complete before returning with results. Depending on integration time configuration, delay caused by waiting can be problematic. This sketch illustrates a way to initiate AS7341 integration and yield control so other things can happen until integration is complete. Note: the I2C operations involved are still blocking calls via Arduino’s Wire library.
smux_test: I didn’t understand this sketch. It has an empty loop() and I don’t see how setup() tests SMUX in any way.
spectral_interrupts: By its name I hoped to see a demonstration of using AS7341 INT pin to generate a hardware interrupt signal for Arduino microcontroller, triggering an ISR (interrupt service routine) for sensor read. I was wrong, the “interrupt” for this sketch is merely a register flag that we read from within loop().
synd_mode: By its name I hoped to see a demonstration of using GPIO pin to trigger start of AS7341 sensor integration. This time I think I got my wish! Unlike all of the other examples, this sketch doesn’t use Adafruit’s AS7341 library and was not written by anyone at Adafruit. It uses the Wire library directly and was written by an AMS application support engineer.
Despite mysteries like smux_test, I see a good set of examples here to help me become familiar with AS7341 capabilities. A sensible person would start their exploration with simple modifications to one of these sample sketches. I did not go down that path of sensibility.
I wanted to play with the AMS AS7341 11-channel spectral color sensor and the easiest way is to buy a breakout board making it easier to work with that tiny little 1.8V surface-mount chip. DFRobot has reasonable looking products but I ended up going with Adafruit’s AS7341 board, item #4698.
Compared with DFRobot’s offering, the Adafruit board has only a single LED instead of two. Neither of them brought out LDR pin for controlling external illumination. They both include all the voltage level handling necessary to allow 3.3V and 5V microcontrollers to talk to this 1.8V chip. DFRobot offered two products: one with their solderless Gravity connector system and a different offering compatible with 0.1″ pitch headers. Physically, Adafruit’s #4698 is slightly larger, but it has both 0.1″ pitch headers and their STEMMA QT connector. These are also known as JST-SH connectors, and I’ve already purchased a set (*) originally intended for use with BeagleBone Blue. Having both options for connectivity down the line is appealing to me, and I’ve been a longtime Adafruit customer. Which meant there were other things I wanted to buy from Adafruit anyway. It was minimal additional effort and cost to add AS7341 to an order and wait for it to show up.
Once the sensor arrived (UPS required a few extra days beyond original estimated delivery) I connected it to an ATmega328P Arduino Nano on a breadboard. As is typical of Adafruit, they have developed an Arduino library to communicate with this sensor, and I could load up the led_test example sketch as a quick test to see if it worked.
I’m intrigued by the AMS AS7341 11-channel spectral color sensor, and I’ve reached the limits of what I can learn from its (somewhat disappointing) datasheet and application note documentation. It’s time to get some hands-on experience with the device, which hopefully would help me understand more of the documentation in a positive feedback cycle. Plus I just want to start playing with it.
I could buy the sensor chip itself from Digi-Key, which has published a product page highlighting AS7341. Cost is reasonable for single quantities ($11.42 at time of writing) but at 3.1mm x 2mm x 1mm it is far too small for me to handle directly. I need a breakout board. The most obvious choice is AMS’ own evaluation kit, but that is priced far too high ($189.38) for me to stomach. Thankfully there are other companies providing AS7341 breakout boards for electronics hobbyists like myself.
DFRobot is one of these companies, and it has not one but two AS7341 offerings that differ by physical interface. Product SEN0364 has connectivity via DFRobot’s “Gravity” connector. Its sibling product SEN0365 has generic 0.1″ pitch breadboard-compatible headers. They both have mounting holes and voltage level shifters/converters for both signal and power interface with 3.3V and 5V parts. (AS7341 itself is a 1.8V part.) The Gravity port only has I2C communication, but the 0.1″ header version also break out INT (optional signal for “reading complete”) and GPIO (optional signal for “start reading”). Both include a pair of white LEDs for illumination controlled by AS7341 LDR pin, but that also meant LDR was not brought out so we can’t use it to control external lights.
On the software front, DFRobot provides an Arduino library and several example projects. I thought their household lights comparison test was very interesting, using an AS7341 to show difference in emission spectra of various household lights. I understood the spectral plots, but they lost me when the math started going into CIE color spaces like the AMS calibration data sheet did. The biggest problem with this example project is that its online listing is incomplete: the Arduino sketch for interfacing with AS7341 is listed, but the Processing sketch was missing. It plots results on a desktop computer screen and screenshots were included in the project writeup. Without it we’d just have a bunch of numbers in a serial terminal. It shouldn’t be too hard to recreate using Processing’s Serial library if one felt motivated to do so. Still, its absence was annoying.
Interesting but incomplete example projects won’t change the fact DFRobot SEN0364 and SEN0365 seem like reasonable options for AS7341 breakout boards. Another option for AS7341 breakout board is Adafruit product #4698, which is what I eventually bought for myself.
I’m learning the ropes of using an AMS AS7341 11-channel spectral color sensor, figuring out what I absolutely need and what I will wait to explore later. So far, I have found AMS product datasheet to be lacking. The topmost irritation was missing information on configuring the sensor multiplexor, a critical component inside the chip. It was also missing information on higher-level concepts for a color sensor and how the AS7341 implements them. I found some of this information in the document titled Spectral Sensor Calibration Methods which is listed as an Application NoteCalibration Methods AS7341 EVKs.
This document taught me how an ideal spectral detector would activate on a specific wavelength, but real-world implementation is sensitive to a range of wavelengths near that target. This is why its documented response curve is a series of bell curves and not a set of spikes. Furthermore, there may be responses far from the target wavelength due to a variety of other factors.
This foundation led to an explanation of why, in addition to 8 different wavelengths within the visible spectrum, the sensor also had three additional sensors: A “Clear” sensor with no color filter, a near-infrared sensor, and a flicker detection system. Originally I had thought they were just thrown in for the sake of more features, but this application note explains they support the 8 color sensors by detecting problems that throw off readings.
I have to admit I did not understand much of the discussion about plotting sensor readings into CIE color space. Color science is a field with a long history and reading Wikipedia pages only taught me that there is a lot I don’t know. Clearly this application note is aimed at an audience who is already familiar with the topic.
But even if I was familiar with CIE color spaces, this document left a lot of gaps in information. This application note referenced a piece of software called “AS7341 Software GUI, running on a Windows personal computer” but that software is nowhere to be found on AMS website. It appears to be something I can obtain by contacting my AMS account representative, which I don’t have. There are also snippets of a large Excel spreadsheet, with the disclaimer “Tables were interrupted. See the full tables in the original MS Excel File.” And is this MS Excel file on the website? Apparently not: “Ask the ams support team for the original XLS file” And there was a section that ended with “For more details, please refer to the Sensor ECGs manual.” What is ECG? That was not explained. And so on.
I learned a lot from AMS documentation for AS7341 but I felt there were significant room for improvement. Nevertheless, I am confident enough in my understanding to get hands-on with AS7341 sensor.
I’m starting to get a handle on the basics of an AMS AS7341 11-channel spectral color sensor. I know how to control sensitivity and exposure time, and I know I lack information on configuring the sensor multiplexor (SMUX) within the device. These are critical parameters for taking any readings and I need to understand them up front. For the moment I’ll postpone the following auxiliary functions that I (hope) are not crucial to sensor operation.
Given this chip only has 8 pins to the outside world, I was surprised that one pin (LDR) was allocated to the task of sinking current for a LED. But it made sense once I thought about it: a source of illumination is a common need for spectral sensor applications. According to figure 37 describing the LED register, it is a constant-current sink that defaults to 12mA which is more than enough to illuminate a single LED. The register implies quite a range of current handling: we can set it to go as low as 4mA and as high as 258mA. A quarter of an amp is quite a lot for a single LED so I guess this is for driving multiple LEDs in parallel. For example, if we want to surround the sensor with a ring of lights. Even then, at a quarter of an amp I’d start to worry about thermal issues.
And heat is definitely a concern for this sensor, judging by its built-in capability to compensate for device temperature. This “autozero” capability takes about 15ms to perform and we can configure its frequency in the AZ_CONFIG register 0xD6. By default, autozero runs once before taking first reading and never again. We can configure it to run more frequently, in terms of once every X readings. I don’t know how important temperature compensation is for this sensor. There’s a chance it is only important for those who need absolute precision, but it is important enough to run at least once. (Datasheet recommends against setting register to zero.)
Back to pins on the chip: INT can be configured to signal that a sensor reading is complete, intended to be connected to a microcontroller pin that signals an interrupt. This is not required as we can optionally poll the STATUS2 register via I2C for a bit indicating sensor reading is complete. And finally, a pin can be used to start a sensor reading but can also be used for general input/output hence it is labeled GPIO. This is also optional: we can start a sensor reading via I2C by setting a bit in the ENABLE register.
These features and others are neat but are not required for taking spectral color sensor readings. Either because they’re not required at all (LED), or their default values are good enough to start (autozero) or we have alternatives (INT and GPIO.) I can come back to play with these later. For now, I want to learn some higher-level concepts about this sensor via its color calibration application note.
I want to understand the capabilities of the AMS AS7341 11-channel spectral color sensor and started orienting myself with its datasheet. The sensor seems quite capable but also quite complex to operate. The biggest barrier on the critical path (I must understand it to do anything with the sensor) is SMUX or sensor multiplexor. The onboard ADC (analog to digital converter) only has 6 channels to serve 11 sensor channels, the SMUX decides which subset of 6 is read at any given time.
Given their importance, I was quite baffled to find no documentation in the datasheet describing SMUX configuration registers. The closest thing I found was in section 8.4:”ams provides reference code and an application note on how to configure the SMUX.” [UPDATE: Found the Application Note.] First of all, sample code is not a substitute for proper documentation. Second, I see neither sample code nor SMUX configuration application note on the product’s supporting documents section. This is… unsatisfactory.
I hope I can resolve that “WTF?” item later, so I set that aside and continued learning about sensor parameters. I started thinking of this sensor as a small digital camera and I could use photography analogies to understand AS7341 parameters. A digital camera has three important variables in every shot:
Aperture size
Shutter speed controlling duration of exposure
Film ISO equivalent controlling sensor sensitivity.
For an AS7341:
It is a point sensor, so its aperture size is a pinhole camera and not adjustable.
Integration time parameters control duration of exposure, equivalent to shutter speed.
Gain parameter control sensor sensitivity, equivalent to ISO.
Integration time is controlled via parameters ATIME and ASTEP. ATIME is a single register at 0x81, and the entire range of 8-bit values (0-255) are valid. ASTEP is a 16-bit value split across two registers: 0xCA (low byte) and 0xCB (high byte.) 65535 is a reserved value for ASTEP, but 0-65534 are valid. Together they control the ADCfullscale parameter, which is defined as (ATIME+1)*(ASTEP+1) and has this footnote:
“The maximum ADC count is 65535. Any ATIME/ASTEP field setting resulting in higher ADCfullscale values would result in a full-scale of 65535“
This I found curious: if the maximum is 65535, the maximum possible representation in 16-bits, why do we need ATIME at all? ASTEP can cover the entire 16 range all by itself rendering ATIME superfluous. There’s a story here missing from the datasheet.
As a starting point for exploration, the datasheet listed 50ms (ATIME 29 ASTEP 599) as the typical integration time. I’ll start there and go higher or lower as needed. And as I’m just starting out, I hope I can safely ignore some of the auxiliary features until later.
I have some grand dreams about what I might do with an AS7341 spectral color sensor, but things are always easier in the fantasy world than in the real world. To turn ideas into reality (or to see if it’s realistic at all) I need to learn the nuts and bolts of the sensor. Which means starting with its datasheet downloadable from AS7341 product page on AMS website. It answered some questions but opened many more.
The first and most important data point is its I2C address: 0x39 and I found no way to change it. (Datasheet section 9.1) It means this sensor is not designed to work in conjunction with others of its kind on the same I2C bus, there can be only one. The sensor is still responsive to I2C traffic when in sleep mode, which might be useful. (Datasheet 8) Also useful is a device identification register to verify I2C communication is working properly. (Datasheet 10.2.4)
The next important note was the chip’s internal architecture (Datasheet 8.1): there are 11 different sensors that could be read, but onboard ADC (analog-to-digital converter) has only 6 channels and a sensor multiplexor (SMUX) which controls which sensor is connected to which ADC and which are left disconnected. In order to read all 11 sensors, we need to make one read operation with 6 sensors then reconfigure SMUX to read the remaining 5. This architecture hints at the challenges ahead.
Each of these ADC channels have 16-bit resolution, and some configuration parameters are 16-bit values as well. This chip organized its registers such that the low order byte comes first, immediately followed by the high order byte. Read operations latch these registers, so the value does not change between reading the low byte and reading the high byte. (Datasheet 9)
My home theater had a small powered subwoofer, an Insignia NS-RSW211 Rocketboost 6-1/2″ 70W Wired/Wireless-Ready Subwoofer. After several years of use, it started exhibiting some strange effects and I disconnected it. Since I’m not a huge home theater buff and it was a modest unit to begin with, I didn’t really miss its absence. It sat forgotten in a corner until I saw Monoprice held a sale on their item #8248, a similar-sized powered subwoofer that would be a great replacement. Before I hit “Buy” on the Monoprice item, though, I thought I should make an effort to fix the one I have.
The failing symptoms indicate an intermittent connection somewhere in the system. When I turn on the subwoofer, it is fine for the first few minutes. After that initial period, sound would start cutting in and out at irregular periods. Every time it cuts out, the low bass sounds disappear. When it cuts back in, a deep “thump” announces return of low frequencies. This would start out tolerably infrequent, like hearing a distant firework show. Interruptions then become increasingly frequent. Eventually it will sound like automatic weapons fire in the background even when we’re not watching an action film, at which point I would turn it off. After a few hours of rest, I could repeat the cycle. Intermittent issues are always annoying to diagnose (part of why I’ve been putting it off) but I should at least take a look. On to the workbench it goes!
There are a lot of fasteners visible on this back plate. This is not a huge surprise: a subwoofer’s job is to push those low frequency thumps. Each thump will rattle anything not securely fastened, and every thump will be trying to loosen every fastener. In fact, the large numbers of fasteners are quite welcome: if it had been glued together, opening it up would be a destructive act making a successful repair unlikely.
But it wasn’t glued, so I could get to work. Removing the outermost eight fasteners allowed me to remove the rear module. I was a little surprised to see all electronics were sealed inside an airtight box. This might be good for acoustics but bad for air cooling circulation. The only thing poking into the acoustic chamber are the pair of speaker wires going to the driver itself. They used commodity spade connectors and were easy to disconnect so I could focus on the electronics box.
Removing the next outermost set of six fasteners allowed me to open up the electronics box. I was greeted with the thick stench of fried electronics. Something definitely died in here and, if it smelled this strong, I should be able to see it.
Yep, there it is. Capacitor C28 is toast. Finding this dead capacitor is good news, much easier than diagnosing an intermittent issue. The bad news is I’m not familiar enough with power supply theory of operation to explain why this absolutely and completely dead capacitor would cause an intermittent failure.
One end has completely blackened and appears to have broken open as well.
The yellow circuit board appears to be the power supply subsystem. 120V AC power cable (black & white wires) goes to the power switch, then into one corner of this yellow board near the dead capacitor. Diagonally opposite them is this connector delivering +24V DC to the rest of the subwoofer.
Unplugging AC input and DC output wires, then removing four screws, allowed removal of this power supply board so I could unsolder the dead capacitor. It came off in two separate pieces, very dead.
Reading markings on the charred capacitor carcass was a challenge. After playing with lighting, camera settings, and photo editing, I could make it out as:
105K
250KC
I’m not familiar with this type of capacitor and didn’t know how to interpret those numbers. Looking around online, I found this page which said “105” meant 10 * 105 pF = 1000000 pF = 1000 nF = 1 uF and the “K” meant +/- 10% tolerance. The voltage rating portion didn’t line up with anything on that page, though. I’m inferring that “250KC” means something that can handle up to at least 250V, as this device can take up to 230V AC input.
Looking around my various assortment trays of capacitors, I didn’t find anything +/- 10% of 1uF. I then looked through my pile of teardown remnants for capacitors to salvage. The closest candidate was a 0.68uF 450V capacitor from the Antec power supply that caught on fire.
It even had the same footprint as the original toasted capacitor, making for an easy fit in the available space. However, 0.68uF is still short of the capacitance of the original so I continued looking.
I found a 0.22uF 250V capacitor inside the surprisingly complex evaporator fan. There was a clear conformal coating over everything that made removal a bit of a pain (and the result looking messy.) But they gave me a theoretical 0.68uF + 0.22uF = 0.90uF and my multimeter says they’re actually a tiny bit above rated value. Bringing me within 10% of 1uF, good enough for a test run.
Since the original capacitor slot was already occupied by the 0.68uF capacitor, the second parallel capacitor had to sit on the back.
I buttoned everything back up and preliminary test looks promising. After playing through a two-hour movie, I have yet to hear the thumping “fireworks” to “gunfire” failure sequence. Still unknown: what killed the original capacitor, and whether the same will happen to these replacements. Time will tell. In the meantime, I’ve managed to keep something out of landfill and resisted the temptation to buy a Monoprice powered subwoofer on sale. I’m thankful the design & engineering team built this device in a repairable way.
[UPDATE: This repair gave me another year of use out of this powered subwoofer before it died again.]
Thanks to prompting by a comment, I am picking up where I left off trying to supply power over a USB-C cable. I love the idea of USB Power Delivery, the latest version covers transferring up to 240W over a USB Type-C cable. But that power also comes with complexity, and I didn’t want to figure out how to establish a power delivery contract when my project really just wanted five volts. Fortunately, the specification also describes a low-complexity way to manage 5V power over USB Type-C. But I had to be confident I was dealing with the correct wires, so I probed wiring with a small breakout board. (*) I confirmed that the four red wires were VBUS, the green and white wires were indeed the differential data pairs, and the mystery yellow wire is the VCONN or CC (cable configuration) wire on the same side.
Ah, yes, that “same side” was an interesting find. USB Type-C is physically shaped so there’s no “upside-down” way to insert the plug, with symmetric wires. However, that also means each side has a set of D+/D-/CC wires, and a USB Type-A to Type-C adapter only connects to one side. It is up to the Type-C device to check both sides.
In my previous experiment I learned that just connecting +5V to red and ground to black was enough to be recognized as a power source by some Type-C device but not my Pixel 3a phone. I found multipleguides that said to connect a 56kΩ pull-up resistor between CC and VBUS, but I wanted to know a little bit more without diving into the deep end of USB specifications. I found a very accessible post on Digi-Key forums describing the details of 5V @ 3A = 15W power over Type-C. Which is itself a simplified version of a much more complex Digi-Key overview of USB power.
Like several other guides, it mentioned the resistors on both ends of the Type-C cable, but it also had this phrase: “Together they form a voltage divider” which was my “A-ha!” moment. It allowed components to negotiate 5V power delivery without a digital communication protocol. We just need a resistor on either side: one for the provider to indicate the amount available, and the other by the consumer to indicate its desired consumption. Then we just need an ADC to measure voltage value of the resulting voltage divider, and we’ll know the safe power level.
When I added the 56kΩ pull-up resistor to my circuit, my Pixel 3a lit up with “Charging slowly”. I thought it was successfully charging at 500mA, but it wasn’t. Over the next half hour, its battery level actually dropped! I put the circuit under a USB power meter(*) and found it was only drawing a feeble 40mA. That meter also told me why: my circuit had supplied only 4.3V because I had a transistor in the circuit for power control and it dropped 0.7V from collector to emitter. This was why the power level was so low: a pull-up resistor to 4.3V was below the voltage threshold for 500mA power.
In order to create a microcontroller-switchable 5V (not 4.3V) power supply, I went with my most expedient option of using another voltage regulator with an enable pin connected to what used to be the transistor base. This raised the divided voltage within 500mA range, and finally the Pixel 3a started charging at that rate as confirmed by the USB power meter. And as an experiment to confirm my understanding, I dropped pull-up resistance down to 22kΩ. This raised the resulting voltage at the divider, and USB power meter reported that my Pixel 3a started drawing 1.5A. My buck converter is rated to handle this output and this way the phone charges faster.
I am interested in electronics, in teardowns, and in electronics teardowns. Thus I was the exact audience for a book coming out soon: Open Circuits by Eric Schlaepfer and Windell H. Oskay. I preordered directly from publisher No Starch Press, which also granted me access to an early access eBook. I’ve finished browsing through that PDF and loved every page of it. I look forward to having the print book in my hand.
I first became aware of these cutaways from Twitter, where author Eric Schlaepfer tweeted a few cross sections shot with a cell phone camera via @TubeTimeUS. Feedback was positive, encouraging Eric to repeat the same treatment for more components, improving the techniques as he went. Things got popular enough that a vocal subset of his new Twitter following got grumpy when he went back to his regular programming. (Paraphrasing his reply: “Come on, guys, this account isn’t @CrossSectionTimeUS.”) Still, people loved the cross-sections and some said “I would love to have these pictures in a coffee-table book.” Thus this book Open Circuits.
Every component cross-sectioned in the book is accompanied by a brief explanation of the component. Knowing what a component does and how its internals accomplish the objective helps give us context to understand what we see in the pictures. Sometimes there’s a diagram with subcomponents called out as a visual explanation augmenting the text description. I knew roughly what some of these components did, but most of them were new information for me. But even if I had known of a component, usually I hadn’t known what it looked like inside! Every page is a new discovery. Occasionally, I even recognized something that I’ve seen before. For example, I recognized a thermal switch as something I took out of a retired coffee maker but I wasn’t sure what it was until I saw one explained and cross-sectioned.
This book is aimed at people who want to know more about what happens behind the scenes, so naturally the book covered that as well: the afterword section describes the techniques that went into this book’s photography. From cutting and polishing of components, to cleaning and mounting, to the photography process. Starting with cameras and lenses, to macro photography, and finally focus stacking to compose the sharp pictures in the book.
If you’ve read this far, you will enjoy the book as well.
We're thrilled to announce our forthcoming new book:
Open Circuits: The Inner Beauty of Electronic Components
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.
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.
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.
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.
New Screwdriver 