Notes on “Make: Bluetooth” by Allan, Coleman, and Mistry

As a part of a Humble Bundle package of books published by Maker Media, I had the chance to read through Make: Bluetooth (*) by Alasdair Allan, Don Coleman & Sandeep Mistry. This book covers a series of projects that can be built by the Make audience: by assembling development breakout boards and discrete components on prototype breadboards.

One of the first things this book covers is that these projects all use Bluetooth LE and not “Classic” Bluetooth. They share two things: (1) they both communicate over 2.4GHz range of RF spectrum, and (2) they are both administered by the Bluetooth Special Interest Group. Other than that, they are completely different wireless communication protocols named for maximum customer confusion.

For each project, this book provides a detailed step-by-step guide from beginning to end, covering just what we need for each project. This is both the book’s greatest strength and leads to my biggest criticism. Minimizing extraneous information not pertinent to the current project avoids confusing beginners, but if that beginner wants to advance beyond being a beginner, this book doesn’t provide much information to guide their future study. This problem gets worse as the book ages, because we’re not given the background information necessary to adapt. (The book is copyrighted 2016, this post is written in 2022.)

The first example is the Bluetooth LE module they used for most of the book: Adafruit product #1697, Bluefruit LE – Bluetooth Low Energy (BLE 4.0) – nRF8001 Breakout. The book never covers why this particular BLE module was chosen. What if we can’t get one and need to find a substitute? We’re not just talking about a global chip shortage. It’s been years since the book was written and Adafruit has discontinued product #1697. Fortunately, Adafruit is cool, and added a link to their replacement products built around the nRF51822 chip. But if Adafruit hadn’t done that, the reader would have been up a creek trying to figure out a suitable replacement.

Another example was the phone interaction side of this book, which is built using Adobe PhoneGap to produce apps for either iOS or Android phones. And guess what, Adobe has discontinued that product as well. While most of the codebase is also available in the open-source counterpart Apache Cordova, Adobe’s withdrawal from the project means a big cut of funding and support. A web search for Apache Cordova will return many links titled “Is Apache Cordova Dead?” Clearly the sentiment is not optimistic.

The Bluetooth LE protocol at the heart of every project in this book was given similarly superficial coverage. There were mentions of approved official BLE characteristics, and that we are free to define our own characteristic UUID. But nothing about how to find existing BLE characteristics, nor rules on defining our own UUID. This was in line with the simplified style of the rest of the book, but at least we have a “Further Reading” section at the back of the book pointing to two books:

  1. Getting Started with Bluetooth Low Energy (*) by Townsend, Cufí, Akiba, and Davidson.
  2. Bluetooth Low Energy: The Developer’s Handbook (*) by Heydon

I like the idea of a curated step-by-step guide to building projects with Bluetooth LE, but when details are out of date and there’s nothing to help the reader adapt, such a guide is not useful. I decided not to spend the time and money to build any of these projects.

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

Monoprice Monitor Internals: Round 2 (10734)

Leveraging Bitluni’s work, I was able to convert one of my ESP32 into a VGA signal generator that outputs full-screen white. This gave me a low-impact way to convert a malfunctioning monitor into a lighting fixture. But the low-impact way is definitely not the optimal way, because it meant I would need a VGA cable dangling outside of the screen, connected to an ESP32, which needs its own power supply. What are my other options? The first time I opened up this monitor, I didn’t understand very much of what I had looked at. A few years of tinkering lessons have been added to my brain, so I’ll open it up again for another look.

This display was spared from the Great Backlight Liberation because it could still be powered on, but once I had it open, I wanted to examine its backlight in light (ha ha) of new knowledge. I found the likely wire harness for this panel’s backlight, a respectable bundle of twelve wires. Flipping over the circuit board, I see those wires were labeled with:

  • G_LED1-
  • G_LED2-
  • G_LED+
  • B_LED+
  • B_LED1-
  • B_LED2-
  • B_LED3-
  • B_LED4-
  • B_LED+
  • G_LED1
  • G_LED3-
  • G_LED4-

Based on these labels, we can infer there are four “G” LED strings and four “B” LED strings, each with their own “-” wire. There are two wires for “B_LED+”, but the “G” LEDs have separate “G_LED+” and “G_LED1”. I don’t know why they were labelled differently, but my multimeter found electrical continuity between “G_LED+” and “G_LED1” so they are wired in parallel, as are those two “B_LED+” wires. Leading me to believe that “G” and “B” LEDs each have two “+” wires corresponding to four “-” wires. So far, so good. I then turned on the monitor to probe voltage levels of these wires. I had expected something in the neighborhood of the 24V DC power supply that feeds this monitor, but my meter said the voltage level is actually in the neighborhood of 64V to 68V DC. Yikes! That’s well above maximum voltage of any boost converter I have on hand, so driving the backlight without this board wouldn’t be my top choice.

I see inductors and capacitors that are likely the boost conversion circuit for this backlight, but I didn’t see a promising chip that might be a standalone LED driver like I see in some laptop panel teardowns. I think it is all controlled by that central main chip sitting under a heatsink. I couldn’t make it drive the backlight with a PWM signal like I could the laptop panel, so I have to stay with the ESP32 VGA signal generator.

The next question is then: could I use this board to drive just the backlight? To test this possibility, I unplugged these two cables connecting to the LCD array. Some of these wires carry power, the rest carry LVDS pixel data. When fed with VGA data from my ESP32, this control board happily powered up the backlight even when it couldn’t communicate with the LCD array. This is a very promising find, but I’m not ready to commit to a destructive separation just yet.

By itself, without an incoming video signal, this monitor quickly goes to sleep mode. I know that my ESP32 VGA signal can keep it awake past that initial sleep mode, but I’m not yet confident everything else will continue running for the long term. The only diagnostic channel I have for this system is the on-screen display, and if I should separate the LCD from its backlight, I would no longer be able to read the on-screen display.

It’s very tempting to separate them now, because I know a lot of light is trapped back there. Look at the brightness difference when I compared a bare backlight with the same non-broken (and non-separated) Chromebook panel. I expect there to be a very bright backlight behind this LCD. But for the sake of doing things incrementally, I’ll leave the LG display module intact for now and focus on integrating my ESP32 VGA signal generator.

Pinout for Asiahorse 120mm Fan (Magic-i 120 V2)

The Asiahorse Magic-i 120 V2 bundle included three 120mm cooling fans with integrated addressable RGB LEDs. These fans have a six-wire connector designed to be plugged into a hub that was included in the bundle, along with a remote control to change the light shown performed by those LEDs. Most users just need to plug those fans into the included hub, but some users like myself want to bypass the hub and control each fan directly. For this audience, I present the fan connector pinout derived from an exploratory session on my electronics workbench.

Since this was reverse engineered without original design documents, I don’t know which side is considered “pin #1” by the engineers who designed this system. These connectors appear to be JST-PH, whose datasheet does point to one side as “Circuit #1”. But there’s no guarantee the engineers followed JST convention. To avoid potential confusion, I’ll call them only by name.

+12VFanHigh side of fan motor. Hub connects this wire directly to +12V power input.
Motor LowFanLow side of fan motor. Use a power transistor between this wire and ground to control fan speed.
GroundFan + LEDPower return for LED circuit and can be used for fan motor low side as well. Hub connects this wire directly to power input ground.
Data InLEDInput control signal for addressable RGB LED. Compatible with WS2812/”NeoPixel” protocol.
+5VLEDPower for LED circuit. Hub connects this wire directly to +5V power input.
Data OutLEDControl signal for addressable RGB LED beyond the end of LED string inside the fan. Useful for chaining multiple units together by connecting this wire to Data In of the next device in line.

Now that I understand its pinout, I will build my own control circuit to replace the default Asiahorse hub.

Exploring 6-Wire Connector of Asiahorse Magic-i 120 V2

I was curious about PC accessories with embedded addressable RGB LED, so I bought the cheapest item available on Newegg that day. I have verified it works as originally intended, and now I’m going to dig deeper. This Asiahorse Magic-i 120 V2 is a three-pack of 120mm fans with integrated LEDs. All three fans plug into a hub that has a corresponding remote control for me to select from a list of programmed patterns. This bundle is fine if I’m satisfied with those patterns, but I want display patterns of my own.

Each fan connects to the hub through this six-wire connector. The distance between each pin is 2mm. Judging by the pitch and physical appearance, I guess they are JST-PH or a clone. (I don’t have any 6-conductor JST-PH to verify.) This is mildly inconvenient because my workbench is setup to work with 0.1″ pitch (~2.54mm) connectors so it’s not very easy for me to probe those signals as-is.

The solution is a quick soldering project to give me an exploration board. I cut the bundle of six wires and inserted a small piece of perforated prototype board. Each of the six wires are then bridged with an exposed length of solid wire, easy for me to clip probes onto.

Trying the easy thing first, I probed for continuity between these six wires and the power input wires. This gave me location for +12V source, +5V source, and ground. Armed with this information, I soldered capacitors to smooth out both power rails, because the AC adapter I’m using is designed for far higher wattage than a few LEDs and it’s not unusual for switching power supplies to be noisy at low power levels. (And the cheap ones are always noisy at all power levels…)

With three out of six wires identified for power, this left me with three more wires to decipher. Here are my candidates:

  • Fan control: it may be one (or none) of the following:
    • Fan motor high side: the fan may be internally connected to the ground wire, and the high side wire is left exposed here for external PWM or on/off control with a power transistor.
    • Fan motor low side: the same idea but reverse: fan motor is internally connected to +12V and the low side is exposed here for external PWM or on/off control with a power transistor.
    • Fan motor PWM: Neither of the above. Instead of leaving either high or low side unconnected for external power transistor, a suitable power transistor is built into the fan and controlled with a 25kHz PWM signal as used in 4-wire fans.
  • Fan tachometer like the type I found in 3-wire fans.
  • LED Data In: addressable RGB signal input.
  • LED Data Out: signal that has passed through the LED string inside this device and ready to be passed on to other LEDs in other devices down the chain.

To decipher which wires are which of those candidate capabilities, I connected my Saleae Logic 8 to the three unknown wires. I started an analog waveform capture session and used the fan remote control to command that all fans show a solid green.

The top line in white stayed at 0V through the entire session. This may be the tachometer wire, or it may be fan motor low side. To determine which, I disconnected everything other than the +12V and ground wires. The fan did not move. I connected the wire corresponding to this white line to ground, and the fan started spinning. Conclusion: this wire is fan motor low side.

The middle line in brown shows a distinct repeating pattern. The bottom line in red shows the same repeating pattern, but delayed by 12 cycles. Since there are 12 LEDs in a fan, that means the middle brown line is LED Data In and the red line is LED Data Out.

To verify LED Data In, I connected +5V, ground, plus this wire to the data pin of a Pixelblaze. After I configured the Pixelblaze to emit control signal for a string of 12 x WS2812 (NeoPixel) LEDs, I saw them light up appropriately on the fan.

To verify LED Data Out, I connected it to the data input pin of an array of 64 WS2812 LEDs. I configured the Pixelblaze for 12 + 64 = 76 pixels. After colorful pixels cycle through the fan, they marched onwards to the array as appropriate for LED Data Out.

With these functions verified, I’m confident enough to describe this Asiahorse fan pinout.

Asiahorse Magic-i 120 V2

I wanted to play with a set of PC case cooling fans with embedded addressable RGB LEDs, with the intent of learning how to control them for a future project. For extra challenge, I got a multipack that combined both fan and LED controls into a single (probably proprietary) connector that plugged into a bundled hub. Using the selection criteria of “Lowest bidder of the day” I bought a three-pack of fans: the Asiahorse Magic-i 120 V2 and I look forward to seeing how it works.

Before I start cutting things up, I need to verify the product worked as originally designed. I won’t need a computer for this as this multipack came with a remote control for the hub that allows operation without a computer. This lets me explore its signals without the risk of damaging a computer. I just need to supply power in the 4-pin accessory format popular with pre-SATA hard drives and optical disks. I didn’t need a computer here, either, as I had an AC adapter with this plug that originally came in a kit that turned internal HDDs into USB HDDs.

There were no instructions in the box, but things were straightforward. Three fans plugged into the hub, and a power cable connected my AC adapter to the hub. As soon as I turned on the power, all three fans started spinning. The LED light show didn’t start until I pressed the “On” button on the remote.

RGB LEDs in this fan are mounted in the hub, on the outside perimeter of the motor control board. I count 12 LEDs and they aimed along motor axis upwards into the center portion of translucent fan blades. These colorful lights are then diffused along length of the blade, resulting in a colorful spinning disk. While shopping on Newegg I saw other arrangements. Some fans have LEDs around the outside perimeter instead, and some fans illuminate both the hub and the perimeter. Each manufacturer hoping to capture the attention of a buyer with novelty of their aesthetic.

This remote control allowed me to cycle between various colorful programs or choose from a set of solid colors. I had hoped the colorful programs would ripple across the fans, but all three fans appear to display identical light sequence. I could control LED brightness or turn all the lights off, but I didn’t seem to have any control over fan speed. I guess this is where an instruction manual would have been useful.

If I wanted to build something bright and colorful that circulates air, almost everything is already here and ready to go. I just have to wire up a power switch to turn everything on/off, and the remote can take care of the rest. But I didn’t buy this just to have some lights. I wanted full control and I’m not afraid to start cutting things up to get there.

Shopping for PC Cooling Fans with RGB LED

I’ve decided to investigate controlling the RGB LEDs embedded in aesthetics-based PC accessories. I’m not interested in using them for my PC, but as research for a yet to be determined future electronics project. I wanted something that is a standardized commodity with a large range of variety in the ecosystem and have some usefulness beyond just looking shiny. I settled on 120mm PC cooling fans.

There are many common sizes for cooling fans, but I’ve found 120mm to be the most common for aftermarket cooling. They’re larger than average for CPU cooling, but not too large especially for heat-pipe based cooling towers. But they’re typically installed for general cooling in tower cases, whose cooling vents are cut for 120mm fans. Covering both popular use cases mean more options.

Looking around on my NewEgg, I find that fans sold individually typically have two separate connectors. One for LED and one for fan control. To the rest of the computer, these fans look like two separate peripherals: the LED and the fan. They just happened to coexist in the same device. The fan control connector sometimes just have two wires for +12V and ground. Some have a third tachometer wire for reporting speed, and some have a fourth wire for built-in PWM control. Here’s an example of a CPU cooler the Vetroo V5 whose fan has two connectors: a 4-pin CPU cooler fan control connector and a JRAINBOW RGB LED plug. These should be simple and straightforward to interface.

More challenging are fans that use an intermediate hub. The hub has a connector for power and for JRAINBOW, consolidating those signals into a proprietary connector. I started contemplating this particular Rosewill RGBF-S12001 three-pack of fans which use such a design. I think I can decipher roles of each wire so I could bypass the hub and control each fan directly. This multipack also had a remote control for direct control of the hub without a computer. This is appealing to me, because independent control meant I didn’t need a PC involved as I probed how it worked. If I should make a fatal mistake (say, accidentally short-circuited something) it should only kill the hub or the fan and not an entire computer.

As I scrolled down, though, Newegg showed me several other items under “similar products”. I saw an even more discounted three-pack of fans: the Asiahorse Magic-i 120 V2. Three fans for fourteen bucks, well within my impulse buy range. I’ll buy the pack and see what it does.

Repurposing PC RGB LED Accessories

I’m quite comfortable poking around inside the tower case of a DIY PC. I’ve built a few PCs from components, and I’ve bought a few that came prebuilt by a shop. In my PC experience I’ve focused on the functional side of things and haven’t paid much attention to the aesthetics side. There’s a whole segment of the market enchanted with flashy LEDs. As an electronics hobbyist, it had been hard for me to look at those accessories seriously. I know how little addressable RGB LED modules cost in bulk, and it is quite clear those PC accessories were sold at a huge profit margin. I would be more inclined to build my own LED creations like Glow Flow than to pay a premium just for overpriced flashy lights in my PC.

But what if I looked beyond products’ MSRP? Since this particular market is about novelty, just like the clothing fashion industry there is a high turnover of products. The huge profit margin entices startups hoping to make it big, and most don’t. High product turnover means there are those who upgrade to the latest look. Each of these scenarios can lead to products sold well below MSRP: (1) clearance sales on unsold inventory of “old looks” (2) liquidation sales from bankrupt companies, and (3) secondhand markets (eBay/Craigslist) for those who have upgraded. A bargain hunter can find LED-bedazzled gear well below the price of new equipment, and in extreme cases even lower than price of buying new WS2812 modules directly.

Well, now I’m interested! Not for my PC, but for potential future electronics projects. Which means looking at these products and try to figure out how I can repurpose them. I started by looking at the product pages for a few PC hardware component companies and their advertising spiel for RGB LED accessories.

  • Corsair uses the iCUE branding as an umbrella covering aesthetics-based accessories. Some are the addressable LEDs I care about, but not all of them.
  • Gigabyte uses the name RGB Fusion.
  • Asus calls theirs Aura.
  • MSI calls theirs Mystic Light.

I hit a gold mine on MSI’s Mystic Light site, because their FAQ included an entry “What is Mystic Light Extension” that gave the following description:

Mystic Light Extension is a feature of Mystic Light software which allows user to control colors and effects of partner’s product such as RGB LED Strips, RGB PC Fans or RGB PC Case via on-board JRGB / JRainbow / JCorsair pin header.

    JRGB (4-Pin / PIN-definition: 12V/G/R/B): The JRGB pin header provides up to 3A (12V) power supply for non-addressable 5050 RGB LED solution showing single color.
    JRAINBOW (3-Pin / PIN-definition: 5V/D/-/G): The JRainbow pin header provides up to 3A (5V) power supply for addressable WS2812 RGB LED (ARGB) solution showing rainbow color.
    JCORSAIR (3-Pin / PIN-definition: 5V/D/G): The JCorsair pin header provides up to 3A (5V) power supply to Mystic Light software compatible CORSAIR devices.

This tells me products that use the JRGB header are colorful but not individually addressable. Products using JRAINBOW or JCORSAIR are 5V devices that uses a single data pin and no clock. This is a very strong hint these products are made of LEDs made of either WS2812 (“NeoPixel”) or alternatives that understand the same control signals. I will go look for a bargain and try one out.

TMP36 Temperature Sensor + ESP8266 = Not a Great Team

After successfully building a small circuit for 3-pin fan PWM control, I decided to add a temperature sensor. Now I have the option to make it smarter about adjusting speed (or stopping entirely) based on temperature. There are many temperatures sensor options, I decided to start simply and inexpensively with a sensor that returns an analog voltage representing temperature. A batch of TMP36 (*) seemed like a good starting point.

According to the Analog Devices datasheet, TMP36 output pin voltage is 0.75V at 25 degrees Celsius. For every degree of temperature rise, voltage increases 0.01V. For my first draft I wired it to my Wemos D1 Mini module’s analog input pin. But I had to adjust the scaling because a D1 Mini includes a voltage divider to scale input of 0-3.3V down to ESP8266 ADC range of 0-1V. This voltage divider (and math necessary to convert it back) added error to the reading. Since I intend to use this sensor for measuring room temperature, I do not expect to measure above 50 degrees Celsius (122 Farenheit) which corresponded to 1 Volt. Thus, I soldered a wire to connect TMP36 signal directly to ESP8266 module analog input, bypassing the voltage divider.

I noticed that there appears to be a startup time period where the temperature reading is 2-3 degrees too high but, after about 5-10 minutes, it will drop to a steady state temperature and stay there. I’m not sure if this startup behavior is from the TMP36 sensor or from the ESP8266 ADC. Either way, it meant I could not use this sensor in a sleep/read/sleep/read cycle because such a quick read will always result in a too-high value from this startup behavior.

With the initial breadboard test complete, I built a dedicated temperature sensor node with just an ESP8266 with a TMP36. In the interest of compactness, I decided to solder the sensor directly to ESP8266 module pins.

Upon startup, I saw that it reported temperature that was a few degrees too high, but I thought that was just the startup behavior I already noticed. But instead of dropping, it had kept going up. I thought I had a bad TMP36 until I realized it was accurately reading heat generated by a running ESP8266. According to my USB power meter, it consumed less than a third of a Watt, but that’s plenty of heat for a directly-mounted TMP36 to pick up.

If I wanted to measure a room’s air temperature and not temperature of a running ESP8266, I needed to give the sensor some distance. But even then, the readings weren’t reliable.

A little web research taught me that the ESP8266 ADC isn’t very precise nor is it calibrated. For most applications, being off by a few hundredth of a volt is a negligible error, but here every hundredth of a volt represents an entire degree of temperature which is decidedly not negligible. Taking multiple values and averaging them did help with the precision, but not accuracy. Knowing what I know now, in hindsight I should have done this with an ESP32. Those chips (or at least newer units) have their ADCs calibrated at Espressif factory. Though it is more likely that I will try a different temperature sensor in a future project. Either way, right now I have TMP36 on hand with a circuit board suitable for controlling 3-wire PC cooling fans. Time to put them together to do something useful.

Even though it doesn’t work very well, here’s an ESPHome YAML excerpt anyway. This will read a TMP36 every second and report average value every five minutes. TMP36 signal is assumed to have been soldered directly to ESP8266 analog input, bypassing Wemos D1 Mini voltage divider.

  - platform: adc
    pin: A0
    name: "Mobile Node Temperature"
    unit_of_measurement: "°C"
    update_interval: 1s
    accuracy_decimals: 2
      - multiply: 100
      - offset: -50
      - sliding_window_moving_average:
          window_size: 450
          send_every: 300
          send_first_at: 15

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

ESP8266 Controlling 4-Wire CPU Cooling Fan

I got curious about how the 4 wires of a CPU cooling fan interfaced with a PC motherboard. After reading the specification, I decided to get hands-on.

I dug up several retired 4-wire CPU fans I had kept. All of these were in-box coolers bundled with various Intel CPUs. And despite the common shape and Intel brand sticker, they were made by three different companies listed at the bottom line of each label: Nidec, Delta, and Foxconn.

I will use an ESP8266 to control these fans running ESPHome, because all relevant code has already been built and ready to go:

  • Tachometer output can be read with the pulse counter peripheral. Though I do have to divide by two (multiply by 0.5) because the spec said there are two pulses per fan revolution.
  • The ESP8266 PWM peripheral is a software implementation with a maximum usable frequency of roughly 1kHz, slower than specified requirement. If this is insufficient, I can upgrade to an ESP32 which has hardware PWM peripheral capable of running 25kHz.
  • Finally, a PWM fan speed control component, so I can change PWM duty cycle from HomeAssistant web UI.

One upside of the PWM MOSFET built into the fan is that I don’t have to wire one up in my test circuit. The fan header pins were wired as follows:

  1. Black wire to circuit ground.
  2. Yellow wire to +12V power supply.
  3. Green wire is tachometer output. Connected to a 1kΩ pull-up resistor and GPIO12. (D6 on a Wemos D1 Mini.)
  4. Blue wire is PWM control input. Connected to a 1kΩ current-limiting resistor and GPIO14. (D5 on Wemos D1 Mini.)

ESPHome YAML excerpt:

  - platform: pulse_counter
    pin: 12
    id: fan_rpm_counter
    name: "Fan RPM"
    update_interval: 5s
      - multiply: 0.5 # 2 pulses per revolution

  - platform: esp8266_pwm
    pin: 14
    id: fan_pwm_output
    frequency: 1000 Hz

  - platform: speed
    output: fan_pwm_output
    id: fan_speed
    name: "Fan Speed Control"

Experimental observations:

  • I was not able to turn off any of these fans with a 0% duty cycle. (Emulating pulling PWM pin low.) All three kept spinning.
  • The Nidec fan ignored my PWM signal, presumably because 1 kHz PWM was well outside the specified 25kHz. It acted the same as when the PWM line was left floating.
  • The Delta fan spun slowed linearly down to roughly 35% duty cycle and was roughly 30% of full speed. Below that duty cycle, it remained at 30% of full speed.
  • The Foxconn fan spun down to roughly 25% duty cycle and was roughly 50% of the speed. I thought it was interesting that this fan responded to a wider range of PWM duty cycles but translated that to a narrower range of actual fan speeds. Furthermore, 100% duty cycle was not actually the maximum speed of this fan. Upon initial power up, this fan would spin up to a very high speed (judged by its sound) before settling down to a significantly slower speed that it treated as “100% duty cycle” speed. Was this intended as some sort of “blow out dust” cleaning cycle?
  • These are not closed-loop feedback devices trying to maintain a target speed. If I set 50% duty cycle and started reducing power supply voltage below 12V, the fan controller will not compensate. Fan speed will drop alongside voltage.

Playing with these 4-pin fans were fun, but majority of cooling fans in this market do not have built-in power transistors for PWM control. I went back to learn how to control those fans.

CPU Cooling 4-Wire Fan

Building a PC from parts includes keeping cooling in mind. It started out very simple: every cooling fan had two wires, one red and one black. Put +12V on the red wire, connect black go ground, done. Then things got more complex. Earlier I poked around with a fan that had a third wire, which proved to be a tachometer wire for reading current fan speed. The obvious follow-up is to examine cooling fans with four wires. I first saw this with CPU cooling fans and, as a PC builder, all I had to know was how to plug it in the correct orientation. But now as an electronics tinkerer I want to know more details about what those wires do.

A little research found the four-wire fan system was something Intel devised. Several sources cited URLs on which redirects to Intel’s documentation site. Annoyingly, Intel does not make the files publicly available, blocking it with a registered login screen. I registered for a free account, and it still denied me access. (The checkmark next to the user icon means I’ve registered and signed in.)

Quite unsatisfying. But even if I can’t get the document from official source, there are unofficial copies floating around on the web. I found one such copy, which I am not going to link to because the site liberally slathered the PDF with advertisements and that annoys me. Here is the information on the title page which will help you find your own copy. Perhaps even a more updated revision!

4-Wire Pulse Width Modulation
(PWM) Controlled Fans
September 2005
Revision 1.3

Reading through the specification, I learned that the four-wire standard is backwards compatible with three-wire fans as those three wires are the same: GND, +12V supply, and tachometer output. The new wire is for a PWM control signal input. Superficially, this seems very similar to controlling fan speed by PWM modulating the +12V supply, except now the power supply stays fixed at +12V and the PWM MOSFET is built into the fan. How is this better? What real-world problems are solved by using an internal PWM MOSFET? The spec did not explain.

According to spec, the PWM control signal should be running at 25kHz. Fan manufacturers can specify a minimum duty cycle. Fan speed for duty cycle less than the minimum is open for interpretation by different implementations. Some choose to ignore lower duty cycles and stay running at minimum, some interpret it as a shutoff signal. The spec forbids pull-up or pull-down resistor on the PWM signal line external to the fan, but internal to the fan there is a pull-up resistor. I interpret this to mean that if the PWM line is left floating, it will be pulled up to emulate 100% duty cycle PWM.

Reading the specification gave me the theory of operation for this system, now it’s time to play with some of these fans to see how they behave in practice.

Computer Cooling Fan Tachometer Wire

When I began taking apart a refrigerator fan motor, I expected to see simplest and least expensive construction possible. The reality was surprisingly sophisticated, including a hall effect sensor for feedback on fan speed. Seeing it reminded me of another item on my to-do list: I’ve long been curious about how computer cooling fans report their speed through that third wire. The electrical details haven’t been important to build PCs, all I needed to know was to plug it the right way into a motherboard header. But now I want to know more.

I have a fan I modified for a homemade evaporator cooler project, removing its original motherboard connector so I could power it with a 12V DC power plug. The disassembled connector makes it unlikely to be used in future PC builds and also makes its wires easily accessible for this investigation.

We see an “Antec” sticker on the front, but the actual manufacturer had its own sticker on the back. It is a DF1212025BC-3 motor from the DF1212BC “Top Motor” product line of Dynaeon Industrial Co. Ltd. Nominal operating power draw is 0.38A at 12V DC.

Even though 12V DC was specified, the motor spun up when I connected 5V to the red wire and grounded the black wire. (Drawing only 0.08 A according to my bench power supply.) Probing the blue tachometer wire with a voltmeter didn’t get anything useful. Oscilloscope had nothing interesting to say, either.

To see if it might be an open collector output, I added a 1kΩ pull-up resistor between the blue wire and +5V DC on the red wire.

Aha, there it is. A nice square wave with 50% duty cycle and a period of about 31 milliseconds. If this period corresponds to one revolution of the fan, that works out to 1000/31 ~= 32 revolutions per second or just under 2000 RPM. I had expected only a few hundred RPM, so this is roughly quadruple my expectations. If this signal was generated by a hall sensor, it would be consistent with multiple poles on the permanent magnet rotor.

Increasing the input voltage to 12V sped up the fan as expected, which decreased the period down to about 9ms. (The current consumption went up to 0.22 A, lower than the 0.38 A on the label.) The fan is definitely spinning at some speed far lower than 6667 RPM. I think dividing by four (1666 RPM) is in the right ballpark. I wish I had another way to measure RPM, but regardless of actual speed the key observation today is that the tachometer wire is an open-collector output that generates a 50% duty cycle square wave whose period is a function of the RPM. I don’t know what I will do with this knowledge yet, but at least I now know what happens on that third wire!

Notes on “Data Oriented Design” Textbook

I spent a lot of time playing Hardspace:Shipbreaker because I enjoyed the game, and I learned about it as an example of Unity’s Data Oriented Technology Stack (DOTS) in action. I was curious about the promised benefits of DOTS and wanted to know more about it. Unity’s learning portal has published several guides relating to the topic including DOTS Best Practices. Among the list of pointers to various background primers is the book Data-Oriented Design by Richard Fabian. (*) The physical book and/or its various digital editions give a full treatment of the topic, but for those who just want to skim through to see the basic concepts, the author has actually made the raw text available online.

And by “raw text” I mean that almost literally. This is a bare-bones site (“HTML 1.0”) with just contents in paragraphs. (Yes, HTML <P> tags.) Tables of information are in actual <TABLE> which sees little use on modern HTML sites. The CSS style sheet is used for its original purpose: declare styling on text with no layout or funny business with <div> mutations. The only images I see are actually code listings a.k.a. pictures of more text. I enjoyed reading such a feed of raw knowledge and here are a few notes.

If I were to summarize the book, I would go with “Why Game Developers Should Learn from Database Gurus.” To be clear, this is not a book about databases, but it discusses many concepts from the world of databases because they are obviously data oriented in nature. Plus, databases have a tremendous history developing methods to work in parallel, taking advantage of multicore processors where most modern applications struggle to do the same. This requires certain ways of thinking about problems, and we can learn from those lessons.

While it would be silly to say every game should be built on SQL queries, it makes sense to consider data-oriented approaches for certain domains. After all, databases underlie a lot of what we do with computers. So many computer applications are merely custom variations of database CRUD pattern that we now have products like Amazon Honeycode built around the concept of letting people create CRUD apps without code. For core game loop data, a general database would incur too much overhead. But we can tailor game code to adopt database concepts where it makes sense to improve game performance.

This book has a focus on game development, which I was surprised by given the lack of mention in the title or in some of the abstracts. It does talk about Unity at places, but only because Unity is a game engine. This book predates Unity’s currently ongoing DOTS overhaul, so DOTS is not mentioned. Code examples are in C/C++ and not the C# used by Unity, but as they are there mostly to illustrate concepts, the specific programming language is less important.

The text starts with a lot of thick theoretical foundations that I found difficult to chew through, with many words I found ambiguous. Things didn’t start to click for me until some concrete examples were shown. There were examples of how object-oriented programming becomes unwieldy in large projects, and I find myself nodding a lot from my own career experience. Data-oriented design approaches were then given as examples of how many of those problems can be solved, and they certainly sound good in theory! But I have yet to see them in practice for large projects and, more importantly, this book didn’t spend any time talking about how DOD might stumble into its own unwieldy problems. I don’t know how to avoid them if I don’t even know what they look like! Another way to present my wariness is this table:

Development ApproachGreatness in TheoryHurdles in Reality
Object-Oriented DesignDiscussedDiscussed
Data-Oriented DesignDiscussed…?

After reading this book, I’m convinced enough of merits to give data-oriented design a try, but I will have to keep my eyes open for where it stumbles. Because I’ve been writing code long enough to be sure of one thing: every nifty new solution to existing problems will bring its own new and unique problems. In time, with practice, I’m sure I’ll learn where DOD is the wrong tool for the job. The good news is that, thanks to the generalized nature of this book, I don’t necessarily have to try applying these concepts inside Unity. Which is good because Unity is still rolling through a multi-year transition to DOD.

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

LCD Driver Pinout for Honda CD

After a few wrong turns, I think I have a good grasp of the interface for talking with the audio (CD player) portion of a Honda Accord dashboard. This circuit board also includes HVAC (heating/ventilation/air conditioning) controls, though I investigated only their knobs and ignored the electronics. This page is a summary of my investigation into interfacing with audio controls.


There are at least three independent circuits present.

  1. Panel backlight using small incandescent (filament) bulbs with a blue cover. Draws 0.6A at14.4V DC.
  2. LCD backlight draws 0.2A at 14.4V DC.
  3. Digital communication with Sanyo LC75883 LCD driver chip, which is a 5V part. We can send data to control LCD segment display and use it to read data for most of the button presses.
1LAMP+BPower for panel light bulbs, up to +14.4V relative to LAMP-RET.
2LAMP+BPower for panel light bulbs, up to +14.4V relative to LAMP-RET.
3LAMP-RETReturn for panel light bulbs.
4LAMP-RETReturn for panel light bulbs.
5LCDLAMP+BPower for LCD backlight, up to +14.4V relative to LCDLAMP-RET.
6LCDLAMP-RETReturn for LCD backlight.
10IS BUS FRAMEUnknown.
11IS BUS DATAUnknown.
13IGN-DETUnknown. (Ignition Detect?)
14SWD-VDD+5V power supply for LC75883.
15D-GND(Digital?) ground.
16LCD-DIData in from LC75883 chip. (Wired to LC75883 DO pin.)
17LCD-DOData out to LC75883 chip. (Wired to LC75883 DI pin.)
18LCD-CLKLC75883 Clock.
19LCD-RSTLC75883 Resets when pulled to 0V. Pull to 5V for normal operation, do not leave floating.
20LCD-CELC75883 Chip Enable.
21ENC VOL-DNOne of two quadrature encoder phases for central audio control knob.
22ENC VOL-UPOne of two quadrature encoder phases for central audio control knob.
23EJECTNormally open, shorts to ground when “Eject” button is pressed.
24PW SWNormally open, shorts to ground when “Power” button is pressed.


All control for LCD segment and key scanning for most of the buttons are handled by a Sanyo LC75883 chip. It communicates with a Sany proprietary protocol called CCB (Computer Control Bus) that has some resemblance to I2C or SPI but is neither. It listens on address 0x42 for bits indicating which LCD segments should be active, and reports on address 0x43 indicating which buttons were pressed. I have an Arduino sketch (target device: AVR ATmega328P based Arduino Nano) that demonstrates how to interact with the LC75883. Pressing the “Mode” button will cycle between the basic “turn all segments on” program, a bit pattern “drawing” program, and an animated demo.

This Arduino sketch for this investigation is publicly available on GitHub.

Honda CD Control Detours

After I finally found my mistake reading a Honda CD control panel’s input (I had left the reset pin floating) I think I have a pretty good handle on communicating with it. The CD audio side, at least, as I had no interest in figuring out the HVAC side. But before I wrap up with a summary and demo, this page describes two additional experiments for future reference.

External Quadrature Encoder

Before I realized my problem was a floating reset pin, I wired in an external quadrature encoder to determine if the problem might be with the Honda circuit board or if it was my code. There was an added bonus that this particular quadrature encoder was designed so that every detent would be high/high. I knew the problem of LCD blanking out was related to grounding various controls (buttons or this knob) to ground, so with its four transitions per detent, this knob would quickly blitz through the problematic states as a workaround.

Successful use of the external knob also meant I now know the LCD wasn’t blanking out due to something in my code, or even something in the Arduino as related to a quadrature encoder. The LCD would blank out if the onboard knob was in the wrong position, even if none of its wired connected to my Arduino. This observation was consistent with the actual cause of a floating reset pin. I removed this external knob once the reset pin was no longer left floating, making room for the next experiment.

Boost Converter for LCD Backlight

When I had illuminated the LCD backlight using my bench power supply, it indicated the backlight drew 0.2A at 14.4V ~= 3W. I thought that would be within reasonable range for a USB power bank, so I dug up a DC voltage boost converter (*) from a batch I had bought for an earlier project. I connected the voltage input to Arduino VIN pin and adjusted the converter to 14.4V open-circuit output voltage. But when I connected that output to the LCD backlight, voltage sagged and the USB power bank went into a continuous reset loop consistent with overload response.

I wasn’t sure if the overload was a startup issue, a transient issue, or a continuous power issue. As an experiment I soldered 220μF capacitors to both input and output. This did not change the behavior: the USB power bank still enters a continuous reset loop. I added a USB power meter (*) between my power bank and the Arduino and it said the circuit tried to draw 3 amps. Yikes! That explains the reset when I had expected only 0.6 amps (3 watts / 5 volts) to be drawn.

I’ll revisit the LCD backlight power supply issue later, if I decide to reuse this LCD for something fun. At least this failed experiment let me know boost converter power draw is more complex than (Power) = (Voltage)*(Current). It is also another checkmark next to “I should learn how boost converters work” on my to-do list, I hope with such knowledge I could properly diagnose this failure to verify I understand the situation correctly.

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

Honda CD LCD Driver Mystery Problems Solved

I’ve been talking to the Sanyo LC75883 LCD driver chip on a Honda CD control panel by soldering wires directly to the board and running those signals to a breadboard. Once I found the correct connector to plug into that board, I transferred my (jumper wires and breadboard) experimental circuit to something a little more compact. But like all projects, it didn’t work at first and needed some diagnosis.

My first problem was a classic electronics problem: “Data In” and “Data Out” lines were reversed. This is a close cousin of the RX/TX problem, where we always have to figure out whose perspective a particular label is using. The RX (receive) line for one component needs to be wired to the TX (transmit) line of the other component, and vice versa. For my circuit, it meant “DO” on the connector pin 17 should go to the LC75883’s “DI” pin. I had connected “DO” to “DO” and “DI” to “DI” which does nothing until I swapped them.

After figuring out my DI/DO lines I was at parity with my breadboard circuit. Which is sufficient for controlling LCD output, but I just like before I still couldn’t read input. I examined the remaining pins looking for things I could try. First experiment was with pin 15, which was labeled D-GND which might mean “Digital ground”. I had been using the trio of pins labeled P-GND for my ground instead. I don’t have a good guess what “P” stood for, but if I had been using the wrong ground that might explain the odd behavior I observed. Sadly, tying D-GND to P-GND made no noticeable difference.

Looking down the list again, I decided to take another look at pin 19 labeled LCD-RST. There was a similar RESET pin on the Toyota tape deck faceplate. I had left that unconnected because the LC75853 driver chip on that board did not expose a reset pin so there was nothing to connect. Due to the similarities between these two chips, I thought I would do the same thing here. But I realized that was a mistake when I reviewed the LC75883 datasheet.

Unlike its sibling, this chip does expose a reset pin (76). Which meant I had been leaving reset unconnected and floating all this time. Not good! I soldered a 1kΩ resistor between pin 14 SWD-VDD and pin 19 LCD-RST in order to tie LCD-RST high, and after that, all input worked as expected. Turning the quadrature encoder knob no longer blanks out the screen at every other detent, and I could successfully read key scan report data to know which buttons had been pressed. And LCD output still worked just as before. This is great! I’m glad I figured out my mistake and frankly, I’m surprised this thing worked at all with a floating reset pin. That’s my silliest mistake so far with this project, the others weren’t as bad.

Reuse Honda CD Connector for Arduino

Once I got over the excitement of lighting up the bulbs and LEDs on a Honda CD control panel, I returned to the original CD player mainboard. The labels on its panel connector gave me the confidence to apply power and expect illumination instead of the smoke of fried electronics. But now I have the labels documented for future reference, I will remove the connector for my own use.

Desoldering was mostly smooth except for the trio of ground pins. They were connected to thick ground traces that dissipated a lot of heat, making it difficult to melt the solder. For the final ground pin, I saw the solder had melted and pulled hard on the connector. Unfortunately, it had not yet melted all the way through so my yank damaged the pin. Well, at least I still have two intact ground pins to work with.

I still don’t know the manufacturer or name for this connector, but it is very similar to the connector I saw on a Toyota tape deck doing the same job. Which meant it shared the pin pitch of 0.1″ (just like a perforated prototype board!) and two rows 0.1″ apart (just like a perforated prototype board!) staggered with a 0.05″ offset. (Just like… oh no! It isn’t.) For the Toyota tape deck project, I gave up on a circuit board and directly soldered wires to connect pins. But I had been thinking about the problem since then and I have an idea I want to try.

I took one of my perforated prototype boards, cut a groove down a row of holes, and snapped it off. This exposed a row of semicircular vias that I could solder to one of the two rows on this connector. For the other row, I would still have to solder to wires directly.

It’s not nearly as solid of a connection as a custom circuit board with the proper pin layout, but it is still far better than nothing. My modified prototype board left just enough space to accommodate an Arduino Nano.

Flipping this assembly over allowed me to solder wires between the Arduino and the salvaged connector.

It is a far more compact and less accident-prone solution than my previous breadboard mess.

Sadly, it did not work straight off the bat. I had to do some debugging to bring it to parity with my breadboard solution, but the debugging session also solved a standing mystery.

Arduino code and other information for this investigation is available on GitHub.

Honda CD Panel Lights and LCD Backlight

When I started this Honda CD control panel investigation, I thought I might still have the CD player mainboard that sat behind the control panel. But when I pawed through my pile of anonymous circuit boards, I didn’t see anything I recognized as related to the CD control panel. After spending time looking at the control panel in detail, I became more familiar with the connector between the control panel and the mainboard. Revisiting the pile with this knowledge, I now recognized the matching connector. But even more importantly, the old mainboard had labels on its connector pins.

Note that both connectors stagger their pins, but confusingly in opposite directions. Pin 1 is lower-right on the mainboard labels, but upper-right on the control board numbering. I hadn’t spent much effort trying to find the pins for control panel illumination, but now that I see these LAMP pins clearly labeled, I wanted to light them up.

The first experiment was to apply +14.4V DC to LAMP+B and ground to LAMP-RET.

When power was applied, all the little incandescent bulbs with blue covers lit up. The color is not as blue as the covers would imply. It actually has a tint of green because those bulb’s natural glow is not white but a warm yellow. If they are supposed to masquerade as blue LEDs, they’re not doing a very convincing job. This collection of 11 bulbs drew 0.6A at 14.4V.

The next test is to put +14.4V DC power to LCDLAMP+B and ground to LCDLAMP-RET.

This illuminated the LCD backlight, drawing 0.2A at 14.4V. It is not very bright, but at least the light is fairly uniform. (Unlike its Toyota tape deck counterpart.) The primary purpose of these backlights is to ensure the display is visible at night. During daylight, these LCDs are legible under ambient sunlight. Lighting these up was fun! This experiment was good reference as I repurpose the connector for my own use.

Honda CD Connector Lost, Connector Found

Examining the fan speed and temperature adjustment knobs from a Honda Accord HVAC (heating, ventilation, air conditioning) control board taught me the existence of rotary encoders that could convey a position from a set of positions within a range of rotation. This was an alternative to potentiometers I had not been aware of, a lesson on top of everything else I learned playing with this module. But all this exploration also meant handling the assembly a lot, eventually breaking something.

This board attached to the main control board via a flexible cable that could only flex so many times before it broke from fatigue. Fortunately, these buttons and lights were associated with HVAC controls, and I hadn’t planned to go figure out that half of the board anyway. And even if these buttons were associated with the CD player, I had no luck so far reading button presses either. Either way, no big loss, and I dropped it in my pile of electronic circuit boards.

When I did so, a shape in the pile caught my eye. A week ago, it was just another electrical connector on a unmarked circuit board I forgot details about. But I now recognize it as the edge connector matching one on the CD/HVAC control board I’ve been exploring. Which meant this circuit board used to be the CD player mainboard that sat behind the dashboard.

Almost as valuable as the connector itself are silkscreened information on the circuit board, labeling the pins. I had puzzled out a preliminary subset just from poking around with a multimeter, but now I have the answer key. I was happy to find confirmation for my guesses and filling in unknowns. Earlier I was puzzled by the hint that multiple pins might be ground, and now I can see there are indeed three pins (7, 8, and 9) all connected to ground. I had traced out a dedicated pin for the power button (24), but I had missed the adjacent one was for eject (23). Things along those lines.

I hadn’t put any effort into figuring out the illumination pins, because I didn’t want to risk making a mistake that would send +14.4V into the wrong place and burning things up. But now that I see lamp pins clearly labeled, I want to light them up.

Honda Accord HVAC Knobs — Electrical

The audio and HVAC (Heating/Ventilation/Air Conditioning) on a 2007 Honda Accord are controlled by a trio of knobs. They each have different range of motion: fan speed sweeps through 120 degrees, temperature sweeps through 270 degrees, and the audio knob is free to spin continuously through 360 degrees without endpoints. However, they all have the same tactile feel through “clicky” detent steps: 13 for the fan speed, 15 for temperature, and 30 per complete revolution of audio. Despite their differences, they appear to use identical Alps ring encoders. How was this done?

My first hint was noticing that each encoder can have six electrical contacts, but the audio knob only used three of them. The other three pins were cut off, never connected to the circuit board. Limited to three pins, the audio knob could express 4 states with the remaining two pins as a quadrature encoder does. Thus these knobs could be configured to act this way, but only as a special case with pins cut off.

To probe the other knobs, I started by arbitrarily number pins. Looking at the encoder’s top side oriented with pins towards me, the left side top to bottom are: 1, 2, and 3. Then the right side top to bottom are 4, 5, and 6. Viewed from the encoder’s bottom side, the pins numbers are like this:

I probed the fan speed knob for electrical continuity. In use we would ground one pin and all the marked pins will also be grounded when the knob is at a particular position.

Fan Speed123456

Looking at this chart, it appears either pin 1 or 6 could be the ground reference. Pins 2 through 5 vary depending on knob position. Using 4 pins they could represent up to 16 positions, though only 13 are used. The digital encoding isn’t a straightforward mapping to binary numbers, even if I move the columns around. I don’t recognize it, but I do see a pattern. One attribute of this pattern is that, when moving from one position to the next, only one pin changes state. This may be useful in some way I don’t understand. I don’t see a way to calculate position number directly from the pattern, so if I were to reuse this knob, I would have to use a lookup table. 13 valid positions out of 16 possible positions shouldn’t be a big deal.

I then probed the temperature knob to see how it compares.

-7 (Coldest)XXX
7 (Warmest)XXX

From here we can tell pin 1 is clearly designed to be the ground reference pin, and we can determine absolute position by reading state of the other five pins. This pattern looks more like a binary number, with pin 4 being the least significant bit and pin 2 as the next least significant bit. But then things fall apart and pin 3 doesn’t fit the pattern for binary number progression. It doesn’t fully follow the “number of transition bits” pattern observed in the fan speed control. Moving from either of the end positions would change one bit. Moving between non-end positions would change two bits. If I were to reuse this knob, I would again use a lookup table, with 15 valid positions out of 32 possible combinations.

These knobs will be interesting to reuse in another project. They take four or five digital input pins instead of the single analog input pin of a potentiometer, but I like their tactile detents which could be useful in specific scenarios. I’ll set them aside and return my focus to digital communication.

Honda Accord HVAC Knobs — Mechanical

I have a retired chunk of Honda Accord interior, a control panel that integrated CD player and HVAC buttons and knobs into a single panel. Once dug into it, though, I discovered that the CD player electronics were actually quite independent of HVAC electronics even though they lived on the same circuit board. I was motivated to figure out the CD player portion because I wanted to play with segmented LCD, but there were no such attractions on the HVAC side. I will remove those HVAC knobs and play with them separately. I wanted to know more about how they worked: mechanically these knobs looked nearly identical to the infinite-rotation quadrature encoder used for audio control. But they have limited travel and their nature requires knowledge of their absolute position, which seems more appropriate for a potentiometer.

First to be removed was the fan speed selector, where I got my first hint at how these are different from visually similar audio knob: they have six electrical contacts instead of three. As soon as I noticed this I went back to the audio knob and saw it had provision for six contacts as well but three on one side were cut. Back to the fan speed knob: I had to desolder those six electrical contacts plus 4 more soldered mechanical mount points.

Once I pulled the knob off, I see a backlight bulb on a pedestal. This bulb would have illuminated the fan speed icons as well as a small piece of translucent plastic visually indicating current fan speed setting.

Looking over the knob, I found no further fasteners. As an experiment I tried pulling, and just a light pull was enough to overcome plastic snaps in this assembly. The rightmost portion in this picture is what actually rotates, attached to a ring on the encoder. The center portion with fan speed icon remains static, mounted to the encoder itself on the left.

After the fan speed knob was removed, I proceeded to do the same for the temperature control knob. Aside from their differences in printed graphics, these two knobs have slightly different range of motion and number of detents. The fan speed knob sweeps approximately 120 degrees, and has 13 total detents: “off” and 12 speeds. The temperature knob sweeps through 270 degrees, and has 15 total detents: 7 levels of cold, 7 levels of warm, plus a neutral position.

In one corner of the encoder body, I saw this logo but no further identifiers. A few searches found the Wikipedia page for Alps Electric, and their current incarnation’s corporate web site Alps Alpine. Digging into their products catalog, the device I have in my hand resembles items in their Ring Encoder product category, but I did not find an exact match. This is either a discontinued product or a Honda exclusive item. I can’t tell in the absence of further identifiers on the device. Perhaps there’s a number inside if I wanted to take it apart further, but I’m more interested in pulling out my multimeter to probe their electrical behavior.