Atomic Pi Adventures, Episode 1: Adding external PCI Express expansion by removing onboard Ethernet

As seen on Hackaday!

TL;DR: The Atomic Pi single-board computer CAN be expanded through PCIe. It’s just a massive pain to do so, even if you have steady hands. Let’s just say it’s a long story…

DISCLAIMER: The modification performed in this blog post can, and has, caused permanent hardware damage to my Atomic Pi, albeit repairable with much skill and effort. Reenacting what I’ve done requires significant experience with SMT (surface-mount technology) components, some barely larger than a grain of sand (I consider 0402-size components to be “oversize” in this instance). I accept no responsibility for damages arising from attempting this modification.

Introduction

Single-board computers (SBCs) are all the rage nowadays, with the Raspberry Pi being the most well-known in this category. SBCs are compact computers, carrying their own CPU and memory, and usually some on-board storage and various I/O connections (e.g. USB, HDMI, Ethernet). Most of these computers use the ARM architecture, found on almost all mobile devices today. However, some use the x86 architecture, which is used in higher-end tablets, laptops and desktop computers.

Recently, the Atomic Pi made waves in the electronics hobbyist space, boasting an Intel Atom Z8350 quad-core CPU with 2 GB of RAM, 16GB of eMMC storage, Gigabit Ethernet, Wi-Fi, USB 3.0, built-in speaker amplifiers, and lots of general-purpose I/O (GPIO) pins – all for less than $40 USD!

As one might expect, there were caveats to this little computer, with some dismissing it very harshly, if not unfairly. With some investigative work, members of the community found out that the “Atomic Pi” board actually belonged to the Kuri robot from Mayfield Robotics; the company shut down in late 2018, and the liquidated stock of these SBCs were snatched up by Digital Loggers with the help of a Kickstarter campaign, who then developed breakout boards to make using them easier. This is because – unlike almost every other SBC – you can’t just plug in a barrel jack or USB cord to power it! Instead, it uses a 2×13 pin header, which many users did not have on hand, nor had the skill and/or resources to build their own solution. This is compounded by the board’s need for clean, well-regulated 5 volts at 2-4 amps, with 12 volts being optional to power the onboard speaker amplifier. The 16 gigabytes of eMMC storage proved to be too cramped to run Windows 10 directly, and the Realtek RTL8111G Gigabit Ethernet chipset is often frowned upon by those in the pfSense (a free firewall/router OS) community.

The NIC’s usage of the Z8350’s single PCI Express (PCIe) lane is what caught my attention. Unfortunately, the RTL8111G Ethernet chip is soldered to the board, with no easy method to replace it with an external card. A few people have attempted to remove the chip and wire in an external PCIe riser, without success. With my previous experience with fine-pitch electronics work, I figured that this would be a fairly easy modification to make.

It wasn’t. In fact, this was one of the most frustrating electronics projects I’ve done to date – and now you get to come with me in my adventures (and misadventures) in microsoldering on the Atomic Pi (or was it Kuri? The jury seems to be out on the nomenclature).

Optional Reading: PCI Express Signals

PCI Express (or PCIe for short) is a very common high-speed interface for connecting processors or chipsets to all sorts of different peripherals. It uses low-voltage differential signaling to minimize interference, and a single lane of PCIe can carry 250 MB/s for the first generation, all the way up to 2 GB/s for the fourth generation!

A single PCIe lane is made up of three differential pairs: receive, transmit, and a 100 MHz reference clock. Control signals for waking up and resetting peripherals are also provided. Riser cards, often used for cryptocurrency mining, use these five signals to provide the minimum connectivity for any PCIe peripheral. The interface is highly flexible, allowing graphics cards that normally use 16 lanes to run on just one lane. The specifications for PCIe make board design easier, as the differential lines are designed to adapt to different lane configurations; the polarities in a pair (transmit, receive, clock) are polarity independent (all that matters is that you maintain a good differential pair).

PCIe Signal Pinout

Since the Atomic Pi lacks a PCIe slot of any kind, I have provided the diagram indicating which signals go to what points on the board:

Note that the AC coupling capacitors are required for the peripheral Rx (receive) pair, and are optional for the peripheral Tx (transmit) pair.

Attempt 1: “Chipple” Bypass

I started this project with the intent of making my modifications as reversible as possible. Looking at the RTL8111E’s datasheet (a similar model to the 8111G) revealed the presence of an “ISOLATEB” pin; grounding this pin causes the chip to disable itself and release its hold on the PCI Express lines.

This brings us to the first roadblock: the Ethernet chip is soldered to the board, and the components that connect it are known as 0201 (0.002 inches in length, 0.001 inches in width), smaller than a breadcrumb!

After disabling the Ethernet chip, I used my trusty 0.1mm (that’s four-thousandths of an inch!) magnet wire to tap into the PCIe lines, and brought them out to a PCIe riser card, which provided a USB 3.0-type socket for an external connection.

Unfortunately, high-speed signals aren’t just about wiring from one device to the next, and this was no exception. The rat’s nest of wires were no suitable medium for the 5-gigabit signals to traverse (PCIe requires very tight control of electrical trace layouts), and the Atomic Pi was unable to detect the presence of any device on the external PCIe port.

Attempt 2: Thin Twinax Troubles

With the signaling issue in mind, I tried some very thin twinaxial cables from a dead MacBook’s hard drive cable to connect the PCIe lines to my riser card. This cable is very thin, with an outer thickness similar to fishing line. It uses a foil and wire “shield” around the two internal wires to protect it from external interference. I figured that this should help protect the delicate signals from the harsh outside world.

I didn’t have very much of this thin twinax cable on hand (that said, if anyone knows where I can buy this stuff in bulk, please let me know!), so I was limited to very short lengths for each pair. I ran out of twinax after the transmit and receive pairs, and resorted to using two coaxial cables from that same cable bundle.

After fiddling with the super-thin wires and soldering them to the header, I still got nowhere and could not get the Atomic Pi to see an external PCIe card.

Removing my modifications revealed my first blunder: despite placing the chip into a temporarily disabled state, the Ethernet chip was dead! This meant that I could not use the built-in Ethernet port anymore, and the LEDs next to the Ethernet port simply glowed a dull orange instead of their rapid blinking pattern when data is being transmitted over Ethernet. I figured that there was no use keeping the chip on the board, so I used my hot air rework station to remove it, using a generous amount of heat and flux to get the chip removed.

Attempt 3: To Ribbons, You Say?

With the dead Ethernet chip removed, I decided to use another tactic to bring out the PCIe interface. I decided to use a thin ribbon cable (okay, more accurately a “flat flexible cable”) to help decouple any mechanical stresses from moving the external USB 3.0 connector around during testing, and its compact size allowed me to try using the QFN pads to connect my ribbon cable, hopefully minimizing noise that could be picked up, as well as avoiding any “stubs” of wiring within the differential pair that would degrade the signals.

The challenge is that the chip uses a very small pad spacing, and I wanted to avoid soldering directly to the ribbon cable. I managed to salvage a couple connectors from some other devices, and used a cut-up CompactFlash memory card’s PCB to make it easier to solder the connector, as well as provide a base for the connector to sit on.

The connector on the board was affixed onto the Ethernet chip’s footprint with the help of some double-sided foam tape, and magnet wire was used to bond the PCIe signal wires onto the ribbon cable. The ribbon itself used copper foil on one side to help with interference suppression, and provide the signals a “ground plane” to travel across.

Things weren’t quite as elegant on the other end of the cable, however. I still had to contend with a fine-pitch ribbon connector, and a way to connect that to a male USB 3.0 plug to hook it up to the PCIe riser. I had little option except to use the small lengths of twinax from the last attempt, and (perhaps unsurprisingly) it didn’t work.

Attempt 4: Teeny Tiny Twists

The next attempt went to a smaller scale, using a very fine twisted pair I created out of my 40 AWG magnet wire (each wire is as thick as a hair). I then shielded this magnet wire by sandwiching it between pieces of copper tape to act as a ground plane for the signals. I reused a dead USB 3.0 drive to act as the plug for the PCIe riser, and wired it straight to the QFN pads of the original Ethernet chip.

Although the twisted pair would have, in theory, reduced intra-pair skew and some degree of EMI resistance thanks to the copper tape, the homemade twisted pair almost certainly would not have provided a 100-ohm differential impedance that’s required for PCIe signaling. Once again, the attempt to break out PCIe from the Atomic Pi was a failure.

Attempt 5: SASsiness Yields Results…?

Since the central issue with external PCIe connectivity involved the connection between the Atomic Pi board and the riser, I figured I would try a medium that was specifically intended for high-speed differential signals. I bought some thin SATA cables (specifically the 18-inch thin cables on Amazon), which used two pairs of thin SAS cable per SATA connection. The difference between SATA, SAS and PCIe is of little difference here, as the key criteria was a differential pair with 100-ohm impedance and ability to carry high-frequency signals.

Despite being a thin cable (each conductor is only 30 AWG, or 0.25 mm in diameter), these cables were too stiff to directly connect to the AC coupling capacitors without a very high risk of damaging the capacitor and/or the pad it is soldered to. I had to reinforce the cables by soldering them down and hot gluing the cables to the board at multiple points to relieve stress on the connections.

The original 0201-sized AC coupling capacitors were removed, and more reasonably-sized 0402 capacitors were used in their place. Each capacitor was a common 100nF capacitance, and were easy to harvest from some dead laptop motherboards I had on hand. I “flipped” the layout of the capacitors away from the QFN footprint, but this meant that only one side of the capacitor was actually anchored to the board; this made the capacitors very fragile and I often lost the terminations on the capacitors (thankfully they are plentiful in electronic devices like this).

To help minimize stress on the vulnerable capacitors, I used magnet wire as a flexible “bridge” between the capacitor and the SAS cable, and the cables were tied down to solder tab wire that I used as “bus bars” for a strong electrical ground as well as a tie-down point to take away most of the strain of the cable’s flexion. Despite negatively affecting signal integrity, I was able to get a sufficiently stable connection to perform some initial testing, and I succeeded! I was able to connect an Intel 82576-based dual-port network card to my external riser.

However, this didn’t last long. The simple movement of the wires on the board when trying to connect different peripherals was enough to break the AC coupling capacitors, despite the use of my flexible terminations from the SAS cable to the capacitors. Replacing the damaged capacitors and redoing the magnet wire terminations failed to restore connectivity, so I desoldered all of the existing connections and started over.

Attempt 6: We Have Lift-Off! (that’s bad)

In an attempt to further improve signal integrity, I decided to take the bold move of eschewing the flexible terminations of magnet wire, and decided to directly solder the SAS cable’s wires to the capacitors, which are soldered to the PCIe pads on the Atomic Pi. I anticipated that physical stresses would damage the capacitors, so I opted to use longer lengths of SAS cable, and to hot-glue the cable to the board at regular intervals to minimize the amount of stress that gets coupled into the cable and capacitors. The 100 MHz reference clock continued to use magnet wire for connection as it was at a much lower frequency than the PCIe signals, and reduced the amount of physical crowding around the PCIe pads.

This leads me to my next issue. To help with structural integrity, I repositioned one of the SAS cables so that it would remain on the board before going to the PCIe riser connector, meaning it would be perpendicular to the other cables. This required me to strip extra foil shielding to jump over the existing capacitors, which increases the risk of physical stress on the capacitors, as well as reduced signal integrity. Additionally, I used a longer set of twinax cables, sacrificing two SATA cables to get most of the original 18 inches of length per cable.

Testing of this construction method failed, and it was only at this point that I realized that two of the four AC coupling capacitors I used weren’t the same capacitance; PCIe usually uses 100 nF capacitors, but I had a 1 nF on one PCIe pair, and 10 nF on the other – no wonder things weren’t communicating (and that’s what I get for assuming the capacitors were the same)! Unfortunately, the process of removing the SAS cable connections resulted in the phenomenon I was trying to avoid: the board’s PERp0 (the positive side of the PCIe receiver) pad had lifted away from the PCB, leaving me with an unsolderable crater.

Attempt 7: Success!

After losing one of the pads for the original coupling capacitors, I was feeling pretty defeated. I didn’t let this stop me, and I decided to apply my magic skills with 40-gauge magnet wire to the trace, and was able to get a sufficient connection with a replacement 100 nF capacitor (and this time I measured it…), hopefully in such a way as to not too negatively affect signal integrity. Unfortunately, the 0201-sized resistors used to connect the PCIe reset and wake signals lost their terminations and no longer took solder on one end; I opted to keep the resistors in place and soldered magnet wire to the other end (facing the SoC rather than the Ethernet chip), as further measurement revealed that the resistors were simply 0-ohm jumpers anyway. I scrapped the longer SAS cables, and went back to the ~8-inch lengths to reduce attenuation.

After rewiring the PCIe data, clock and control lines, I crossed my fingers and retried the riser with my Intel NIC – and it worked! After verifying the connections were sufficiently strong, I decided to make the modification permanent, and covered the area with epoxy to prevent any of the components from breaking loose. Additionally, I used some aluminum sheet metal, double-sided foam tape and some zip ties to create a reinforcement bar, helping to strengthen the cable connections as they leave the board.

With all the connections in place, it was time to get to the fun part: seeing what PCIe peripherals work on the Atomic Pi!

Testing Results

One interesting behaviour of the Atomic Pi when using Windows is that changing PCIe cards often causes the system to immediately power down or freeze during boot. Simply powering the board on again seems to fix this issue. Why am I using Windows? I already upgraded the board to a 64GB eMMC instead of the original 16GB, and the appeal of the Atomic Pi’s x86 architecture was the ability to run desktop apps – in particular, Windows apps.

The UEFI firmware has a hidden advanced menu, accessible if the “shutdown /r /fw” command is run as administrator. There is a section for PCIe settings, and the ones that interested me were the AER (Advanced Error Reporting) and PCIe hot-plug settings. Unfortunately, these do not seem to have any effect as Windows doesn’t seem to pick up any hardware events in the Event Log.

Test 1: Network Devices

PASS: Intel 82576 Dual-Port Adapter

If the port(s) have a connection to another device (e.g. a network switch), the orange and green LEDs will illuminate soon after the PCIe link is properly initialized, which makes for quicker troubleshooting. Even if the system is off, the green link LED remains lit, but goes out once the PCIe bus is reset.

The card works a treat in pfSense and Windows, allowing high-performance Gigabit-speed transfers with both ports in use. However, the UEFI firmware does not recognize the card as a bootable medium (which is for the best in my opinion – the PXE boot program tends to hinder the boot process more than anything).

PASS: Realtek RTL8111GS (External Card)

The PXE network boot program built into the UEFI firmware works just fine, which is expected as the chip is the same type as the original RTL8111G, with the exception that the chip has a built-in switching converter rather than the linear LDO that the Atomic Pi uses natively.

PASS: JMicron JMC250

The card works in Windows and pfSense; the particular card I have has always been flaky in operation, and this was no exception.

PASS: ASUS PCE-N15 (Realtek RTL8192CE) 802.11n WLAN Adapter

Using this card is a performance downgrade compared to the dual-band adapter already present on the Atomic Pi, but it did function correctly in Windows.

Test 2: External Graphics Cards (eGPU)

PASS: EVGA/nVidia 8500 GT

The UEFI firmware doesn’t seem to want to acknowledge the presence of PCIe graphics adapters, which results in issues when testing in Windows. Initially, the card failed to enumerate correctly, identifying as a Microsoft Basic Display Adapter and displaying an error in Device Manager:

This device is not working properly because Windows cannot load the drivers required for this device. (Code 31)

The driver trying to start is not the same as the driver for the POSTed display adapter.

Manually downloading and installing the drivers allowed the card to work properly. As previously mentioned, the UEFI does not recognize the presence of the graphics card, so a monitor that is plugged into the graphics card won’t start working until Windows is loaded and the graphics driver initializes.

Additionally, the adapter’s resources won’t be used if the monitor is connected to the Atomic Pi’s built-in HDMI port – it’s a tradeoff between graphics performance and the ability to see what’s happening on boot; maybe this is different in a multi-monitor configuration, but I didn’t have enough desk space to test this.

PASS: XFX/AMD Radeon 4650

The same driver issues popped up when using this card as well, and the same fix applies.

PASS: ASUS/nVidia GTX 660 Ti

Ditto. This card was the best I had on hand for testing, and amusingly it consumes about 10-20 times the amount of power that the Atomic Pi uses, and is bigger in size as well.

Connecting this card allowed me to run games that would otherwise simply not work, such as Just Cause 2. It performed at about 20-30 frames per second: not great but not terrible. Just Cause 3 was absolutely painful to run, but this is not surprising as the Atomic Pi’s hardware is far below the game’s minimum requirements in almost all aspects.

Test 3: Storage

PASS: Dell PERC H200 SAS Adapter

To my surprise, not only will it work in Windows, it even supports booting from the UEFI! It mentions a SAS controller driver during boot, but I am not sure as to whether this is present in the Atomic Pi’s UEFI, or if it is a driver provided by the SAS adapter itself. The PCIe 2.0 1x interface limits the maximum throughput to less than 500 MB/s, which is slower than a single SATA III connection, and informal testing showed a maximum speed of about 330 MB/s. I have not investigated whether I could configure the hardware RAID features of the adapter from the operating system, but I imagine that doing so would dramatically improve performance when running a RAID 1 (mirrored) setup.

FAIL: OWC (What’s This?) Aura Pro X 480GB NVMe SSD

This SSD was originally meant as an aftermarket SSD upgrade for a MacBook Air, but I bought a PCIe adapter card to use it in a regular PC. I was able to get it to enumerate in Windows, but any sort of read/write action caused it to lock up and throw errors in the Windows Event Log. I suspect this is likely a power supply issue due to how the PCIe riser board provides power (12 volts -> DC/DC converter -> 3.3V LDO linear regulator), or maybe the card just doesn’t want to cooperate.

FAIL: Marvell 88SE9128 2x SATA III + 1x PATA UDMA-133

This adapter caused Windows to almost freeze during boot. Instead, the boot animation would advance by one frame every 2 seconds until the card is removed. I suspect this is the PCIe bus attempting to negotiate a connection but failing, possibly due to signal integrity issues. Checking the Windows Event Log turned up nothing either.

Test 4: … More PCIe?

FAIL: Extender Cable

One would think that a simple straight-through cable would work, right? Nope – it seems like the signal has already been degraded enough after traveling across multiple non-ideal connections, and the extra length in a cable was just enough to degrade the signal beyond recovery.

UNKNOWN: PCIe Port Multiplier / Pericom PI7C9X2G PCIe Packet Switch

As of the writing of this blog post, I haven’t received this in the mail yet; I am eager to test it out once it arrives – if it works, this could allow more than one PCIe peripheral to be connected to the Atomic Pi, and hopefully alleviate some signal integrity issues in the process. If the devices support peer-to-peer transfer, that would be even better.

Conclusion

Despite all the roadblocks I encountered in this project (sometimes rage-inducing ones), I still enjoyed this project and the various techniques I tried along the way. The prospect of attaching desktop PCI Express peripherals to a CPU designed for a tablet opens up many different applications for the Atomic Pi, including ones that would otherwise have been less efficient or impossible using the board’s built-in hardware (e.g. dual Gigabit Ethernet without using USB, or GPU-intensive computing workloads).

The high-speed nature of modern computer systems presents many challenges for engineers and modders alike. Multi-gigabit interfaces easily reach into the realm of radio-frequency (RF) electronics, where things like AC transmission line effects and differential signal routing become very important. This issue, coupled with the fact that most modern devices use very small components, makes it difficult for many electronics hobbyists to access these interfaces on their own. Although a modification like what I did is technically possible, I don’t consider it practical for an average electronics/computer enthusiast.

Future Ideas

One avenue I’ve thought about pursuing is a mod board that is soldered onto the Atomic Pi’s PCB, allowing a more robust connection for the PCIe lines; this would include signal integrity improvements like ESD protection and PCIe line redrivers to strengthen the signals to/from the SoC and peripheral(s). PCB design is currently beyond my scope of knowledge, but it would be a fun way to dive right into the subject matter.

 

Advertisements

eMMC Adventures, Episode 4: Recovering data from physically damaged BGA eMMC Flash storage chips

As seen on Hackaday!

The ball grid array (BGA) chip package has been instrumental in getting modern electronics to fit in smaller and smaller spaces, as it uses tiny balls of solder on the bottom of the package to make electrical connections, instead of copper leads on the edge of the chip package. This allows for hundreds of connections to be made in a small amount of PCB area, but their size also makes them very vulnerable to damage as well.

One common way for BGA chips to become damaged is called “pad cratering“, where the copper pad on the package’s substrate (basically a wafer-thin circuit board) separates and leaves behind a crater.

Continue reading

eMMC Adventures, Episode 3: Building a custom adapter to use cheap eMMC-based 32GB SSD modules

As seen on Hackaday!

While on my quest for more eMMC-based storage devices, I stumbled upon a few devices that piqued my interest: eMMC-based SATA SSDs! I found two models of particular interest: Dell had M.2 modules with a 2.5″ adapter, and HP had custom boards intended for use in cheap laptops (for example, the HP 14-an012nr). Although the former was easier for me to use (but not acquire), I will be focusing on the latter in this blog post.
Continue reading

Gaining access to the Windows CE desktop (and Doom!) on the Keysight DSOX1102G Oscilloscope

As seen on Hackaday!

TL;DR – Yes, the Keysight 1000 X-Series oscilloscope runs Doom! The journey getting there wasn’t easy, though.

The oscilloscope is one piece of equipment that any self-respecting electronics enthusiast should have. In short, oscilloscopes let you view the electronic waveforms of a circuit, and digital storage oscilloscopes (DSOs) are especially useful since they can reveal infrequent glitches on signals that an analog oscilloscope or a multimeter wouldn’t pick up.

DSC_2506

Keysight DSOX1102G oscilloscope

The subject of my blog post is the DSOX1102G from Keysight Technologies (formerly Agilent), which is part of their low-end offerings that still offer very good value compared to their competitors. As with most of their oscilloscope offerings, they run an embedded operating system called Windows Embedded CE 6.0 (AKA Windows CE or WinCE), but as with most WinCE applications, you almost never see the Windows interface since it’s hidden behind a custom user interface.

Continue reading

eMMC Adventures, Episode 2: Resurrecting a dead Intel Atom-based tablet by replacing failed eMMC storage

As seen on Hackaday!

Recently, I purchased a cheap Intel Atom-based Windows 8 tablet (the DigiLand DL801W) that was being sold at a very low price ($15 USD, although the shipping to Canada negated much of the savings) because it would not boot into Windows – rather, it would only boot into the UEFI shell and cannot be interacted with without an external USB keyboard/mouse.

The patient, er, tablet

The tablet in question is a DigiLand DL801W (identified as a Lightcomm DL801W in the UEFI/BIOS data). It uses an Intel Atom Z3735F – a 1.33GHz quad-core tablet SoC (system-on-chip), 16GB of eMMC storage and a paltry 1GB of DDR3L-1333 SDRAM. It sports a 4500 mAh single-cell Li-ion battery, an 8″ 800×1200 display, 802.11b/g/n Wi-Fi using an SDIO chipset, two cameras, one microphone, mono speaker, stereo headphone jack and a single micro-USB port with USB On-The-Go support (this allows the port to act as a USB host port, allowing connections with standard USB devices like keyboards, mice, and USB drives).

Continue reading

Reading out HDQ-equipped battery fuel gauges with a serial port

Battery fuel gauges are the unsung hero of the battery world. There’s more to it than just measuring the voltage on the battery terminals,. These little chips are microcontrollers (tiny computers, essentially) that sit inside the battery pack and keep tabs on the battery’s performance for the life of that battery pack.

Texas Instruments makes battery fuel gauges that are small enough to fit in the circuitry of a cell phone, and one of the most common ones that uses this technology are iPhone batteries. These batteries use a single-wire interface called HDQ (which stands for High-Speed Data Queue). It may sound similar to Dallas Semiconductors’ 1-Wire protocol, but the two are completely different and incompatible with each other.

Protocol details

The HDQ protocol can be emulated with a serial port and a little bit of external circuitry. The protocol can be emulated with a serial port at 57600 baud with 8 data bits, no parity bit and 2 stop bits. Because this is a bi-directional bus, an open-drain configuration is needed. Most TTL serial ports are not open-drain, so some circuitry is required to do this. TI’s application note suggests using a CMOS inverter and an N-channel MOSFET along with a 1 kOhm pull-up resistor, but this can be cut down with a 74HC07 open-drain buffer and pull-up resistor.

[EDIT: June 13, 2015 – Corrected schematic]

The HDQ protocol uses a short pulse to indicate a logic 1, with a longer pulse to indicate a logic 0. The data is sent LSB (least significant byte) first, with a 7-bit address and an eighth bit to indicate if the operation is a read or write (0 is read, 1 is write). If it is a read operation, the fuel gauge will respond with one byte of data. As you might think, this is a very slow means of communication; the typical bus speed is 5-7 kilobits per second, but the actual usable throughput will be less than this.

The hack in this is that the bit timing can be made by sending a specially crafted UART byte that meets the timing specifications. Each bit takes up one byte of UART buffer memory, with 24 bytes being enough to perform an HDQ read (the first 8 bytes are echoed back to the PC and need to be ignored by the software). TI’s application note goes into this with a bit more detail.

Windows HDQ utility

HDQ utility icon, in all its pixelated glory.

HDQ utility icon, in all its pixelated glory.

I have written a small Windows program that will read out the battery’s main data, identify as a certain iPhone battery model (most iPhone batteries are supported), and save a copy of this data to a text file for safekeeping. This program requires the National Instruments LabWindows/CVI Runtime library to run, since I whipped this program up with the first available IDE on my college PC.

fdd82eef8d

Screenshot of HDQ Utility version 0.96

The source code is not yet available (translation: I’m too ashamed of my programming skills to share it with others); however, a Windows executable is available for download below.

You will need to download the National Instruments LabWindows/CVI Runtime to run this program.

Current version (0.96): https://www.dropbox.com/s/pf0vszgfei7s8ly/HDQ%20Utility%200.96.zip?dl=0

Version 0.95: https://www.dropbox.com/s/7xdurbh9qibdftl/HDQ%20Utility%200.95.zip?dl=0
Version 0.9: https://www.dropbox.com/s/cd3esa5us6elfgr/HDQ%20Utility.zip?dl=0

Contributions are always accepted! Email me if you would like to send in a battery for me to analyze, or you can buy me a coffee through PayPal:


[EDIT – July 28, 2016] Welp, looks like the PayPal button’s broken (or was it never working to begin with…?). If you’d like to send anything to me, just give me a shout at ginbot86@gmail.com!

[EDIT – August 2, 2016] Whoops, looks like I never had the button working in the first place. Hopefully it works this time.

 

So Phone Me Maybe: A list of iPhone/iPad batteries with gas gauge functionality

Looking for my HDQ Utility to read out your own batteries? Click here!

UPDATE: Turns out the iPhone 3G and 3GS do have gas gauges! I will add them to my list as I find out more about them.

Each iPhone generation since the iPhone 4 iPhone 3G uses a TI gas gauge and uses the HDQ bus (iOS refers to this as the SWI [single-wire interface]) to communicate with the outside world. For more information about the HDQ protocol, click here.

I’ve noticed that many of the iPhone 5S and 5C batteries that can be purchased online are reusing iPhone 4 circuits, which will cause a significant decrease in gauge accuracy (proper parameters need to be programmed into the gas gauge, and that information is chemistry dependent), and the protection circuits in the iPhone 4 battery PCB will kick into overvoltage protection mode at 4.25 volts, less than the 4.3 volts that the iPhone 5 (and newer) batteries need to charge fully.

Because I have been unable to find a list of information of each battery generation, I’m making one myself. Because nobody else has dug this deep into the fuel gauges that the iPhone uses, I have to get this information experimentally (that is, by buying various batteries from online shops; the iPhone 5S battery has been very difficult to get, besides the fake ones I mentioned earlier).

So far I’m in need of an iPhone 3G (not the 3GS) battery, as well as all iPad batteries (or, if you have my program on hand, what model the battery is intended for, the fuel gauge device (eg. bq27541, bq27545), firmware version and designed capacity.

Model Gas Gauge Firmware Designed Capacity Default Unseal Key? Comments
iPhone 3G bq27541 ? ? Yes (0x36720414) Need to acquire one of these.
iPhone 3GS bq27541 1.17 1200 mAh Yes (0x36720414) Limited feature set. My utility will throw “No response” errors when reading this battery.
iPhone 4 bq27541 1.25 1420 mAh Yes (0x36720414)
iPhone 4S bq27541 1.35 1430 mAh Yes (0x36720414)
iPhone 5 bq27545 3.10 1430 mAh No (0x52695035) Many thanks to Yann B. for finding the unseal key!
iPhone 5S bq27545 3.10 1550 mAh No (0x84966864)
iPhone 5C bq27545 3.10 1500 mAh No (0x84966864)
iPhone 6 sn27545-A4 (note 4) 5.02 1751 mAh No (0x65441236)
iPhone 6 Plus sn27545-A4 (note 4) 5.02 2855 mAh No (0x18794977)
iPhone 6S sn27546-A5 (note 5) 6.01 1690 mAh No (0x90375994)
iPhone 6S Plus sn27546-A5 (note 5) 6.01 2725 mAh No (0x11022669)
iPhone SE Unrecognized (note 6) (A1141/0x1141) 1.03 1560 mAh No (unknown) (See note 6)
Apple Watch (38mm) sn27545-A4 5.02 235 mAh No (0x09130978)
Apple Watch (42mm) sn27545-A4 5.02 245 mAh No (unknown) If anyone has one that reads “FULL ACCESS” in my program, please send it to me! 🙂
iPad (3rd gen) bq27541 1.35 11560 mAh Yes (0x36720414)

Notes:

  1. All known iPhone battery models use custom firmware, so not all of the features that the mainstream gas gauge models use are available. For example, none of these gauges will calculate the battery’s State of Health percentage (it is basically the percentage of the battery’s full charge capacity (it degrades with use) versus its designed capacity.
  2. The iPhone 5C’s battery label indicates a designed capacity of 1510 mAh, but the battery I’ve received indicates a capacity of 1550 mAh. As I have only been able to get one of these batteries that seem to be genuine, I will need to get more batteries of this type to confirm that this information is correct.
  3. The iPhone 5’s battery label indicates a designed capacity of 1440 mAh, but the fuel gauge reports 1430 mAh. The 5S battery reports 1550 mAh, but is labeled 1560 mAh. The 5C reports 1500 mAh, but is labeled 1510 mAh.
  4. The iPhone 6 and 6 Plus use a special firmware that is identified in TI’s battery software (except the very latest releases where such data was removed), and it has a very extensive feature set, and a lot of data logging features.
  5. The iPhone 6S/6S Plus use a firmware version similar to the iPhone 6/6 Plus, but with a newer chip and some features trimmed out. I’m reasonably confident that the chip is an sn27546-A5 but have no idea if it’s the official part designator.
  6. The iPhone SE battery seems to have a unique custom chip, but has gone back to a DFN-based package (similar to bq27541) rather than a BGA like the bq27545/546. It is marked “A1141” and does not respond to my HDQ adapter, only the official TI EV2300/EV2400. I have only one in my possession, so I am not 100% sure whether this is true for this series of batteries.

An Easy Hook-Up: Creating breakout Power/HDQ breakout boards for iPhone smart batteries

Now that I’ve been amassing a greater and greater arsenal of iPhone batteries, it’s gotten to the point that it makes most sense to create a connector board that can bring out the Pack+/Pack- pins alongside the HDQ data pin so I can view the gauge’s status in GaugeStudio.

Why use iPhone batteries in DIY projects?

The benefit of using iPhone batteries (note they must be for the iPhone 4 or newer; older ones will lack the fuel gauge) in microcontroller-based projects, is that the fuel gauge allows the microcontroller’s program to read out its current battery level, power consumption, capacity and time-to-empty; you also get the usual built-in protection circuit to safeguard against short-circuits, overcharge/overdischarge and overcurrents.

Additionally, iPhone replacement batteries are easy to find online or in cell phone repair shops, making them cheap and plentiful.

What is this “HDQ” that I keep talking about?

HDQ is a communication bus originally made by Benchmarq (now a part of TI). It stands for “High-Speed Data Queue”, and is a serial bus that transmits data over a single wire. This, however, is not to be confused  with Dallas Semiconductor’s 1-Wire protocol. The basic idea is the same but they are completely incompatible with each other.

Board construction

The board was made up of an iPhone surface-mount connector, a 4-pin connector for HDQ data transfer, a 2-pin male header, and a 2-terminal screw terminal. As with many of my prototype boards, wiring of the board is done with thin, flat solar cell tabbing wire. It’s flat, pre-tinned, and can handle high currents easily.

The benefits of this sort of board is that it allows:

  • Easy, removable connections to the battery; no need to solder to the battery terminals directly
  • Access to the HDQ data pins and power terminals
  • Real-time monitoring of battery State-of-Charge (%), current (mA), voltage (mV), capacity (mAh) and also the remaining time-to-empty (minutes).
  • Adaptability for different connectors (either by making a separate board for that connector or by creating a single “universal” board)
  • HDQ protocol can be used by a microcontroller via either bit-banging the protocol, or using an on-chip UART. (subject to a separate post in the future)

Although I could have created one large breakout with all the available connectors populated, I wanted to be able to use multiple batteries at once for powering different devices. Additionally, the HDQ bus has no support for addressing multiple devices.

The iPhone 4, 4S and 5 batteries have an additional NTC thermistor pin, but I have left them disconnected since I can read out the battery temperature over HDQ anyways.

Safety

Keep in mind that not all Li-Ion batteries have the same charging voltage. The iPhone 4 and 4S batteries use a 3.7 volt cell, charging at 4.2 volts; but the iPhone 5, 5S and 5C batteries are 3.8 volts, charging at 4.3 volts. 4.3 volt cells can charge at 4.2 volts with a capacity reduction of 5-10%, but 4.2 volt cells must not be hooked up to a 4.3 volt charger. There is overcharge protection built into the battery but it should not be relied upon for regular charging. Apart from the usual risk of the battery catching fire (or even just puffing up like a balloon), you also permanently decrease the battery’s capacity and dramatically increase its internal resistance, essentially crippling the battery for life.

Review, teardown and analysis of Charging Essentials USB wall outlet

(UPDATE: March 2, 2015 – I’ve picked up a pair of the newer tamper-resistant versions of this wall outlet. A review and teardown on that unit is coming up; stay tuned!)
(UPDATE 2: May 29, 2016 – Scratch that on the first tamper-resistant model; it had the same performance as the one mentioned here. Also, Costco has released a 3.1A version of this outlet, and is currently under review.)

About a week ago I bought a set of wall outlets from Costco that integrate two USB charging ports into a standard Decora-type receptacle. It’s marketed to replace your traditional AC adapter, allowing other appliances to be plugged in while charging your portable electronics.

The outlet is made by Omee Electrical Company, but curiously enough this particular model, the OM-USBII, wasn’t listed on their site. The packaging itself bears the name Charging Essentials, with a logo that looks like a USB icon that’s had one Viagra too many. The packaging states that the outlet has:

  • “Two 5VDC 2.1A ports for more efficient charging in less time”
  • “Smarter USB charging with special chip designed to recognize and optimize the charging requirements of your device”
  • “Screw-free wall plate snaps into place for a more clean, modern appearance”

The second note is of particular importance to me. If it’s true, that means it might be using some USB charge port controller like TI’s TPS251x-series chips. But I’m not one to have blind faith in what’s written on the packaging. Let’s rip this sucker apart!

The outlet has a snap-on coverplate which may look sleek but could hamper removal of this outlet later on if needed. I was curious as to why one couldn’t just use a regular screw-on coverplate, and it turns out it’s because the mounting flange doesn’t have any tapped screw holes; you physically can’t use screws on this because the manufacturer didn’t want to go to the effort to make holes that can accept screws!

The casing is held together with four triangle-head screws in a weak attempt to prevent opening of the device. I had a security bit set on hand so this posed no hindrance to me. Upon removing the cover, the outlet seems rather well built. However, after removing the main outlet portion to reveal the AC-DC adapter inside, I quickly rescinded that thought.

The converter seems relatively well-built (at least relative to some crap Chinese power supplies out there). Some thought was put into the safe operation of this device, but there’s almost no isolation between the high and low voltage sides, and the DC side of this adapter is not grounded; the “ground” for the USB ports floats at 60 volts AC with respect to the mains earth pin. The Samxon brand caps are also pretty disappointing.

As for the USB portion of this device, I had to remove some hot glue holding the panel in place. After a few minutes of picking away at the rubbery blob, I was able to pull out the USB ports.

… and I found LIES! DIRTY LIES! There is no USB charge port controller, contrary to what the packaging claims. It just uses a set of voltage dividers to emulate the Apple charger standard, which could break compatibility with some smartphones. Ugh, well let’s put it back together and take a look at it from the performance side of things. At least the USB ports feel pretty solid…

To measure the voltage-current characteristic of the outlet, I rebuilt my bq27510-G3 Li-Ion gas gauge board so it had better handling of high current without affecting my current and voltage measurements. The reason I used this is because the gauge combines a voltmeter and ammeter in one chip, and by using the GaugeStudio software, I could create easy, breezy, beautiful V-I graphs.

Using a Re:load 2 constant-current load, I slowly ramped up the load current while logging the voltage and current data to a CSV file for analysis in Excel.

overall vi graphThis charger’s… okay. It has surprisingly good regulation up to 2.3 amps, but after that point the AC-DC converter basically brickwalls and the voltage plummets to 3 volts. That said, this also means that this outlet is not a set of “two 2.1A USB ports”. You can charge one tablet but you won’t be able to charge a tablet along with another device simultaneously.

Bah, I’ve had it with this wall outlet. Looks like this one’s gonna be returned to Costco in the next few days. This outlet may be adequate for some people, but for me it’s a disappointment.

Pros:

  • Solid USB ports
  • Good voltage stability (up to 2.3 amps, enough to charge ONE tablet)
  • Apple device compatibility

Cons:

  • Annoying coverplate design
  • Does not meet rated current output, will not charge 2 tablets or 1 tablet + another device
  • Does NOT have a “smart charging chip” despite being stated on packaging, some devices (eg. BlackBerry) will refuse to charge from these ports
  • Power supply for USB seems cheap
  • USB port is not grounded – if a short-circuit happens inside the power supply it can be a shock hazard to you

A Temporary Hold: Creating Li-Ion battery holders with prototype boards and pin headers

As seen on Hackaday!

Lithium-ion batteries are great. They have high energy density, are lightweight, and in the case of many portable devices, they can be easily swapped in and out. One problem with prismatic (the types you often find on cell phones that have a set of flat contacts on one end of the battery) packs is that they’re all custom; the cell may be standardized but the pack it’s in is often proprietary to a certain make and model. Sure, there are “universal” holders out there, but they provide poor electrical contact at best. Since I need a secure electrical connection when using my battery fuel gauges, I sought to create a more sturdy holder for the batteries I have lying around.

The construction of the holder is pretty simple. A strip of female pin header (I used a single-pin-width header but a double-width one can be used for greater mechanical strength) is used as an end-stop for the battery, and a right-angle pin header is used to create contact with the battery’s terminals and to provide the physical “clamping” needed to create a good connection. The right-angle header can be bent and soldered into place to adjust the holder to the particular cell you’re using. Additionally, be sure to use some high-quality FR4-based boards as the brown-coloured paper/resin-based boards won’t have as good resilience and strength, and probably won’t be plated through either (this improves the structural integrity of the holder since the pin headers will be under a bit of physical stress).

For connections, I have a 2-pin header (physically a 3-pin header with one removed to denote polarity) and a set of screw terminals. These are wired up using a flat ribbon “wire” used to connect solar cells together as they can handle several amps and come pre-tinned with solder.

This sort of setup can be adapted to nearly any commercially available prismatic battery, provided it uses a flat contact area on the sides.

Tearing down and modifying the Mars RPB60 power bank

A while ago I mentioned purchasing a very cheap battery pack that obviously didn’t live up to expectations. However, I didn’t get a chance to write about a more capable power bank, the Mars RPB60. It was branded as a SoundLogic/XT power bank, and holds 4400 mAh of battery capacity, with two USB ports (one labeled for 1 amp and 2.1 amps) and a micro-USB power input.

The power bank

The power bank from the outside looks pretty nondescript, with two USB ports, a micro-USB input, a button and four blue LEDs. Initially it seemed that there wouldn’t be any easy way to open up the casing without damaging it, so I tried to pry away the plastic covers at the ends. Doing so revealed plastic plates held in with small Phillips screws. Disassembly from that point was a cinch.

Removing covers reveals hidden screws

Removing covers reveals hidden screws

The PCB portion of the pack is of a stacked design. The two halves are connected with a set of small pin headers, with one side being the main DC-DC converter and USB output, and the other being the “gas gauge” and charging circuitry. The reason I put the phrase ‘gas gauge’ in quotes is that it’s only going by pure voltage thresholds, making it inaccurate when under load (like charging a phone and tablet, for example).

2014-01-05 00.25.02The main microcontroller is an unmarked 14-pin SOIC (likely an OTP-based PIC clone) and a TP4056 Li-Ion charging IC. The DC-DC converter is a DFN package that I couldn’t find any data on, but from what I can tell it integrates the DC-DC converter control circuitry and the switching MOSFETs.

2014-01-05 00.26.41

Blurry photo of microcontroller/charger PCB, taken with a potato for a camera. 😛

2014-01-05 00.27.16 Cells

The cells themselves seemed to be of good quality, but the bastards at Mars decided to black out the branding and model number of the cells! However, I was unphased at their attempt to cover up what cells they were using. With a careful cleaning with flux remover and some Kimwipes, I found that this pack uses ATL INR18650 cells with a DW01-based protection circuit. These cells hold 2200 mAh each, and the INR prefix means that these are high-power cells intended to provide heavy output currents. This is desirable as a 10 watt load like an iPad would definitely put heavy strain on the batteries. Considering the good cells they used, I don’t understand why they’d want to hide the markings on the cells (and in a half-assed way too!)…

The initial capacity was at about 4800 mAh (greater than the rated capacity 😀 ) with an average ESR of about 63 milliOhms. However, after a dozen charge-discharge cycles, the capacity has decreased to 4630 mAh and has an average internal resistance of 190 milliOhms. I’ve got a feeling charge cycle endurance may be an issue with this battery pack. Time will tell…

Gas gauge hacking

Since this battery pack didn’t have the gas gauge capabilities I wanted (voltage threshold-based gauging isn’t enough!), I decided to put in my own. I built a small bq27541-V200 gauge board with an external thermistor and current-sense resistor, using the breakout board itself to hold all the SMD passive components required for the gauge to function. The thermistor is taped to the cells to get an accurate temperature reading, and the current-sense resistor is attached in series between the cell’s negative terminal and the negative contact of the protection circuit.

Gas gauge chip added

Gas gauge chip added

This is where the hacking happens. I connected the I2C lines to the left USB port’s data lines. The voltage divider used for Apple devices is very high-resistance and makes for good I2C pullup resistors. The device still appears as a normal device charger but works just fine when the I2C signals are hidden behind the USB lines.

Quirks

However, the design for my gauge is definitely not the best one. I noticed that with heavy use (and not even one full discharge cycle), the gauge had reset 4 times without me knowing. Of course, I’m not expecting great performance from this gauge since it’s extremely susceptible to EMI (long wires looping around are just asking for trouble 🙂 ) in its current state. Given how I basically hacked this together in a matter of a few hours, it works well enough. Next up is to go into Altium Designer and make a proper gas gauge board with good EMI and RFI mitigation (and perhaps sell them on Tindie; the hobbyist community needs better gas gauges and stop being so paranoid about Li-Ion batteries).

Further testing showed that certain phones put pulses on the USB lines which has occasionally caused the bq27541 to crash and reset as well.

Additionally, I’ve noticed that the DC-DC converter circuit is quite inefficient. It has 5-7 mA of quiescent current draw and has about 60-80% efficiency. At a full charge, it will take only one month before all the charge is drained from the cells and the protection circuit disconnects the cells.

Future plans

Since this battery pack has a nicely built casing, I intend to gut the battery pack, design new PCBs inside with good DC-DC conversion, an Impedance Track-based fuel gauge, and an onboard microcontroller with some battery-logging capabilities (perhaps to an EEPROM or an SPI Flash ROM), accessible through the micro-USB port. I also plan to use some higher-capacity cells, like the 3400 mAh Panasonic NCR18650B.

If not, then at least I want to replace the microcontroller with one that will read the bq27541’s state of charge readings and display them on the LED bar graph.

Using a laptop battery to power lighter-socket devices

Laptop batteries can be a rather handy source of power, even if it’s not being used in a laptop computer. I built an adapter that converts the knife-blade connector that a laptop battery uses to a car lighter socket.

2013-12-24 02.02.02The connections are made by taking the blades of an ATO or ATC (regular size) car fuse, soldering them to some 16-gauge speaker wire, then soldering the other end to an inexpensive DC lighter socket.

2013-12-24 02.05.39This setup is only good for roughly 5 amps (the overcurrent protection on this battery is set to 6 amps) and the voltage near the end of discharge can be too low for certain devices; power inverters will stop at about 10 to 11 volts which leaves a small amount of battery capacity unused.

Update: How to install Windows x64 drivers for the Schlumberger Reflex USB smart card reader

Update (December 11, 2017): For those on Windows 10, click HERE for the SCR300 driver package – digitally signed to ensure compatibility. Extract the files, right-click the appropriate x86/x64 .INF file and select “Install”. Proceed with the installation as shown below.

A viewer requested help on installing the drivers for the Schlumberger Reflex USB smart card reader, so I’ve created a step-by-step instruction guide on doing so.

1. Plug in the smart card reader into an available USB port. Windows should attempt to install a driver but won’t succeed.

 

2. Open Device Manager, and select the “SLB ReflexUSB SmartCard Reader” in the list.

 

3. Follow the wizard and opt to install the drivers manually.

 

4. Enjoy your now-functional smart card reader.

 

Convenient chips but even more inconvenient packages – Fail, fail, fail and fail again: Trying to solder the TPA2011D1 speaker amplifier

I was doing some prototyping of the TI TPA2011D1 3 watt Class-D amplifier that’s in a 1.2 x 1.2 mm 9-ball BGA package. Unlike my tries with the bq27421, these chips are downright painful to solder. Out of 5 chips that I’ve tried to solder, only one of them actually worked. That’s a 20% success rate. Bummer. The only thing that’s preventing me from being any more angry about these chips is that my back and shoulders hurt quite a bit after hunching over to try and solder these bastards for a good 6 hours.

“Thumbs down!” –Dave Jones

2013-07-25 01.35.11

Making use of a Schlumberger Reflex USB Smart Card Reader in Windows 7 x64

2013-05-08 01.31.41 2013-05-08 01.34.57For a tutorial on how to install the drivers, click here.

A while back a friend of mine gave me an old smart card reader that was of no use to him; he had no need to use smart cards at home and the reader he gave me, a Schlumberger Reflex USB reader, had no support in 64-bit Windows 7, or so it seemed.

I cracked open the reader (didn’t take any effort, there are no screws nor snap-clips holding the case together) and found the internal part number: an SCM Microsystems SCR301 reader. Forcing Windows to use the SCM Microsystems SCR300 driver was successful in getting the reader to show up in Windows, meaning that I had a free, usable smart card reader to tinker around with. Awesome.

scr300 reflex usbUpdate on June 20, 2013: Added a screenshot of the reader in Device Manager.

Making use of an old TI-83 Plus LCD Screen

Since my previous attempts at getting the Motorola smart cards to work were generally fruitless, I decided to revive an old attempt to get a TI-83 Plus LCD screen to work by itself. Earlier tries failed due to mistakes in creating a pinout for the LCD, and at one point I thought I damaged the driver as the chip got very hot.

After completing a recent assignment for my electronics engineering class involving the classic 8-bit parallel HD44780 LCD (and finally understanding the difference between 8080 and 6800-type parallel interfacing), I dug up a datasheet for the LCD and spent about an hour and a half getting it to display content.

2013-03-02 13.17.52

… And it worked! Because this LCD is a graphic LCD, there is no built-in method to display text. For my tests I manually entered the command and graphic data, by hand, using nothing more than a bank of DIP switches and a debounced pushbutton.

The LCD, when first initialized, has complete garbage in the built-in display SRAM. I had to manually enter 0s for all the visible pixels on screen in order to clean up the display, then set the rows and columns manually to print out “Hello world!” on-screen.

The LCD driver is a Toshiba T6K04, which has 128×64 resolution internally but only the left 96 pixels are visible on the screen. It uses an 8-bit 6800-type parallel interface (CE is used for clocking in data) and, depending on the age of the calculator, has all the support circuitry on the same PCB.

Note that newer TI-83 Plus models are built a lot “cheaper” than the older models. The newer ones don’t have a PCB on the back of the LCD screen and all the support components are on the mainboard. I had one that was made around 2004, give or take a couple years. There are older models that use the Toshiba T6A04. I believe the pinout for the older TI-83s using the T6A04 is different, but the command set is the same.

For the ~2004 era of TI-83 Plus calculators, the pinout is as follows:

  1. Reset: Active-low input for resetting the LCD screen.
  2. D0: Input for the 8-bit parallel interface
  3. D1: Input for the 8-bit parallel interface
  4. D2: Input for the 8-bit parallel interface
  5. D3: Input for the 8-bit parallel interface
  6. D4: Input for the 8-bit parallel interface
  7. D5: Input for the 8-bit parallel interface
  8. D6: Input for the 8-bit parallel interface
  9. D7: Input for the 8-bit parallel interface
  10. CE: Active-low clock for the parallel interface
  11. RW: Input for parallel interface read/write mode: High = read, low = write. For most purposes you can leave this tied low.
  12. D/I: Selects whether to send graphic data, or to send a command. High = data, low = command.
  13. STB: Active-low standby input. Typically you would leave this tied high unless you want to put the LCD in a low-power state.
  14. NC: Bare pad that is not connected to anything on the PCB.
  15. NC: Bare pad that is not connected to anything on the PCB.
  16. VCC: Power supply input: 2.7-5.5 volts DC.
  17. GND: Power supply ground.

After a bit of tinkering I’ve created a table of commands to send to the LCD to initialize it.

D/¬I

R/¬W

D7

D6

D5

D4

D3

D2

D1

D0

Action

0

0

0

0

0

0

0

0

0

1

Set 8 bit mode

0

0

0

0

0

0

0

0

1

1

Enable display

0

0

1

1

x

x

x

x

x

x

Set contrast (0bxxxxxx)

0

0

0

0

0

0

0

1

0

1

Sets counter mode: 8 bits along X, each write increases row # by 1

0

0

0

1

c

c

c

c

c

c

Set column (0bcccccc), display driver is 128×64 but left 96 columns are visible

0

0

1

0

r

r

r

r

r

r

Set row (0brrrrrr)

1

0

d

d

d

d

d

d

d

d

Write display data (8 bits wide)

If time permits (and after college midterms are over, etc.) I’ll write up a quick microcontroller program to control the LCD.