Complete
over 4 years ago

WERETECH-11147

Fixed

The burn-in protection on Venu2(s) devices with CIQ4 falsely triggers and turns off the display

I have ported several watch faces with Venu1 AOD support to the Venu2 and Venu2s devices.

My AOD modes are straight forward. I'm using a dense pattern clearing every 2nd pixel row or column on the screen alternating each minute starting with the first row/column or the second row/column.

This ensures that less than 10% of the pixels are on and no particular pixel is on for more than 1 minute.

On the Venu2 the simulator detects a screen burn-in. On the Screen Burn-In Simulation window it looks like the overlay pattern is ignored.

Also some drawing artifacts are missing on the burn-in screen for example the minute and hour hands.

I'm in contact with 2 other developers who have similar problems with at least some of their watch faces.

I already uploaded my watch faces with Venu2 support to the Connect IQ store and received feedback from a user who also owns a Venu1 that

the AOD is not working on his new Venu2. - It turns off the screen.

So this is potentially not only a problem of the simulator but also of the actual device.

Here is a screen recording of the problem in action highlighting the differences between Venu1 and Venu2:

https://drive.google.com/file/d/123bDerdGzCovWEcJlxonKbRBSo96lqrq/view?usp=drivesdk

Manuel B.
Parents
  • over 4 years ago

    Not sure which vacuum all the replies are being sucked away to, but in answer to Jim: no. 

    Dc.setColor(0,0) was pretty much my first test (referenced in my first post on the thread that predates the ticket. 

    It seems that _any_ design that would break number of pixels rule in high power mode will break it in low power mode. 

    It is like it counts _before_the first low power onUpdate. 

Comment
  • over 4 years ago

    Not sure which vacuum all the replies are being sucked away to, but in answer to Jim: no. 

    Dc.setColor(0,0) was pretty much my first test (referenced in my first post on the thread that predates the ticket. 

    It seems that _any_ design that would break number of pixels rule in high power mode will break it in low power mode. 

    It is like it counts _before_the first low power onUpdate. 

Children
  • over 4 years ago in reply to jim_m_58

    video shows that there was no interleaving pixel, heat maps says the same 

    so solutions:

    1. heat map not work right and on device will be ok

    2. Pattering not work well

    rather 2, why?

    - bad algorihm

    - system draw something else if not black colour

  • over 4 years ago in reply to 9635560

    That's not what I see with mine.  I have a number of WFs that run fine for the v2 in the sim.

    If the WF has say a green background with white text, that's 100% of the pixels, and it works fine in low power mode.