Hardware Waveform file decoding: how much do we know?

mark03 · 11-28-2018, 05:27 PM

Background: I'm a EE with embedded-systems experience, playing with E-ink. I'd like to use one of the newer EPD panels (E-ink Carta, preferably) in a project, without Linux, using a microcontroller and maybe an FPGA. I'm familiar with some of the previous published work along these lines (mainly http://essentialscrap.com/eink/).

It's clear from the earlier work that you can conjure up your own waveforms for simple black-and-white experiments without too much hassle. Grayscale and partial updates, on the other hand, probably require the vendor's waveforms. I don't see any reason to believe that these waveforms are "magic" either---meaning, I suspect that a reasonably competent engineer "skilled in the art" (to borrow the patent-office phrase) and provided with some basic support, could design good ones from scratch. But to do that, he/she would need a simulation model of the display pixel's behavior in something like MATLAB, for running experiments and performing optimization. And the chance of obtaining *that* is pretty much zero, so hey, maybe we should just figure out how to decode the d**n waveform file...

I realize this is quite a different goal from most of the dev work here. I.e. I don't want to convert from one file to another, or patch a file to work with a different display. I just want to extract waveforms from available data (a .wbf file probably), so that i can use those waveforms in my own driver.

I found the "inkwave" program here: https://github.com/fread-ink/inkwave
This is part of the fread project, which I believe is based here at mobileread? The inkwave source code is quite helpful, but the aim there was to convert wbf into wrf and I just need to understand what the waveform data actually mean. Is this known at all?

Thanks,
Mark

NiLuJe · 11-29-2018, 11:48 AM

I don't recall ever hearing from the fread guy directly here, but I think he does mention MR in some of his material

.

AFAICT, his is the only project that went as far as this on the subject (and, err, possibly the only project, period

).

mark03 · 12-02-2018, 02:20 PM

Since posting this I have discovered a .wbf file dump utility:

https://github.com/julbouln/ice40_ei...utils/wbf_dump

This guy implemented a basic EPD controller in an FPGA and was apparently able to extract waveforms from the file. I tried it on one of my wbf files and it prints a bunch of waveforms then segfaults, so obviously a work in progress. I haven't had time to dig much deeper though.

One question I have is what makes the "regal" technology different from the older "direct update" (non-flashing) waveforms? Is regal merely a more-refined version, calibrated at different temperatures, etc.? Or is there some qualitative difference between the two, like storing the history of a pixel and using that to dynamically alter the waveform?

11-28-2018, 05:27 PM	#1
mark03 Enthusiast Posts: 30 Karma: 10 Join Date: Jun 2011 Device: Kindle 3 wifi	Waveform file decoding: how much do we know? Background: I'm a EE with embedded-systems experience, playing with E-ink. I'd like to use one of the newer EPD panels (E-ink Carta, preferably) in a project, without Linux, using a microcontroller and maybe an FPGA. I'm familiar with some of the previous published work along these lines (mainly http://essentialscrap.com/eink/). It's clear from the earlier work that you can conjure up your own waveforms for simple black-and-white experiments without too much hassle. Grayscale and partial updates, on the other hand, probably require the vendor's waveforms. I don't see any reason to believe that these waveforms are "magic" either---meaning, I suspect that a reasonably competent engineer "skilled in the art" (to borrow the patent-office phrase) and provided with some basic support, could design good ones from scratch. But to do that, he/she would need a simulation model of the display pixel's behavior in something like MATLAB, for running experiments and performing optimization. And the chance of obtaining that is pretty much zero, so hey, maybe we should just figure out how to decode the d**n waveform file... I realize this is quite a different goal from most of the dev work here. I.e. I don't want to convert from one file to another, or patch a file to work with a different display. I just want to extract waveforms from available data (a .wbf file probably), so that i can use those waveforms in my own driver. I found the "inkwave" program here: https://github.com/fread-ink/inkwave This is part of the fread project, which I believe is based here at mobileread? The inkwave source code is quite helpful, but the aim there was to convert wbf into wrf and I just need to understand what the waveform data actually mean. Is this known at all? Thanks, Mark

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
waveform issues.. help?	readingforfun	Amazon Kindle	4	10-11-2016 01:15 PM
Waveform fs (request)	mmatej	Kindle Developer's Corner	0	06-28-2013 02:09 PM
CHM decoding.	lippy	Calibre	3	07-18-2010 02:16 AM
Announcing Decoding the Kindle	KindleDecoder	Amazon Kindle	4	10-28-2008 06:35 PM

11-29-2018, 11:48 AM	#2
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	I don't recall ever hearing from the fread guy directly here, but I think he does mention MR in some of his material . AFAICT, his is the only project that went as far as this on the subject (and, err, possibly the only project, period ).

12-02-2018, 02:20 PM	#3
mark03 Enthusiast Posts: 30 Karma: 10 Join Date: Jun 2011 Device: Kindle 3 wifi	Since posting this I have discovered a .wbf file dump utility: https://github.com/julbouln/ice40_ei...utils/wbf_dump This guy implemented a basic EPD controller in an FPGA and was apparently able to extract waveforms from the file. I tried it on one of my wbf files and it prints a bunch of waveforms then segfaults, so obviously a work in progress. I haven't had time to dig much deeper though. One question I have is what makes the "regal" technology different from the older "direct update" (non-flashing) waveforms? Is regal merely a more-refined version, calibrated at different temperatures, etc.? Or is there some qualitative difference between the two, like storing the history of a pixel and using that to dynamically alter the waveform?