I have the 7.3” E6 epaper panel that claims 12s refresh rate in all marketing/spec sheets. However I’m consistently getting >20s. Has anyone actually managed to get close to the claimed refresh rate?
I’ve tried multiple example code from Waveshare and Good-Display (supposedly identical panels).
There is an example init sequence that is commented as “fast”, but yields identical behaviour for me.
Just curious what refresh times other people are seeing.
1 Like
Hi @rpdb and welcome to the forums, glad to have you here.
I’m frankly quite sceptical of that 12s refresh time for a full colour display that big. If they recorded a time of 12s they were probably using a very simple image for the refresh, possibly just a black and white image.
I know from other colour epaper screens that disabling colour tends to speed up the refresh rate. What happens if you refresh with a black and white image?
1 Like
I’ve done some more digging and testing; documenting here in case anyone else has the same issue.
It seems the 12s that is posted everywhere (including on Core Electronics page) is a completely theoretical minimum, needing perfect conditions and possibly even a custom waveform LUT.
It’s also possible earlier panels had a faster waveform baked in, and subsequent panels were changed to be slower (higher quality?)
The creator of the GxEPD2 library seems to have a fast panel, although that was ~1 year ago, and was a panel donated by Waveshare directly.
(that lib uses the same init sequence as some “official” examples)
I had got a value of 12468000us [for the BUSY pin] when I created the driver class.
This page has the most realistic specs I’ve seen. Other pages from Good-Display referencing the exact same model still quote 12s however.
Full Refresh Time(s) 15~22
The Inky Impression uses the same panel, and while they also quote 12s they have a footnote:
A complete ‘real world’ refresh cycle is likely to take around 20-25 seconds.
These numbers match my experience of ~19-20s, regardless of color or init code. To clarify, I am measuring just the refresh itself, from sending the final SPI DRF command until the BUSY pin goes high. The prior SPI comms to send the actual image data will take ~1s longer, depending on your setup. I’m still interested to hear what numbers other people are getting.
Perhaps Core Electronics would consider updating their listing with these more realistic/real-world times, or at least footnote them.
1 Like
try and use simpler images with fewer color transitions and gray levels to reduce the refresh time. This can be particularly useful for dynamic content or animations.
Can you clarify what you mean? I’m struggling to understand how that applies to these panels specifically.
Complex images with any kind of transitions will take longer to process (on the panel), this will apply to most boards 
Understanding E-Paper Refresh Times: Text vs. Images
E-paper displays, particularly those using electrophoretic technology (E Ink), are known for their high contrast, low power consumption, and ease of reading in bright sunlight. However, refresh times for text and images can vary significantly.
E-Paper Technology: Electrophoretic Displays (E Ink)
E Ink displays use microcapsules filled with positively charged white particles and negatively charged black particles. Applying an electric field moves these particles to create black or white pixels. This technology allows for a high-contrast, low-power display.
Text Rendering
Text is usually rendered in black and white or grayscale, simplifying the refresh process. The display only needs to move the black and white particles to create characters. The high contrast makes text easy to read quickly. E Ink displays can perform partial updates, refreshing only the changed portions of the screen, which is efficient for text.
Image Rendering
Complex images, such as photographs or detailed graphics, include a wide range of colors and gradients. E Ink displays struggle with these elements due to their black-and-white or grayscale nature. High-resolution images require more data processing and pixel updates, slowing down the refresh time. Dithering is used to simulate colors and gradients, but this process is more complex and time-consuming. Complex images often require full screen updates, further slowing the refresh time.
Technical Challenges
The movement of particles within the microcapsules is relatively slow, affecting the refresh time for complex images. Precise control over the electric field is required for accurate particle movement. E Ink displays prioritize power efficiency, which can result in slower refresh times for complex images. The bistable nature of E Ink means that updating images requires more energy and time.
Conclusion
Text refreshes quickly due to the simplicity of black-and-white content and high contrast. Complex images require more precise control over particle movement, dithering, and full screen updates, which can slow down the refresh process. Understanding these mechanisms is crucial for optimizing e-paper applications.
Optimization Techniques
To improve the display of complex images on e-paper:
-
Use dithering to simulate colors and gradients.
-
Utilize partial updates to refresh only changed portions of the screen.
-
Pre-process images to simplify content or reduce complexity.
Hi @rpdb ,
Thanks for diving into this! I have left a note for our team to update the product pages to better reflect that the quoted refresh times are theoretical numbers and not accurate to real-world conditions.
All the best with your future projects!
1 Like
