Windows PC Keyboard Beeps Instead of Types? Turn Off “Filter Keys”

A common side effect of technical aptitude is the inevitable request “Can you help me with my computer?” Whether this side effect is an upside or downside depends on the people involved. Recently I was asked to help resurrect a computer that had been shelved due to “the keyboard stopped working.”

Before I received the hardware, I was told the computer was an Asus T300L allowing me to do a bit of research beforehand. This is a Windows 8 era touchscreen tablet/laptop convertible along the lines of a Microsoft Surface Pro or the HP Split X2. This added a twist: the T300L keyboard base not only worked while docked, but it could also continue working as a wireless keyboard + touchpad when separated from the screen. This could add a few hardware-related variables for me to investigate.

When I was finally presented with the machine, I watched the owner type their Windows login password using the keyboard. “Wait, I thought you said the keyboard didn’t work?” “Oh, it works fine for the password. It stops working after I log in.”

Ah, the hazard of imprecision of the English language. When I was first told “keyboard doesn’t work” my mind went to loose electrical connections. And when I learned of the wireless keyboard + touchpad base, I added the possibility of wireless settings (device pairing, etc.) I had a hardware-oriented checklist ready and now I can throw it all away. If the keyboard worked for typing in Windows password, the problem is not hardware.

Once the Windows 8 desktop was presented, I could see what “keyboard stopped working” meant: every keypress resulted in an audible beep but no character typed on screen. A web search with these symptoms found this Microsoft forum thread titled “Keyboard Beeps and won’t type” with the (apparently common) answer to check Windows’ Ease of Access center. I made my way to that menu (as the touchscreen worked fine) and found that Filter Keys were turned on.

Filter Keys is a feature that helps users living with motor control challenges that result in shaky hands. This could result in pressing a key multiple times when they only meant to press a key once or jostling adjacent keys during that keypress. Filter Keys slow the computer’s keyboard response, so they only register long and deliberate presses as a single action. Rapid tap and release of a key — which is what usually happens in mainstream typing action — are ignored and only a beep is played. Which is great, if the user knew how to use Filter Keys and intentionally turned it on.

In this case, nobody knows how this feature got turned on for this computer, but apparently it was not intentional. They didn’t recognize the symptoms of Filter Keys being active. Lacking that knowledge, they could only communicate their observation as “the keyboard stopped working.” I guess that description isn’t completely wrong, even if it led me down the wrong path in my initial research. Ah well. Once Filter Keys were turned off, everything is fine again.

MageGee Wireless Keyboard (TS92)

In the interest of improving ergonomics, I’ve been experimenting with different keyboard placements. I have some ideas about attaching keyboard to my chair instead of my desk, and a wireless keyboard would eliminate concerns about routing wires. Especially wires that could get pinched or rolled over when I move my chair. Since this is just a starting point for experimentation, I wanted something I could feel free to modify as ideas may strike. I looked for the cheapest and smallest wireless keyboard and found the MageGee TS92 Wireless Keyboard (Pink). (*)

This is a “60% keyboard” which is a phrase I’ve seen used two different ways. The first refers to physical size of individual keys, if they were smaller than those on a standard keyboard. The second way refers to the overall keyboard with fewer keys than the standard keyboard, but individual keys are still the same size as those on a standard keyboard. This is the latter: elimination of numeric keypad, arrow keys, etc. means this keyboard only has 61 keys, roughly 60% of standard keyboards which typically have 101 keys. But each key is still the normal size.

The lettering on these keys are… sufficient. Edges are blurry and not very crisp, and consistency varies. But the labels are readable so it’s fine. The length of travel on these keys are pretty good, much longer than a typical laptop keyboard, but the tactile feedback is poor. Consistent with cheap membrane keyboards, which of course this is.

Back side of the keyboard shows a nice touch: a slot to store the wireless USB dongle so it doesn’t get lost. There is also an on/off switch and, next to it, a USB Type-C port (not visible in picture, facing away from camera) for charging the onboard battery.

Looks pretty simple and straightforward, let’s open it up to see what’s inside.

I peeled off everything held with adhesives expecting some fasteners to be hidden underneath. I was surprised to find nothing. Is this thing glued together? Or held with clips?

I found my answer when I discovered that this thing had RGB LEDs. I did not intend to buy a light-up keyboard, but I have one now. The illumination showed screws hiding under keys.

There are six Philips-head self-tapping plastic screws hidden under keys distributed around the keyboard.

Once they were removed, keys assembly easily lifted away to expose the membrane underneath.

Underneath the membrane is the light-up subassembly. Looks like a row of LEDs across the top that shines onto a clear plastic sheet acting to diffuse and direct their light.

I count five LEDs, and the bumps molded into clear plastic sheet worked well to direct light where the keys are.

I had expected to see a single data wire consistent with NeoPixel a.k.a. WS2812 style of individually addressable RGB LEDs. But label of SCL and SDA implies this LED strip is controlled via I2C. If it were a larger array I would be interested in digging deeper with a logic analyzer, but a strip of just five LEDs isn’t interesting enough to me so I moved on.

Underneath the LED we see the battery, connected to a power control board (which has both the on/off switch and the Type-C charging port) feeding power to the mainboard.

Single cell lithium-polymer battery with claimed 2000mAh capacity.

The power control board is fascinating, because somebody managed to lay everything out on a single layer. Of course, they’re helped by the fact that this particular Type-C connector doesn’t break out all of the pins. Probably just a simple voltage divider requesting 5V, or maybe not even that! I hope that little chip at U1 labeled B5TE (or 85TE) is a real lithium-ion battery manage system (BMS) because I don’t see any other candidates and I don’t want a fiery battery.

The main board has fewer components but more traces, most of which led to the keyboard membrane. There appears to be two chips under blobs of epoxy, and a PCB antenna similar to others I’ve seen designed to work on 2.4GHz.

With easy disassembly and modular construction, I think it’ll be easy to modify this keyboard if ideas should strike. Or if I decide I don’t need a keyboard after all, that power subsystem would be easy (and useful!) for other projects.


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

Old OCZ SSD Reawakened and Benchmarked

In the interest of adding 3.5″ HDD bays to a tower case, along with cleaning up wiring to power them, I installed a Rosewill quad hard drive cage where a trio of 5.25″ drive bays currently sit open and unused. It mostly fit. To verify that all drive cage cable connections worked with my SATA expansion PCIe card (*) I grabbed four drives from my shelf of standby hardware. When installing them in the drive cage, I realized I made a mistake: one of the drives was an old OCZ Core Series V2 120GB SSD that had stopped responding to its SATA input. I continued installation anyway because I thought it would be interesting to see how the SATA expansion card handled a nonresponsive drive.

Obviously, because today intent was to see an unresponsive drive, Murphy’s Law stepped in and foiled the plan: when I turned on the computer, that old SSD responded just fine. Figures! I don’t know if there was something helpful in the drive cage, or the SATA card, or if something was wrong with the computer that refused to work with this SSD years ago. Whatever the reason, it’s alive now. What can I do with it? Well, I can fire up the Ubuntu disk utility and get some non-exhaustive benchmark numbers.

Average read rate 143.2 MB/s, write 80.3 MB/s, and seek of 0.22 ms. This is far faster than what I observed by using the USB2 interface, so I was wrong earlier about the performance bottleneck. Actual performance is probably lower than this, though. Looking at the red line representing write performance, we can see it started out strong but degraded at around 60% of the way through the test and kept getting worse, probably the onboard cache filling up. If this test ran longer, we might get more and more of the bottom end write performance of 17 MB/s.

How do these numbers compare to some contemporaries? Digging through my pile of hardware, I found a Samsung ST750LM022. This is a spinning-platter laptop hard drive with 750GB capacity.

Average read 85.7 MB/s, write 71.2 MB/s, and seek of 16.77 ms. Looking at that graph, we can clearly see degradation in read and write performance as the test ran. We’d need to run this test for longer before seeing a bottom taper, which may or may not be worse than the OCZ SSD. But even with this short test, we can see the read performance of a SSD does not degrade over time, and that SSD has a much more consistent and far faster seek time.

That was interesting, how about another SSD? I have an 120GB SSD from the famed Intel X25-M series of roughly similar vintage.

Average read 261.2 MB/s, write 106.5 MB/s, seek 0.15 ms. Like the OCZ SSD, performance took a dip right around the 60% mark. But after it did whatever housekeeping it needed to do, performance level resumed at roughly same level as earlier. Unlike the OCZ, we don’t see as much of a degradation after 60%.

I didn’t expect this simple benchmark test to uncover the full picture, as confirmed after seeing this graph. By these numbers, the Intel was around 30% better than the OCZ. But my memory says otherwise. In actual use as a laptop system drive, the Intel was a pleasure and the OCZ was a torture. I’m sure these graphs are missing some important aspects of their relative performance.

Since I had everything set up anyway, I plugged in a SanDisk SSD that had the advantage of a few years of evolution. In practical use, I didn’t notice much of a difference between this newer SanDisk and the old Intel. How do things look on this benchmark tool?

Average read 478.6 MB/s, write 203.4 MB/s, seek 0.05 ms. By these benchmarks, the younger SanDisk absolutely kicked butt of an older Intel with at least double the performance. But that was not borne out by user experience as a laptop drive, it didn’t feel much faster.

Given that the SanDisk benchmarked so much faster than the Intel (but didn’t feel that way in use) and OCZ benchmarked only slightly worse than the Intel (but absolutely felt far worse in use) I think the only conclusion I can draw here is: Ubuntu Disk Utility built-in benchmarking tool does not reflect actual usage. If I really wanted to measure performance details of these drives, I need to find a better disk drive benchmarking tool. Fortunately, today’s objective was not to measure drive performance, it was only to verify all four bays of my Rosewill drive cage were functional. It was a success on that front, and I’ll call it good for today.


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

Rosewill Hard Disk Drive Cage (RSV-SATA-Cage-34)

Immediately after my TrueNAS CORE server power supply caught fire, I replaced it with a spare power supply I had on hand. This replacement had one annoyance: it had fewer SATA power connectors. As a short-term fix, I dug up some adapters from the older CD-ROM style power connectors to feed my SATA drives, but I wanted a more elegant solution.

The ATX tower case I used for my homebuilt server had another issue: it had only five 3.5″ hard drive bays for my six-drive array. At the moment it isn’t a problem, because the case had two additional 2.5″ laptop sized hard drive mount points and one drive in my six-drive array was a smaller drive salvaged from an external USB drive which fits in one bay. The other 2.5″ bay held the SSD boot drive for my TrueNAS CORE server. I did not want to be constrained to using a laptop drive forever, so I wanted a more elegant solution to this problem as well.

I found my elegant solution for both problems in a Rosewill RSV-SATA-Cage-34 hard drive cage. It fits four 3.5″ drives into the volume of a trio of 5.25″ drive bays, which is present on my ATX tower case and currently unused. This would solve my 3.5″ bay problem quite nicely. It will also solve my power connector problem, as the cage used a pair of CD-ROM style connectors for power. A circuit board inside this cage redistributes that power to four SATA power connectors.

First order of business was to knock out the blank faceplates covering the trio of 5.25″ bays.

Quick test fit exposed a problem: the drive cage is much longer than a CD-ROM drive. For the case to sit at the recommended mounting location for 5.25″ peripherals, drive cage cooling fan would bump up against the ATX motherboard power connector. This leaves very little room for the four SATA data cables and two CD-ROM power connectors to connect. One option is to disconnect and remove the cooling fan to give me more space, but I wanted to maintain cooling airflow, so I proceeded with the fan in place.

Given the cramped quarters, there would be no room to connect wiring once the cage was in place. I pulled the cage out and connected wires while it was outside the case, then slid it back in.

It is a really tight fit in there! Despite my best effort routing cables, I could not slide the drive cage all the way back to its intended position. This was as hard as I was willing to shove, leaving the drive cage several millimeters forward of its intended position.

As a result, the drive cage juts out beyond case facade by a few millimeters. Eh, good enough.

Radeon HD 7950 Video Card (MSI R7950-3GD5/OC BE)

This video card built around a Radeon HD 7950 chip is roughly ten years old. It is so outdated, nobody would pay much for a used unit on eBay. Not even at the height of The Great GPU Shortage. I’ve been keeping it around as a representative for full sized, dual-slot PCIe video cards as I played with custom-built PC enclosures. But I now have other video cards that I can use for the purpose, so this nearly-teenager video card landed on the teardown bench.

Most of its exterior surface is covered by a plastic shroud, but the single fan intake is no longer representative of modern GPUs with two or three fans.

Towards the center of this board is a metal bracket for fastening a heat sink that accounted for most of the weight of this card. In the upper left corner are auxiliary PCIe power supply sockets. The circuit board has provision for a 6-pin connector adjacent to an 8-pin connector, even though only two 6-pin connectors are soldered to this board. Between those connectors and the GPU itself, I see six (possibly seven) sets of components. I infer these are power-handling parts working in parallel to feed a power-hungry chip.

This was my first 4K UHD capable video card, which I used via the mini-DisplayPort connectors on the right. As I recall, the HDMI port only supported up to 1080p Full HD and could not drive a 4K display. Finally, a DVI port supported all DVI capabilities (not all of them do): analog VGA on its DVI-A pins, plus dual-link DVI-D for driving larger displays. I don’t recall if the DVI-D plug could output 4K UHD, but I knew it went beyond 1080p Full HD by driving a 2560×1600 monitor.

The plastic shroud was held by six plastic screws to PCB and two machine screws to metal plate. Once those eight fasteners were removed, shroud came off easily. From here we get a better look at the PCIe auxiliary power connectors on the top right, and the seven sets of capacitors/inductors/etc. that work in parallel to handle power requirements of this chip.

Four small machine screws held the fan shroud to the heat sink. Fan label indicates this fan consumes up to 6 Watts (12V 0.5A) and I recall it can get move a lot of air at full blast. (Or at least, gets very loud trying.) It appears to be a four-wire fan which I only recently understood how to control if I wanted. Visible on the fan’s underside is a layer of fine dust that held on, despite a blast of compressed air I used to clean out dust bunnies before this teardown.

Some more dust had also clung on to these heat sink fins. It seems like a straightforward heat sink with stamped sheet metal fins on an aluminum base, no heat pipes like what we see on many modern GPUs. But if it is all aluminum, and there are no heat pipes, it should be lighter weight than it is.

Unfastening four machine screws from the X-shaped rear bracket allowed me to remove the heat sink, and now we can see the heat sink has a copper core for heat distribution. That explains the weight.

The GPU package is a high-density circuit board in its own right, hosting not just the GPU die itself but also a large collection of supporting components. Based on the repeated theme of power handling, I guess these little tan rectangles are surface mount capacitor arrays, but they might be something else.

Here’s a different angle taken after I cleaned up majority of thermal paste. An HD 7950 is a big silicon die sitting on a big package.

When I cleaned all thermal paste off the heatsink, I was surprised at its contact surface. It seems to be the direct casting mold surface texture with no post-processing. For CPU heatsinks, I usually see a precision machined flat surface, either milling or grinding. Low-power/low-cost devices may skip such treatment for their heatsinks, but I don’t consider this GPU as either low power or low cost. I know this GPU dissipated heat on par with a CPU, yet there was no effort for a precision flat surface to maximize heat transfer.

I think this is a promising module for reuse. Though in addition to the lack of precision flat surface, there’s another problem that the copper core is slightly recessed. The easiest scenario for reuse is to find something that sticks up ~2mm above its surrounding components, but not by more than the 45x45mm footprint of this GPU. This physical shape complicates my top two ideas for reuse: (1) absolute overkill cooling for a Raspberry Pi, or (2) retrofit active cooling to the passively-cooled HP Split X2. If I were to undertake either project, I’d have to add shims or figure out how to remove some of the surrounding aluminum.

Disable Sleep on a Laptop Acting as Server

I’ve played with different ways to install and run Home Assistant. At the moment my home instance is running as a virtual machine inside KVM hypervisor. The physical machine is a refurbished Dell Latitude E6230 running Ubuntu Desktop 22.04. Even though it will be running as a server, I installed the desktop edition for access to tools like Virtual Machine Manager. But there’s a downside to installing the desktop edition for server use: I did not want battery-saving features like suspend and sleep.

When I chose to use an old laptop like a server, I had thought its built-in battery would be useful in case of power failure. But I hadn’t tested that hypothesis until now. Roughly twenty minutes after I unplugged the laptop, it went to sleep. D’oh! The machine still reported 95% of battery capacity, but I couldn’t use that capacity as backup power.

The Ubuntu “Settings” user interface was disappointingly useless for this purpose, with no obvious ability to disable sleep when on battery power. Generally speaking, the revamped “Settings” of Ubuntu 22 has been cleaned up and now has fewer settings cluttering up all those menus. I could see this as a well-meaning effort to make Ubuntu less intimidating to beginners, but right now it’s annoying because I can’t do what I want. To the web search engines!

Looking for command-line tools to change Ubuntu power saving settings brought me to many pages with outdated information that no longer applied to Ubuntu 22. My path to success started with this forum thread on Linux.org. It pointed to this page on linux-tips.us. It has a lot of ads, but it also had applicable information: systemd targets. The page listed four potentially applicable targets:

  • suspend.target
  • sleep.target
  • hibernate.target
  • hybrid-sleep.target

Using “systemctl status” I could check which of those were triggered when my laptop went to sleep.

$ systemctl status suspend.target
○ suspend.target - Suspend
     Loaded: loaded (/lib/systemd/system/suspend.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

Jul 21 22:58:32 dellhost systemd[1]: Reached target Suspend.
Jul 21 22:58:32 dellhost systemd[1]: Stopped target Suspend.
$ systemctl status sleep.target
○ sleep.target
     Loaded: masked (Reason: Unit sleep.target is masked.)
     Active: inactive (dead) since Thu 2022-07-21 22:58:32 PDT; 11h ago

Jul 21 22:54:41 dellhost systemd[1]: Reached target Sleep.
Jul 21 22:58:32 dellhost systemd[1]: Stopped target Sleep.
$ systemctl status hibernate.target
○ hibernate.target - System Hibernation
     Loaded: loaded (/lib/systemd/system/hibernate.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)
$ systemctl status hybrid-sleep.target
○ hybrid-sleep.target - Hybrid Suspend+Hibernate
     Loaded: loaded (/lib/systemd/system/hybrid-sleep.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

Looks like my laptop reached the “Sleep” then “Suspend” targets, so I’ll disable those two.

$ sudo systemctl mask sleep.target
Created symlink /etc/systemd/system/sleep.target → /dev/null.
$ sudo systemctl mask suspend.target
Created symlink /etc/systemd/system/suspend.target → /dev/null.

After they were masked, the laptop was willing to use most of its battery capacity instead of just a tiny sliver. This should be good for several hours, but what happens after that? When the battery is almost empty, I want the computer to go into hibernation instead of dying unpredictably and possibly in a bad state. This is why I left hibernation.target alone, but I wanted to do more for battery health. I didn’t want to drain the battery all the way to near-empty, and this thread on AskUbuntu led me to /etc/UPower/UPower.conf which dictates what battery levels will trigger hibernation. I raised the levels so the battery shouldn’t be drained much past 15%.

# Defaults:
# PercentageLow=20
# PercentageCritical=5
# PercentageAction=2
PercentageLow=25
PercentageCritical=20
PercentageAction=15

The UPower service needs to be restarted to pick up those changes.

$ sudo systemctl restart upower.service

Alas, that did not have the effect I hoped it would. Leaving the cord unplugged, the battery dropped straight past 15% and did not go into hibernation. The percentage dropped faster and faster as it went lower, too. Indication that the battery is not in great shape, or at least mismatched with what its management system thought it should be doing.

$ upower -i /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          BAT0
  vendor:               DP-SDI56
  model:                DELL YJNKK18
  serial:               1
  power supply:         yes
  updated:              Fri 22 Jul 2022 03:31:00 PM PDT (9 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       action
    energy:              3.2079 Wh
    energy-empty:        0 Wh
    energy-full:         59.607 Wh
    energy-full-design:  57.72 Wh
    energy-rate:         10.1565 W
    voltage:             9.826 V
    charge-cycles:       N/A
    time to empty:       19.0 minutes
    percentage:          5%
    capacity:            100%
    technology:          lithium-ion
    icon-name:          'battery-caution-symbolic'

I kept it unplugged until it dropped to 2%, at which point the default PercentageAction behavior of PowerOff should have occurred. It did not, so I gave up on this round of testing and plugged the laptop back into its power cord. I’ll have to come back later to figure out why this didn’t work but, hey, at least this old thing was able to run 5 hours and 15 minutes on battery.

And finally: this laptop will be left plugged in most of the time, so it would be nice to limit charging to no more than 80% of capacity to reduce battery wear. I’m OK with 20% reduction in battery runtime. I’m mostly concerned about brief blinks of power of a few minutes. A power failure of 4 hours instead of 5 makes little difference. I have seen “battery charge limit” as an option in the BIOS settings of my newer Dell laptops, but not this old laptop. And unfortunately, it does not appear possible to accomplish this strictly in Ubuntu software without hardware support. That thread did describe an intriguing option, however: dig into the cable to pull out Dell power supply communication wire and hook it up to a switch. When that wire is connected, everything should work as it does today. But when disconnected, some Dell laptops will run on AC power but not charge its battery. I could rig up some sort of external hardware to keep battery level around 75-80%. That would also be a project for another day.

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:

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

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

fan:
  - 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 http://FormFactors.org 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
Specification
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.

OCZ Core Series V2 120GB SSD (OCZSSD2-2C120G)

My first SSD was a Patriot WARP V.2 32GB SSD. It not quite the bleeding edge, that “V.2” signified a revision that solved some issues in the first wave. Early experience with my first SSD was amazing enough for me to look for a larger 120GB unit to gain a little more elbow room in day-to-day use. They both represented early technology with flaws that needed solving before SSD became long-term reliable. I didn’t know that when I bought them, but it was certainly made clear as their performance degraded over a few years and then dying entirely when they no longer showed up as SATA drives when plugged them in. I took apart the first Patriot drive, now it’s time for the second OCZ drive.

Since they were both built around the JMF602 controller and arrived on market around the same time, I expected them to both utilize a JMF602 reference design. Before I opened up this SSD, I expected the circuit board to look identical to the smaller Patriot, just with higher capacity flash memory chips.

I found I was wrong when I opened up the case, this drive used a very different circuit board layout. This design placed the JMF602 at the center, and I don’t see an obvious debug header. There is still a connector adjacent to the SATA data port and it is populated on this drive: a USB mini-B socket that lets this SSD act as a USB flash drive.

Four more flash chips live on the other side of this board, again in a different layout compared to the Patriot drive. They seem to have the same production information sticker, but that might be some sort of industry standard sticker.

Thanks to the USB port, I could still access this drive even though the SATA port no longer enumerates. It is only an USB 2.0 connection, but I don’t think that is a constraint. Write performance has degraded to an atrocious level on this drive. Here I’m copying a single large ISO file to the drive. 25MB/sec throughput and a response time of nearly 500ms are well below limits of USB2.

Read throughput is only slightly better at nearly 40MB/sec and a 20ms read response time is significantly faster but still not great. Since this drive still works via USB, for now I’ll spare it the hot air treatment I performed to the Patriot. But given this level of performance I’m not sure if I can do anything useful with it.

Patriot WARP V.2 32GB SSD (PE32GS25SSD)

When the cost of flash memory dropped low enough for consumer-level solid state drives to come to market, it was a time when multicore multi-gigahertz processors sit mostly idle waiting for data to be fetched from a spinning platter hard drive. SSDs resolved that performance bottleneck and provided a huge boost to overall system performance. But like all revolutionary technology, early implementations had some serious teething issues. Some problems required operating system support like TRIM to solve, which didn’t show up until later.

In those pre-TRIM days, the most affordable consumer-level SSD were built around a JMF602 controller. It helped make SSD affordable, but without TRIM and related functions, those drives weren’t durable. My first two SSDs used JMF602 and both drives died within two years of use. When I plug them into a computer’s SATA port, they no longer enumerate as devices as if they weren’t plugged in at all.

I forgot I had kept those two drives until I found them in my pile of old computer hardware. I might as well open them up before I dispose of them. I don’t expect to see much: just a circuit board inside a 2.5″ form factor metal case. But I was curious if those two circuit boards would be identical: it is fairly common for multiple manufacturers to use the same reference implementation and sell basically identical devices.

First up is Patriot’s WARP V.2 with a paltry 32GB capacity, model PE32GS25SSD.

I found the expected single circuit board inside. The infamous JMF602 chip amongst multiple Samsung flash chips. I see a row of four vias on the lower right edge resembling an unpopulated debug header. (Not that I’d know how to debug this thing.) In the lower left, adjacent to the SATA data connector, is an unpopulated connector blocked off by the metal case. We’ll see this again later.

Four more Samsung flash chips reside on the other side of the circuit board.

I now remember why I kept the drive even after it failed: I had personal data on this drive when stopped responding. Even though it doesn’t enumerate as a SATA device for me, I was worried that the data could still be recovered. Perhaps through that debug header, or possibly a SATA diagnostic tool could unlock it.

Making data really difficult to recover is easy with a spinning platter hard drive: I would open it up to expose those shiny platters. Everyday household dust would render those data surfaces unreadable except to maybe the NSA. But at the time I didn’t know how to perform similar data destruction with SSDs. I had contemplated drilling a hole through each flash chip, but now that I have a hot air rework station, I decided to remove all 16 flash chips from the board. If someone wants to steal my data, they’ll have to decipher how my data was spread across these chips and do a lot of soldering. I may still drill a hole through one of those chips just for curiosity, but first I want to compare and contrast this drive with my second SSD based on the same JMF602 controller.

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!

[UPDATE: After buying a multichannel oscilloscope, I was able to compare fan tachometer signal versus fan behavior and concluded that a fan tachometer wire signals two cycles for each revolution. Implying this fan was spinning at 3333 RPM which still seems high.]

Miscellaneous Notes on HP Stream 7 Installation

My old HP Stream 7 can now run around the clock on external power, once I figured out I needed to disable its battery drivers. Doing so silenced the module that foiled my previous effort. (It would raise an alert: “the tablet has run far longer than the battery capacity could support” and shut things down.) Ignoring that problematic module, remaining drivers in the same large Intel chipset driver package allowed the machine to step down its power consumption. From ten watts to under two watts, even with the screen on. (Though at minimum brightness.) Quite acceptable and I’m quite certain I’ll repurpose this tablet for a project in the future. In the meantime, I wanted to jot down some notes on this hardware as reference.

The magic incantation to get into boot select menu (getting into BIOS, reinstalling operating system, and other tools) is to first shut down the tablet. While holding [Volume Down], hold [Power] until the HP logo is visible. Release power immediately or else it might trigger the “hold power for four seconds to shut off” behavior. (This is very annoying.) The boot select menu should then be visible along with on-screen touch input to navigate without a keyboard.

There are many drivers on the HP driver downloads site. Critical for optimized power consumption — and majority of onboard hardware — is the “Intel Chipset, Graphics, Camera and Audio Driver Pack”. I also installed the “”Goodix Touch Controller Driver” so the touchscreen would work, but be warned: this installer has a mix of case-sensitive and case-insensitive code which would fail with a “File Not Found” error if the directory names got mixed up. (/SWSetup/ vs /swsetup/)

The available drivers are for Windows 8 32-bit (what the machine came with) and Windows 10 32-bit (what it is successfully running now.) The machine is not able to run 64-bit operating system despite the fact its Intel Atom Z3735G CPU is 64-bit capable. I don’t know exactly what the problem is, but when I try to boot into 64-bit operating system installer (true for both Windows 10 and Ubuntu) I get the error screen

The selected boot device failed. Press <Enter> to Continue.
[Ok]

Which reminds me of another fun fact: this machine has only a single USB micro-B port. In order to use USB peripherals, we need a USB OTG adapter. Which is good enough for a bootable USB drive for operating system installation… but then I need to press [Ok] to continue! The usual answer here is to use an USB hub so I could connect both the bootable OS installer and a keyboard. There’s actually no guarantee this would work: it’s not unusual for low-level hardware boot USB to support only root-level devices and not hubs. Fortunately, this tablet supported a hub to connect multiple USB devices allowing bootable USB flash driver for operating system installation to coexist with USB input devices to navigate a setup program.

I’ll probably need some or all of these pointers the next time I dig this tablet out of my pile of hardware. For now, I return it to the pile… where I noticed an unpleasant surprise.

Disable HP Stream 7 Battery Drivers When Externally Powered

I gave up trying to run my HP Stream 7 tablet on external DC power with the battery unplugged. The system is built with a high level of integration and it has become unreliable and too much of a headache to try running the hardware in a configuration it was not designed for. So I plugged the battery back in and installed Windows 10 again. And this time, the Intel chipset driver package installed successfully.

This was a surprise, because I thought my driver problems were caused by hardware I damaged when I soldered wires for direct DC power. Plugging in the battery allowed these drivers to install. And the driver package is definitely doing some good, because idle power draw with screen on minimum brightness has dropped from nearly 10W to just under 2W. This is a huge improvement in power efficiency!

So I wanted the drivers for low power operation, but maybe I don’t need every driver in the package. I went into device manager to poke around and found the key to my adventure: The “Batteries” section and more importantly the “Micro ACPI-Compliant Control Method Battery” device. This must have been the driver that rendered the system unbootable once I unplugged the battery — as an integrated system, there’s no reason for the driver to account for the possibility that the user would unplug the battery!

But now that I see this guy exists, I think perhaps it is part of the mechanism that outsmarted me and was skeptical running on external power. I disabled the drivers in the “Batteries” section and rebooted. I reconnected the external power supply keeping battery at 3.7V. Disabling the battery power related drivers were the key to around-the-clock operation. With the battery device absent from the driver roster, there’s nothing to tell the system to shut down due to low battery. But since the battery hardware is present, the driver package could load and run and there’s something to buffer sharp power draws like plugging in USB hardware. This configuration was successful running for a week of continuous operation.

Drawing a modest two watts while idle, this tablet can now be used as anything from a data dashboard, to a digital picture frame, or any other project I might want to do in the future. I don’t know what it will be yet, but I want to make sure I write down a few things I don’t want to forget.

HP Stream 7 Really Wants Its Battery

I’ve been trying to get a HP Stream 7 tablet running in a way suitable to use as a future project user interface or maybe a data dashboard. Meaning I wanted it to run on external power indefinitely even though it could not do so on USB power alone. When I supplied power directly to the battery it would shut down after some time. The current session deals with disconnecting the battery and feeding the tablet DC directly, but this machine was designed to run with a battery and it really, really wanted its battery.

While I could feed it DC power and it would power up, it would intermittently complain about its battery being very low. This must be in hardware because it would occur when booting into either Windows or a Debian distribution of Linux. This shouldn’t be an input voltage problem, as my bench power supply should be keeping it at 3.7V. But there’s something trigging this error message upon startup and I have to retry rebooting several times before operation would resume:

HP Battery Alert

The system has detected the storage capacity of the battery stated below to be very low. For optimal performance, please attach the power adapter to charge the battery over 3%, and then re-power on the unit.

Primary (internal) Battery

Currently Capacity: 2 %

System will auto-shutdown after 10 second

Perhaps my bench power supply isn’t as steady as I assume it is. Perhaps there are problems keeping up with changes in power demand and that would occasionally manifest as a dip in voltage that triggers the battery alert. Another symptom that supports the hypothesis is the fact I couldn’t use USB peripherals while running on the bench power supply. When I plug in a USB peripheral, the screen goes black and the system resets, consistent with a power brownout situation.

So to make the hardware happy and to support sudden spikes in power requirements, I really need to plug the battery back in. Trying to run without battery was a fun experiment but more importantly it gave me an idea on running this tablet on continuous external power: silence the battery driver.

HP Stream 7 Running Debian with Raspberry Pi Desktop

My HP Stream 7 seems to be having problems with a Windows device driver, but the problematic driver is somewhere in a large bundle of Intel chipset related drivers. For another data point I thought I would try an entirely different operating system: Debian with Raspberry Pi Desktop. Also, because I thought it would be fun.

Debian with Raspberry Pi Desktop is something I encountered earlier when looking for Linux distributions that are familiar to me and built for low-end (old) PC hardware left behind by mainline Ubuntu builds or even Chrome OS. The HP Stream 7 tablet fit the bill.

One amusing note is that since HP Stream 7 is formally a tablet, the default resolution is portrait-mode which means taller than it is wide. Unlike the Windows installer which knew to keep to the middle of the screen, the Debian installer scaled to fit the entire screen making for some very difficult to read tall narrow text.

Once up and running, the Debian with Raspberry Pi desktop ran on this tablet much as Raspberry Pi runs its Raspberry Pi OS, except this configuration is comparable to a fresh installation of Windows: many devices didn’t have drivers for proper function. I disabled Secure Boot in order to access non-mainline device drivers, which is thankfully straightforward unlike some other PCs of the era I had played with. But even then, many drivers were missing. Video and WiFi worked, but sound did not. A pleasant surprise was that the touchscreen worked as input, but only at the default orientation. If I rotate the desktop, the touchscreen did not adjust to fit. And while an idle Debian drew less power (~8W) than plain vanilla Windows (~10W) it is still significantly worse than this tablet running at its best.

Seeing Debian with Raspberry Pi Desktop run on this tablet was an amusing detour and possibly an option to keep in mind for the future. On the upside, at no point did Debian complain that the battery is low, because the operating system didn’t think there was a battery at all. The hardware, however, really misses the battery’s absence.

HP Stream 7 Reboot Loop Linked to Intel Chipset Windows Driver

I disconnected the battery on my HP Stream 7 tablet and soldered wires to put power on its voltage supply lines. The good news is that the tablet would start up, the bad news is that Windows couldn’t complete its boot sequence and gets stuck in a reboot loop. After a few loops, Windows notices something is wrong and attempted to perform startup repair. It couldn’t fix the problem.

My first thought was that I had damaged a component with my soldering. A small tablet has tiny components and I could have easily overheated something. But portions of the computer is apparently still running, because I could still access the Windows recovery console and boot into safe mode. But I didn’t have any idea on what to do to fix it while in safe mode.

Since there were no data of consequence on this tablet, I decided to perform a clean installation of Windows. If it succeeds, I have a baseline from which to work from. If it fails, perhaps the failure symptoms will give me more data points to diagnose. A few hours later (this is not a fast machine) I was up and running on Windows 10 21H2. Basic functionality seemed fine, which was encouraging, but it also meant the machine was running in unoptimized mode. The most unfortunate consequence is that the tablet runs hot. The power supply indicates the tablet is constantly drawing nearly 10 Watts, no matter if the CPU is busy or idle. A basic Windows installation doesn’t know how to put machine into a more power efficient mode, putting me on a search for drivers.

Since the tablet is quite old by now (Wikipedia says it launched in 2014) I was not optimistic, but I was pleasantly surprised to find that HP still maintains a driver download page for this device. Running down the list looking for an Intel chipset driver, I found a bundled deal in the “Intel Chipset, Graphics, Camera and Audio Driver Pack“. It sounded promising… but during installation of this driver pack, the tablet screen went black. When I turned it back on, the dreaded reboot loop returned. Something in this large package of Windows drivers is the culprit. Maybe I could try a different operating system instead?

Direct DC Power on HP Stream 7 Renders Windows Unbootable

While spending way too much time enjoying the game Hardspace: Shipbreaker, I was actually reminded of a project. In the game, safely depowering a ship’s computers involve learning which power systems are on board and disconnecting them without electrocuting yourself. It got me thinking about my old HP Stream 7 tablet that couldn’t run indefinitely on USB power and refused to believe an illusion of free energy when I supplied power on the lithium-ion battery cell. I thought it might be interesting to see what would happen if I disconnected the battery and supplied DC power directly.

My hypothesis is that the earlier experiment was foiled by the battery management PCB, it was too smart for its own good and realized the tablet had consumed far more capacity than its attached battery cell had any business providing and shutting the computer down. By disconnecting that PCB, perhaps the doubting voice would be silenced.

To test this idea, I would need to find the power supply and ground planes on the circuit board. I could solder directly to the empty battery connector, but that would make it impossible to plug the battery back in and was too drastic for my experiment. I could see pads underneath the connector clearly labeled VBAT + and – but I couldn’t realistically solder to them without damaging the connector either.

Taking my multi-meter, I started probing components near that battery connector for promising candidates. The search didn’t take long — the closest component had pads that connected to the voltage planes I wanted. I had hoped to find a decoupling capacitor nearby, but this doesn’t look like a capacitor. With a visible line on one side, it looks like a diode connected the “wrong” way. Perhaps this protects the tablet from reverse voltage: if VBAT +/- were reversed, this diode would happily short and burn out the battery in the interest of protecting the tablet.

Whatever its actual purpose, it serves my need providing a place to solder wires where I can put 3.7V (nominal voltage for single lithium-polymer battery cell) to power the tablet while its original battery is unplugged.

Good news: The machine powers up!

Bad news: Windows doesn’t boot anymore!

I could see the machine boot screen with the HP logo, and I could see the swirling dots of Windows starting up. But a few seconds later, the screen goes blank. We return to the HP logo, and the process repeats. Time to diagnose this reboot cycle.

HP Stream 7 Refuses to Believe in Free Energy

After salvaging the LED backlight from a Chunghwa CLAA133UA01 display panel, I have processed all the disembodied panels in my hardware stack. But I still have plenty of other displays still embodied in some type of hardware of varying levels of usefulness. The least useful item in the pile is my HP Stream 7 Windows tablet. For reasons I don’t understand, it doesn’t want to charge its battery while it is up and running. It seems the only way to charge the battery is to plug it in while it is powered off.

If I wanted to use this tablet as portable electronics as originally intended, this is annoying but workable. But there’s not much this old tablet could do that my phone (which has grown nearly as large…) can’t do, so I wanted to use it as a display. But if it can’t charge while running, and it can’t run without its battery, then it’s not going to be useful as an always-on display. After poking around its internals, I set the tablet aside in case I have ideas later.

It is now later! And here is the idea: if I can’t convince the tablet to charge its battery while running, perhaps I can do the charging myself. I peeled back some protective plastic to expose the battery management circuit board, and soldered a JST-RCY compatible power connector(*) in parallel with the lithium-polymer battery cell.

Putting this idea to the test, I first ran the tablet until the battery voltage dropped to 3.7V, the nominal voltage for a LiPo battery cell. I then connected my benchtop power supply to this newly soldered connector. The power supply was adjusted to deliver a steady 3.7V. In theory this means the battery would drain no further, and all power for the tablet would be supplied by my bench power supply.

To test longevity, I turned off all power-saving functions so the tablet would not turn off the screen or try to go to sleep. The tablet was content to run in this condition for many hours, and after the first day I was optimistic it would be happy to run indefinitely. Unfortunately, this budget tablet was smart enough to notice something was wrong. I’m not sure how it knew, but it definitely refused to believe the illusion its battery is an endless source of energy. Despite the fact that battery voltage was held steady at 3.7V, on-screen battery percentage started dropping after about forty hours. Eventually the indicated charge dropped below 10% and entered battery-saver mode, followed by shutting itself down. Despite the fact its battery voltage was held at 3.7V, this tablet acted as if the battery has been depleted.

After the failure of this test, I contemplated pulling it apart and extract the tablet backlight as I did to a broken Amazon Fire tablet. But I decided against doing anything destructive, and I put it aside yet again hoping to think of something else later. In the meantime I switch gears from this digital tablet to an analog glass tube TV.


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

Four Screws Fasten NVIDIA GTX 1070 Dust Cover

I recently took apart three external hard drives to retrieve their bare drives within to use in an internal application. In all three cases, there were no externally accessible fasteners to help with disassembly. I had to pop plastic clips loose, breaking some of them. For laughs, I thought it’d be fun to talk about a time when I had the opposite problem: I was confronted with far too many screws, most of which weren’t relevant to the goal.

I have a NVIDIA GTX 1070 GPU and it had been in service for several years. NVIDIA designed the cooling shroud with a faceted polygonal design. Part of it was a clear window where I could see dust had accumulated through years of use. I thought I should clean that up, but it wasn’t obvious to me which of the many visible screws held the dust cover in place. The visual answer is in this picture:

In case these words are separated from the illustrative image, here is the text description:

Starting from the clear window, we see four fasteners closest to them. These four fasteners hold the clear plastic to the dust cover and not useful right now. We need to look a little bit further. There are two screws further away between the clear window and the fan. Those are two of the four dust cover screws. The remaining two are on the top and bottom of the card, closer to the metal video connector backplate. Once these four screws are removed, the dust cover can slide sideways (towards the backplate) approximately 1cm and then the dust cover can lift free. After that, the four screws holding the clear window can be removed to separate the window from the rest of the dust cover.

In the course of discovering this information, I had mistakenly removed a few other screws that turned out to be irrelevant. Since they’re not useful to the task at hand, I put them back without digging deeper into their actual roles.

Goodbye and Good Riddance To This Generation of Hybrid Drives

I have successfully upgraded a HP Pavilion Split X2 (13-r010dx) to use a modern M.2 SATA SSD with the help of an adapter circuit board. The results were stellar and, even though the adapter does not mount inside the computer properly, I have no plans to put the original drive back in. It was a compromised solution of its era and times have moved on.

A little over ten years ago, flash-based solid state drives started edging towards price levels affordable to normal computer buyers. A few bargain basement devices were released, and they were terrible. I had two JMF602-based drives that lasted through their 90-day warranty periods but not much beyond that. The big breakthrough in affordable and durable performance is credited to the Intel X25-M, but the capacity was quite small. SSD performance is something that I had to experience to be converted to a fan, and it was hard to get non-converts to accept living with 80GB of capacity when we had become accustomed to hundreds of gigabytes.

The compromised solution was the SSD/HDD hybrid drive: there is a magnetic platter hard disk drive, but there is also a small piece of flash memory acting as a small solid-state drive cache. The advertising proclaimed that we would get the capacity of a HDD with all the performance of a SSD. I thought the concept was enticing, but never actually got one to try.

I’m glad I did not, if this computer’s stock WD5000M21K hybrid drive is representative of the breed. Its performance was absolutely terrible. Maybe modern workloads overwhelmed its meager 8GB of flash cache. Maybe years of use has worn out the flash and there was no caching anymore. Whatever the reason, its performance was no better than a HDD, definitely nowhere near the performance of a real solid state drive.

Now solid state drives with plenty of elbow room are quite affordable, giving old computers a new lease on life. The hinderance of oddball connectors like the SFF-8784 become just a speed bump with help of adapters, so we don’t need to put up with the compromises of SSD/HDD hybrid drives anymore.