Overlay clock - Wrong time display on startup

andyyngo commented 5 months ago

When the overlay clock starts from cold state, it picks up and displays the cached value. Only after the first refresh, the correct time show.

Example:

Start-up shows: 10:17 Real time ~10:48
After one minute (refresh period): 10:49 Real time ~10:49
After few mins, restart the Pi, the time now show: 10:17 again
After one minute 10:51 Real time ~10:51

mariusandra commented 5 months ago

Is this time that you see on the screenshot in the interface, or time you see on the actual display? Hard to help without knowing any more details about your setup.

andyyngo commented 5 months ago

This is from actual display. This bug got nothing to do with the FrameOS controller. Just the nim code deployed to the Pi

mariusandra commented 5 months ago

What screen are you using? What does your FrameOS scene look like? What logs do you get during bootup?

andyyngo commented 5 months ago

Screen: Waveshare 7.5" 800x480 Hardware: Raspberri Pi 4 Scene Screenshot 2024-01-09 at 4 53 04 PM

Sequence of events: Startup 1_startup

Refresh 2_refresh

Restart 3_restart

Refresh 4_refresh

mariusandra commented 5 months ago

Thank you!

This is very weird behaviour. FrameOS only caches things in memory, so it's very weird to see the display or the frame remember the image. This might be due to some mistake on in the initialization sequence, but I'm not sure.

Which driver are you using?

I might have exactly the same display, so I'll run some more tests to see if I can replicate this. This might be tomorrow though.

andyyngo commented 5 months ago

Driver info: waveshare.epd7in5_V2 800x480 black

andyyngo commented 5 months ago

Extra information: The initial stucked screen always ending with xx:17 So far I see: 10:17, 11:17 and the latest one is 17:17

mariusandra commented 5 months ago

I just booted up my waveshare frame with the same driver and it's working quite well. I'll be monitoring it for a while, but so far shows every minute (refresh interval 60 seconds).

2024-01-11 01 29 13

However to get it to work I had to revert one change I had done a few days ago to the waveshare drivers. Perhaps something there also fixes your situation, I'm not sure.

It might be worth upgrading to the latest version just in case to see.

andyyngo commented 5 months ago

I use watchtower, the frameOS image was updated 2hrs ago.

With the same setup above, made a small change in time format. The problem is still there. So the display always shows 17 in the minute section xx:17:xx when startup, then the first refresh will bring the value to the correct state.

https://github.com/FrameOS/frameos/assets/2083512/31a4a1e6-0d4c-41c8-9a7c-6f5000b51991

mariusandra commented 5 months ago

One thing that I noticed is that on the images, on your HAT, the "Display Config" setting is set to "A: 3R", whereas I have it at "B: 0.47R". I don't know what difference it makes, nor do I remember explicitly setting it to something else.

Some other things to try:

If you remove the clock and use any other scene, will there still be something weird? E.g. replace the clock with a "random unsplash" app, with a cache smaller than your refresh time. The image quality is likely very bad (I need to implement some dithering to make it better), but it should be possible to tell if the same thing keeps happening.
Download and try to run the original waveshare drivers. Clone this folder, and follow the readme. Essentially run make clean && make EPD=epd7in5V2 && ./epd. Will the waveshare example get any image frozen, or will it work fine?
You could click "edit app" on the clock, and have it log the time to the console before printing it. Just to double confirm that the data that's sent to the display is what's expected. If :17 shows up in the logs as well, then it's definitely not the display that's at fault.

mariusandra commented 5 months ago

Hey again @andyyngo, I just merged this PR, which includes some changes I copied from ESPHome (longer discussion).

The bigger change in the merged PR is of course black and white dithering, meaning you can now use this display for photos. I was getting weird artifacts with the dithered images though, and these changes to the driver did make a difference. Perhaps they will also accidentally fix this ghosting number?

andyyngo commented 5 months ago

few things:

I reduced the scene to just: event rendering --> clock overlay and still see this issue
I have a theory: Raspberry board doesn't have a clock, when restarting it may get/guess non-accurate time and display it on eink, only after a while then it will get proper timing from the internet (through WIFI) and display that time.
Got to learn some nim in order to do development/debugging the clock overlay

andyyngo commented 5 months ago

yup, this thread confirms my theory https://forums.raspberrypi.com/viewtopic.php?t=254744

mariusandra commented 5 months ago

Hey, this does make some sense, though strange that it's always :17, and strange that I haven't experienced anything similar myself.

I might add some "wait until there's network" functionality to get around this, however a quick workaround is be to add the init event to the scene, and then write custom code that essentially just runs import os and then sleep(30000) in it. This could be enough for the frame to connect to wifi and talk to ntp to get the current time, before a frame is displayed.

mariusandra commented 4 months ago

Well, I just experienced this myself. I also got a frame to show :17 on boot (with the right hour), and only a minute later it would update to the correct time.

FrameOS / frameos

Overlay clock - Wrong time display on startup #37