How my e-reader lost its stripes

I’ve been a lifelong reader, which has proved a fragile habit in our era of endless trivial
distraction. While books and e-ink readers solve the problem of competition for attention, they
can’t compete with a phone for convenience. That tiny device in my pocket has made reading both
easier and more vulnerable to displacement whenever a notification pops up.

A few days ago, I learned for the first time about a recent generation of tiny e-ink readers.
Since they’re cheap, it was easy to give into curiosity: I bought an Xteink
X3. Not only is it astonishingly tiny, I could immediately
install the delightful open-source
CrossPoint firmware. I was very
quickly able to install a few books. I also appreciated being able to install custom fonts,
though I was a little surprised by their indifferent rendering (foreshadowing…).

CrossPoint is very configurable out of the box, so I converted a photo to a dithered black and
white bitmap as my “device sleep” screen, and was pleased with how pretty this looked. When I
read that the device supported 4 whole shades of grey, I was intrigued: would a greyscale image
look better?

Down the rabbit hole: first image bugs#

This revealed what looked like a bug: the sleep screen was displaying greyscale images with very
murky dark areas. Either my middle-aged eyes were finally failing me, or was dark grey rendering
as black? I created a quick test image and verified that dark grey really was black, while
light grey was extremely pale (almost white). Mildly annoying, but hardly unexpected on a
cheap device, and easily worked around: let’s create a three-tone image!

With less of the regenerated image containing large regions of black, I now saw a new bug: in
the CrossPoint viewer app, the prior screen contents were still present in ghostly form (only on
paler parts of the display, hence me failing to notice the first time around). However, on the
same image, the sleep screen didn’t suffer from this problem. This suggested that there were
two image renderers making different decisions, and the viewer app’s code was buggy.

In both cases, though, the photograph had distinctive vertical stripes across it that were not
present in the bitmap file.

Since I knew next to nothing about e-ink, ESP32 development, or CrossPoint, I started
investigating in the usual late-2026 way, using GPT-6 Astra in Codex. I would capture the X3’s
screen on my phone and drop images into my Codex session.

An e-ink screen uses voltage pulses to move black and white pigment particles, which stay in
place after the power is removed. An incomplete update or insufficient voltage can leave ghosted
traces of the prior image behind.

To display a greyscale image, CrossPoint first draws a black-and-white base in which even the
grey pixels start out black. It then runs a short voltage-pulse waveform to move selected pixels
partway towards white. This second stage, a “nudge,” produces dark and light shades of grey by
driving those pixels for different amounts of time.

Astra found that the viewer did a fast black-and-white update and simply stopped, without ever
performing the grey nudge. It quickly fixed the problem.

The stripes proved much more stubborn. Astra initially flailed, blaming the Floyd–Steinberg
dithering it had used to prepare my sleep picture. A different algorithm made no difference. It
then followed a lead down the stack, and flagged the nudge waveform as worth investigating.

But we were struggling to agree on what artifact we were even looking at or measuring, which
concerned me; I didn’t want to burn state-of-the-art tokens chasing phantoms. When I pushed,
Astra dug in and reported a stripe pattern two pixels wide. That didn’t make any sense to me, so
I asked it to annotate the photograph, and found that it had picked out fine dither texture
instead of the bands I could see across the image.

What Astra’s FFT found

Using a fast Fourier transform (FFT) here was quite clever: it’s an almost ideal tool to pick
out and quantify repeating patterns that are hard to measure by eye. Astra applied a
two-dimensional FFT to small patches of the photograph and the source image, and found a strong
repeat at roughly two screen pixels in both.

Unfortunately, error-diffusion dithering produces structure of its own, by its nature often
high-frequency noise that creates a strong signal in an FFT. Astra had picked out the fine dot
pattern of Floyd–Steinberg, the very algorithm it had chosen to prepare the image and blamed
early in the investigation. The broader bands I was complaining about appeared only on the
reader. When I challenged its estimate, it made this annotation, which confirmed that we were
looking at different patterns.

Making the stripes measurable#

Slightly frazzled by Astra’s hypotheses that were going nowhere, I switched to Fable 5.1 in
Claude Code for another perspective.

I had a hunch that the width of the stripes meant something, but even identifying the stripes
had eluded Astra. And this isn’t easy, as a lot of sources introduce patterns and noise:

• The image’s own dither pattern that had tripped up Astra
• Whatever was introducing the stripes
• The X3 screen’s own physical characteristics
• A handheld phone photo of this mess:
  • Sensor noise
  • Variable focus within an image
  • Lens distortion (these have to be macro shots to capture the 259ppi screen)
  • Lighting and exposure variations, processing artifacts
  • Motion blur from my shaky hands

Warned away from Astra’s naive image processing dead end, Fable wrote code to average the
brightness down each column. For the view below, it used a sliding window 200 rows tall: each
point became the average of a short vertical strip around it. This averaged away the dither
texture, while a brightness difference that persisted down a column would survive. Broad shapes
in the picture remained, but the stripes became much easier to see:

Fable now used an FFT on a one-dimensional brightness profile to measure the spacing and
strength of the vertical pattern. Its first guesstimate put the stripes roughly seven screen
pixels apart, but this was based on a guess of my photograph’s scale.

It returned its attention to dithering, this time inside the firmware, proposing that repeated
rounding errors could line up to produce the vertical bands. When I mentioned that my source
image was already dithered, it became more excited, but this ended up being a 20-minute false
lead. Another investigation involved Fable getting worked up over the bit depth of an image, but
this too led nowhere. At least it was being more novel in its investigations than Astra?

What was different about grey?#

I had also been investigating much simpler images on the device. Removing either the grey or the
pattern made the stripes disappear:

The specific combination of grey pixels with neighbours of a different shade was what caused
trouble. Fable matched small blocks of the source image to the phone photograph, which finally
allowed it to see that light-grey pixels carried the stripe, an important detail that hadn’t
even been clear to me due to the very pale tone of light-grey pixels.

This evidence now pointed towards how the screen produced grey, via the greyscale nudge. The
code for this lives in freeink-sdk, the hardware
library CrossPoint uses.

Fable was initially reluctant to go further: “I cannot design or validate a LUT change from
here.” A LUT is the lookup table holding the nudge waveform. When I pointed out that the X3 was
on my desk, and I could photograph whatever a new build displayed, it came back with experiments
we could run.

The X3’s odd choice of a magnetic contact charger worked in our favour here. Fable could flash
and reboot the device over USB while it was plugged in. I could then pick the device up to
photograph the screen and put it back down without ever needing to fiddle with a USB-C
connector.

A test pattern, and a second bug#

The existing nudge lasted seven scan cycles: each time, the controller worked through the
panel’s rows, applying the next step of the voltage sequence to each pixel. We still thought the
stripe spacing was about seven pixels. Could the timing be showing up as a spatial pattern?
Changing the waveform’s duration would give us something to compare.

First we needed a better image to measure, so I suggested to Fable that it should generate a
test image. It created a pattern with flat patches at all four shades, mixtures of grey with
black or white, a checkerboard, and lines running in both directions.

The test image made progress dramatically easier. Fable knew how the image should look, so
variations in my photos and the screen’s appearance became possible to see and account for. For
example, Fable’s original scale estimate had mistaken a feature in the photograph’s spectrum for
the screen’s pixel grid. With the test pattern as a ruler, the stripe period turned out to be
eight pixels, rather than seven.

I supplied raw DNG files from my phone as well as processed photographs. Comparing the two
showed that the phone’s processing exaggerated the stripe amplitude by about 70 percent and
shifted the apparent grey levels. We used raw files after that. Fable worked out how to locate
the test patches despite changes in framing, perspective, and lens distortion, so it could
measure each build and photo in the same way.

We tried stretching the nudge from seven frames to ten, then a version that interleaved drive
pulses with rests. Neither affected the stripes. This ruled out the proposed connection between
the frame count and the stripe period.

Three, then four, shades of grey#

The test pattern also brought back a problem we’d worked around earlier.

Our supposedly four-shade reader was definitely displaying three shades; this wasn’t just my
aging eyes. Dark grey was black. I was lucky enough to be watching Fable doing its thinking when
it found this, because it only reported this as an offhand drive-by comment. Understanding the
significance of its finding, I had to jump in, stop it, and get it to dig in deeper.

Fable traced this to a disagreement between CrossPoint and the driver about how to request dark
grey. CrossPoint sends two bits per pixel for the nudge, selecting one of four waveform tables.
Its code for dark grey selected a table that did nothing. The intended dark-grey drive was
sitting in a different table. Fable fixed the mistake and issued a PR against freeink-sdk.

With that fixed, dark grey appeared, and the patch that should have been dark grey dithered on
black became a visible speckle instead of a solid black square. But the light-grey drive hadn’t
changed, and neither had the stripes. We had opportunistically fixed another bug while building
the test for the first one.

The missing shade had also been making text look rough (remember that mention of indifferent
text rendering?). CrossPoint anti-aliases its text, so pixels intended to soften the edges with
dark grey had been coming out black, yielding chonky text. Restoring that shade improved text
throughout the reader.

A slower way to draw a picture#

The driver contained another waveform we hadn’t tried: the manufacturer’s four-grey image
mode, called XTH4. It used a much longer sequence of pulses to produce the four shades, taking
roughly a second to refresh. That would be an annoying delay on every page turn, but seemed
reasonable for opening a picture or drawing the sleep screen.

The table was already in freeink-sdk, and another reader’s driver used a version of it for
images. We could simply try it on the X3 without inventing a waveform from scratch. Fable was
not at all sure this would achieve anything, but I urged it to forge ahead.

There was a memory problem to solve first. The nudge only needs to distinguish dark grey,
light grey, and “leave this pixel alone”. Black and white can share that last instruction
because the first pass has already drawn them. The longer waveform needs separate
instructions for all four shades.

The other reader’s driver solved this by keeping a copy of the black-and-white image in RAM and
combining it with the grey data. My X3 uses an ESP32-C3 with about 380 kilobytes of RAM, and its
largest free block was only 53 kilobytes. At 528 by 792 pixels, even a one-bit copy of the
screen would consume 52 kilobytes. There wouldn’t be room to casually add another buffer.

Fable proposed having CrossPoint draw the data in the required format to begin with. The image
viewer already decoded the file once for each rendering pass; those passes could produce two
bits per pixel that identified all four shades. The driver would receive what it needed without
another screenful of data.

With this all implemented and flashed, I opened the image that had kicked off the investigation,
and told Fable: “The stripes ARE NO LONGER visible in my original why are there stripes?
image.”

The measurements agreed. The column variation dropped from roughly four percent of the
black-to-white range to one percent. The peak at eight pixels disappeared entirely from the
frequency spectrum.

The longer waveform also had the happy side effect of improving the shades themselves.
Restoring dark grey had given us four levels; this also pulled light grey further from white
(remember my comments about it being very pale?). Dark grey is a bit darker than I’d like, so
there’s still some tuning to do.

Do we get closure?#

So this is a half-satisfying investigation: replacing the code fixed the problem, but do we
really know why it occurred in the first place? Not quite.

Here is my best guess, based on my newly acquired and still very limited knowledge of
electrophoretic displays. The rows of an e-ink panel are switched by a gate driver etched into
the glass. A handful of interleaved clocks drive the gates, each opening every nth row for a
slightly different interval of time. A particle being driven hard to black or white is
insensitive to timing variation. A pixel nudged partway to grey over three frames gets only the
charge its row’s time window allows, so every eighth row comes out a little lighter or darker.

When a column is charged, this happens one row at a time, and its voltage only has to move when
consecutive rows are different shades. If a grey pixel follows a black one, that voltage swing
has to complete inside our brief and variable time window. A flat grey field never swings, while
a black-and-white swings, but the optical response saturates, so timing doesn’t matter so much.
Only when we have a grey dither do we see a swing and sensitivity to timing, and that’s when
we get our stripes.

Do I know that this is true? No, but it fits the electrical architecture and the evidence I
have. I could have pursued this further, but I was relieved to have non-stripy imagery.

A happy pixelated ending#

The driver change became freeink-sdk#95. Both
of my freeink-sdk pull requests were merged within hours. I submitted a couple of CrossPoint PRs
too. Amusingly, someone else gazumped me there, by merging an almost identical set of changes
right before mine got reviewed.

I find the timescale of all this a little ridiculous. A few hours after unboxing my first e-ink
device, I was testing fixes to its display waveforms. Astra and Fable handled unfamiliar code,
build tools, and measurement scripts, while I could concentrate on what the experiments ought
to do, provide major hints like use of FFTs and test patterns, quibble and steer around
investigative dead ends, and share what the screen actually showed.

This experience of being able to jump into the unknown and immediately make progress was quite
exciting. Even though I didn’t know much about e-ink, CrossPoint, or ESP32 in the beginning, I
learned a lot within hours. It’s definitely whetted my appetite for more of this sort of
low-level device hacking.