iiinova — where your digital self keeps evolving

In that kind of case, the screen itself doesn't consume power, but the controller still need to work constantly, checking if anything has changed from the video input (pulling out the previous frame from DDR, 60 times a second, just to confirm nothing is moving), so it's still rather power intense

Generally speaking, it's comparable: this portable monitor consumes ~4W in low power mode, and ~7W in standard mode. Similar sized regular LCD displays also consume between 3-10W depending on the backlight brightness

It's an FPGA driving the screen. STM32 is just there doing other stuff (like power management, initializing peripherals, running USB and USB PD protocol stack etc.)

030

Well yes, the caveats would be power consumption. Contrary to common belief, Eink is actually rather power hungry. When used inside an e-reader, because it only consumes power during page turns, the average power consumption can be really low. This is no longer true when you are playing video on it.

1170

I am currently running the crowdfunding campaign for it: www.crowdsupply.com/modos-tech/m... It's not cheap unfortunately, I am already working with rather thin margin

130

It's a monitor that you will need to plug into a laptop (or a phone), unlike trmnl which is a standalone device. Though it does have a somewhat powerful CPU inside (like Raspberry Pi 2 level) so you could hack it to run standalone

ALSO you just need a screwdriver to take it apart. It's not glued down. This is how it looks like without the chassis: (this is a prototype, production units won’t have bodge wires). I have also added a MicroSD card slot and through-hole JTAG connector onto the board, to make it more hacker-friendly

19414

It is pretty good for eink. I even made a frame rate limiter option in the OSD, to limit it down to 15Hz in case it no longer feels like eink

3340

It's just a touch screen monitor, you will need to connect to your PC (or phone I guess). Though it does have a dual core Cortex-A9 processor, so you can hack it to run Linux if you want

1130

It's constant 60Hz. But sub-100ms is talking about latency not throughput. So while it's presenting 60 images per second, the image would take a while before it's displayed on the screen. 100ms is really the worst case measurement, image generally starts become visible within 20ms

1250

Wenting @wenting.bsky.social · 15/06/2025

Sorry for not posting for so long... I have been extremely busy working on my new project: The Enchanter (also called Modos Flow): a 300-ppi Eink portable monitor with 60Hz refresh rate and touch screen. It's fully open-source: gitlab.com/zephray/ench....

19564137

Does anyone know anything about this? It says its "Apple iPort", "Designed by HWTE in Shanghai", featuring a Micro USB port, 2 USB-C ports, and a 4.2" Eink screen. It doesn't function properly as a USB-C cable tester between its 2 ports, and I have no other idea on how to use it.

8384

So at least on this level, due to the lack of the TFT, the LPD could potentially be much cheaper than the Eink. This is my adventure with the screen so far. Still not sure what I want to do with the screen, let me know if you have any ideas. In any case, thanks for reading!

1160

Eink is much slower, typically requiring 100ms+ for it to fully change color. The presence of TFT (+capacitor) ensures the pixel keeps getting driven even when the line is not currently being scanned. If without, a 320x240 panel would take 0.1*240=24 seconds to update!

160

Another characteristic making it possible to drive without TFT is it's fast. As fast as 0.2ms from black to white. Without TFT, the pixel is only driven when the line is scanned. With a 0.2ms line time, a 320x240 panel takes a quite reasonable 0.2*240=48 ms to update

According to the paper, the LPD screen shouldn't respond to the 40V voltage. (Though based on my tests it still does. The threshold is more like 20V rather than 40V). But the important thing is it could withstand non-zero OFF voltage. Eink starts to respond at even 0.1V.

Taking the driving waveform from the paper, up to +/-40V are applied to non-selected pixels (pixels that shouldn't change color during the scan). This is what happens when the screen doesn't have TFT: pixels cannot be fully turned OFF, there is always a voltage on the pixel.

But TFTs are expensive. The cost is okay for mass-produced screens (like >10K pcs per month), but prohibitive for smaller quantities. This is where LPD shines, it doesn't require TFT because it has a threshold: it doesn't respond to low voltages.

160

I realized I forgot to mention the advantage it has over Eink: it doesn't require TFT. TFT screens add tiny transistors under each pixel, so they can be switched ON/ OFF in a matrix without having to worry about issues like ON/ OFF voltage ratio like what I just discussed.

But it seems to be almost impossible for me to get a Pricer ESL from that era, or see any of those LPD demo machines (linked below) IRL. So maybe I will never know. www.youtube.com/watch?v=MDvO...

This is basically what I have got with this screen so far. If possible I would still love to see how the screen should look like. I am not confident about if the poor contrast is due to the age of the screen, my bad code, wrong voltage, or combination of these things.

190

Turns out this is a very effective measure for improving the contrast. Left is with 60V/30V, while the right is with 48V/32V/16V:

1141

What I ended up realizing is, there is no requirement that I have to provide two STV7733 with the same voltage. By giving the H/V different voltages (specifically 60V/40V/20V), the voltage on the non-selected pixels are reduced to 20V while keeping the 60V for selected pixels.

150

I can reduce the voltage to say, 60V/30V, this reduces the non-selected pixel voltage down to 30V, but also reduces the selected pixel voltage down to 60V. There are some limited improvements by doing so.

Unless there is a way to improve the contrast... The main reason for the contrast loss is the from the non-selected voltage I mentioned previously: Pixels that shouldn't be driven are still subject to a 40V voltage difference. This is more than enough to get the pixels moving

The paper mentioned it's possible to do greyscale on the screen, so I tried that as well. It works by not driving the pixel all the way. I tried only up to 8 levels of greyscale. I think higher is possible, but with the poor contrast, it won't make too much of a difference.

1152

And this is how it looks after some trial and error:

1140

Another thing to know is that, according to the paper, it's also better to use a bunch of short pulses instead of a single long pulse.

This means other than the selected line, we also need to consider pixels on the none selected line. In this scheme, still assuming the 80V and 40V driving voltage, the selected pixel would see a 80V voltage, while the non-selected pixel would still see a 40V voltage.

160

The paper comes to the rescue again, it provides a basic driving scheme. Just like on an LED matrix, only one line is selected at a time, and the segments are set based on the pixel of that line. Unlike LED, the LPD responds to both positive and negative voltage

On to the software. The STV7733 used on this screen is essentially a giant high voltage shift register. It does nothing other than outputting a lot of specified voltages. So driving it actually requires synthesizing the driving waveform by the MCU.

With the pinout I can finally design the board. Here is what I got. It has got 2 boost converters to generate the 40V and 80V needed for driving the screen (at least the paper says these two voltages), and a RP2040 for generate all the timings.

So what I did is I did an overlay of the bump map in the datasheet on top of the packaged COF. In this way I can deduce the pinout of the COF:

1121

Even better, ST still has the datasheet publicly available on their website. The bad part is, the datasheet is for the gold bumped chip only, not the COF. So I still don't know the pinout of the COF on the screen.

To drive the screen, I will need to know the pinout of the thing. Luckily, COF chips usually have their model number marked on them somewhere. This one is of no exception:

Linking DotMatrix Labels in Supermarket

Back to the screen I got, I have some clue about its original use: electronic shelf labels (ESL). Specifically, I suspect it was used on the Pricer DotMatrix(TM) ESLs from around 2008. Here is a video showing the thing, though I am not super confident. www.youtube.com/watch?v=6JNO...

youtube.com

YouTube video by PricerAB

190

The charged powder with different colors can be sealed into small grids (pixels), and then drove by electric field. Quite similar to Eink. One major difference is that the Eink only works with TFT while this one doesn't quite need TFT.

It's based one a new material, which they call it the liquid powder. It's a powder but acts like liquid. In their paper, they showed pouring the powder onto a table. The ordinary powder piled up, while their liquid powder doesn't (which is more like liquid than powder)

1141

After a tons of searching online, I learned this neither LCD nor Eink, it's called the Liquid Powder Display (LPD). It was a display technology co developed by Kyushu University and Bridgestone (yes, that tire company).

1170

I bought it thinking it's probably just another weird LCD. But when I got it, I immediately knew this has to be something else. It reflects light diffusely like Eink or paper (unlike LCD which is more like specular reflection). It also has a special grainy looking to it:

But upon closer inspection, this simply couldn't be a memory LCD (which has TFT). It has 2 COF (chip-on-flex) driver ICs bonded to 2 sides of the screen (upper and lower glass panel). Likely one for X scanning and the other for Y, on two glasses. TFT screens have both scan lines on the same glass.

190

At first glance, it looks quite similar to SHARP memory LCDs (or other reflective TFT LCDs, which uses internal metal layer for reflection):