No image downloaded to tag if new image is available

[Teddyz]

Preconditions:
Using demo_firmware_2.9_33_V1.9.0.0.bin and epaper-station.

Problem:
When I upload new images to epaper-station faster than the rate the tag is checking in, I never get new images to download.
Instead epaper-station prepares a new image and notifies the tag with the new imgUpdateVer.

Sometimes the tag checks in after a few seconds and no new image-file is available, but still no download. Only after a full (in my case) 5 minute delay with no new image, then the tag updates and new image is shown.

So, even if I upload only one image I still have to wait the CHECKIN_DELAY until a image is downloaded

Is this known? Should it be fixed in the epaper-station or in the tag? How?

[atc1441]

Hey,

this sounds like your Station takes too long to convert the image and when its ready the Display is already sleeping again as it has timed out.
On a "tower" pc i do not have this problem but heard from people having it when using a PI etc.

You could try to feed the Station .bmp files instead of .png if you dont do this already.

Otherwise it is already on the todo list to actively prepare the images by monitoring the available images and pre converting them.

[Teddyz]

no_update_log.zip
I used png, but I face the same problem using bmp.
The attached zip has my changed version of epaper-station with less but more informative printing.
I run epaper-station on my old Asus router, so I guess performance is even less than on an RPI.

Below is a more recent output with 10 checkpoints in bmp2grays.py. Is there any optimization possible in there?

`2023-01-28 15:44:30,926 0000021bd0f23b11 > Got checkin request
2023-01-28 15:44:30,927 0000021bd0f23b11 > CheckinInfo(swVer=1181116006400, hwType=8, batteryMv=2600, lastPacketLQI=0, lastPacketRSSI=0, temperature=148, rfu=b'\x00\x00\x00\x00\x00\x00')
2023-01-28 15:44:30,929 0
2023-01-28 15:44:30,931 1
2023-01-28 15:44:30,932 2
2023-01-28 15:44:30,933 3
2023-01-28 15:44:30,933 4
2023-01-28 15:44:30,934 5
2023-01-28 15:44:30,935 6
2023-01-28 15:44:30,936 7
2023-01-28 15:44:30,937 8
2023-01-28 15:44:30,938 9
2023-01-28 15:44:38,482 10
2023-01-28 15:44:38,486 bmp2grays.py made ./tmp/0000021BD0F23B11_7193729378165277377.bmp

[atc1441]

As mentioned:
Otherwise it is already on the todo list to actively prepare the images by monitoring the available images and pre converting them.

[christescu]

bmp2grays.py is very, very slow. For me, it takes about 24s on RPI for converting a 640 x 384 24 bit bmp.
The C version from Dmitry takes 150ms.
So I compiled bmp2grays.c and replaced bmp2grays.convertImage() calls with os.system('./bmp2grays -D "1bppR" < '+ filename + ' > ' + file_conv).
Now it function far, far better on RPI.
But it does not work on Windows, compiled with MinGW, I get BITMAP HEADER INVALID.

[atc1441]

Hey,

Thats is what i also could observe, the problem is that windows reads the bytes in another endian mode so everything(4byte blocks) is reversed, so instead of fixing the bmp2grays i ported it to python without looking out for any speed issues.