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
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