GxGDEW075T7 got Image or password failed verification test
zhongshanliyu opened this issue · comments
Per GxGDEW075T8 end of life, I am trying to get GxGDEW075T7 working in wall-ink device.
-
GxGDEW075T7 driver copy from ZinggJM/GxEPD Version 3.0.9 to caedm/GxEPD
-
ESP8266 version2.6.1
-
GxGDEW075T7.h --> #define GxGDEW075T7_PAGES 2
-
stream_screen.ino -->
#define ROTATION = 0 showing below
#define ROTATION = 2 showing below
GxGDEW0583T7 and GxGDEW075T8 running good, so I confirmed server and Adruino setup are correct.
Debug below
`[HTTP] begin...
[HTTP] GET...
Time in milliseconds: 33862
File Size: 48068
remote timeHash:
b42af630fcd9d5c4443fbe9a1f35322f8dad17cc
local timeHash:
b42af630fcd9d5c4443fbe9a1f35322f8dad17cc
Updated currentTime: 1574205505
Updated nextTime: 1574206230
Old imageHash: ffffffffffffffffffffffffffffffffffffffff
New imageHash: d586842c4c32602568bd24c852814b7b855f28c2
Initializing display; time in milliseconds: 33885
Display initialized; time in milliseconds: 34128
state: 5 -> 0 (0)
rm 0
del if0
usl
mode : null
force slp enable,type: 2
fpm open,type:2 0
Calculating SHA1 hash
Time in milliseconds: 36003
local image hash:
18f0581b86ca778b683725ea3e58fc8bc491e5d
local hash with everything:
28ec2aa14d5ea7c6e9fedfb1295fd8bc12e126e
Image or password failed verification test, sleeping
Time in milliseconds: 36035
fpm close 3
force slp enable,type: 2
fpm open,type:2 0
Measuring Voltage...
Time in milliseconds: 36330
Voltage: 2.88
Time in milliseconds: 36331
Image failed verification test
`
update, when I ignore the imageVerified, got half of the screen shows.
that should be cause by GxGDEW075T7.h --> #define GxGDEW075T7_PAGES 2
This project doesn't currently support partial updates. We may choose to support this feature in the future, but for the most part we're just maintaining the features we already have at the moment.
The problem with partial updates is that if you're only updating half the screen at a time, the image verification will only hash half the image and the hashes won't match. I did some quick math though, and it looks like partial updates are our only option for the screen as long as we're using the ESP8266.
I thought about how I would do this, and I came up with something: When the device sends its request to the server, it would include a number that indicates how many pages the image should be split into, and which page is being asked for. The device would need to send multiple requests, which is not a huge deal. There are also some other far fancier solutions we could implement. The real problem is, like I said, we're mostly supporting our existing features right now. We may never get to actually implementing this. In the meantime, if someone else does, we'd probably accept their pull request.
Is gooddisplay going to stop making GxGDEW075T8 displays? Are the physical dimensions of the GxGDEW075T7 at least the same? It would be a pain if we had to design a new case. How fast does the new screen update?
I confirmed from Gooddisplay, and there only 10 inventory of GxGDEW075T8. Gooddisplay as vendor of Waveshare . GxGDEW075T7 physical dimensions same as GxGDEW075T8, with 800x480.
How fast can the new T7 update the display? Does it take about the same amount of time as the old T8, or is it faster? We are concerned about engineering a solution that minimizes battery utilization.
Thanks for looking that up... it looks like it will still be 4 seconds. So this puts us in a difficult situation, as AndersenJ explained earlier. There is not enough RAM on the esp8266 to download the entire 800x480 image to display it. The 640x384 image uses about 32K of RAM to store, and the new image at 800x480 is 48K. The esp8266 only has 80K of RAM, and 40K of it are used with the Espressif SDK for WiFi and TCP/IP functionality. Of the 40K left, the 640x384 image used 32K of it.
Andersen J suggested splitting the image into two 24K chunks to solve this problem, but I'm hoping to perhaps we can figure out a way to have the SDK use less space...
This thread espressif/ESP8266_NONOS_SDK#238 suggests that a user who was facing a similar issue with a different ESP8266 project was able compile his project with 60k of free memory. AndersonJ and I will have to look this over and see if this is even possible and get back to you.
Unfortunately, this solution is unlikely to work for us.
yeah, let close it then. thank you.
Thanks for reporting this, it's really good for us to know about this.