Improved auto-brightness and Italian language support

[oldmaker]

Thank you André for your firmware.
I am Pasquale "OldMaker" from Italy.
I bought a Waveshare Pico-Clock-Green and tested it with the original firmware; then I installed a Pico-W and tested it with your firmware and I found it very very good.

So I decided to add a couple of features:

• modified the auto-brightness mechanism (hardware and software);
• added Italian language support.

You can find the modified firmware on my fork: https://github.com/oldmaker/Pico-Green-Clock.

I'll explain the changes in detail.

Auto-brightness - hardware.

• Replaced resistor R8 with a 1.5 MOhm resistor (any value between 1 and 2 M is ok);

• added a 2200 pF capacitor in parallel with photo-resistor R7 (any value between 1000 and 4700 pF is ok); it's an optional change, it makes the readings more stable and add a little "natural" hysteresis;

• made a 7-8 mm hole in the plastic container, nearby the photo-resistor, then closed it with a transparent lens.

These hardware changes improve considerably the sensitivity to ambient light: now the values of the readings (adc_read_light) actually vary in the range from 5 to over 4000.

Auto-brightness - software.

• Defined two new user-customisable parameters: MIN_LIGHT_LEVEL (the light level at which the display brightness will be set at 10% - default 10) and MAX_LIGHT_LEVEL (the light level at which the display brightness will be set at 100% - default 1000); so the user can choose the response of the display to the ambient light, e.g. if the room is dark or sunny or he didn't make the hardware changes;

• modified adjust_clock_brightness() function; due to the new and variable range of readings, I adopted a new algorithm to calculate the corresponding DutyCycle, based on the equation of the straight line through two given points:
  given points: (x1=MIN_LIGHT_LEVEL, y1=10%), (x2=MAX_LIGHT_LEVEL, y2=100%)
  standard equation: y - y1 = (y2 - y1) * (x - x1) / (x2 - x1)
  so: y - 10 = (100 - 10) * (x - MAX_LIGHT_LEVEL) / (MAX_LIGHT_LEVEL - MIN_LIGHT_LEVEL)
  finally (line 3744): DutyCycle = (90 * (AverageLevel - MIN_LIGHT_LEVEL) / (MAX_LIGHT_LEVEL - MIN_LIGHT_LEVEL) + 10);

• moved adjust_clock_brightness() function call from timer_callback_ms() to timer_callback_s() (executes it every second instead of every millisecond) and reduced from 5000 to 5 the number of readings for the average calculation; this reduces the Pico's load and it seems to me that it works well. Or, do you think there is any reason to leave the reading every millisecond ?

Italian language support.

• Added in bitmap.h a and i with grave accent (à, ì); ... a computer technician can be really fussy :-) :-)
• added #define ITALIAN 0x05;
• added italian names for months and days;
• added all "case (ITALIAN)" in switch instructions.

If you think that my changes are interesting or useful, feel free to use them in your next release.
Thank you again. Bye.

        Pasquale "OldMaker"

[astlouys]

Hello Pasquale,

Thank you for your good words and for taking the time to drop a few comments. It's fun to know that part of my firmware is now running in Italy !! (By the way, I spent part of my career with GTech which has been bought by Lottomatica, your neighbour ;-) )

I was already planning to add a parameter to define the minimum ("floor") value for the clock brightness (It may be a little too dim right now, although some users told me they appreciated the fact that they can put it in the bedroom and it does not disturb... Adding a parameter for this "floor" value will allow a simple customization. Since you offered me, I could take a look at your code and copy-paste it (or use it as an inspiration for the improved algorithm).

What are the advantages of the "hardware" hysteresis instead of the software one ? Maybe you simply discovered the new firmware after making hardware changes to the clock ? It seems that Waveshare removed the link to my GitHub page from their web site. Did you discover it simply because you use to scan GitHub for different purposes ?

No doubt that the hole in the plastic case should help. If you have the same hardware revision that I have, there is no "smoke" (color) on the plastic on top of the photo-resistor, but nonetheless, I've seen that ADC readings are not as wide as they could be.

As for the frequency for reading ambient brightness, you're right, every second would definitely remove some load on the micro-controller. (I'm curious to see how much the "system idle monitor" will be affected by this change). That's strange that I haven't thought about changing that... Good idea !

I will take advantage of the Italian translation that you've done to implement it to my firmware. I'm currently working on a stepper-motor project, but I should spend some time on the Green Clock again in the coming weeks. I also have a few "Pico-RGB-Matrix" that I bought a while ago and that I want to improve... Too many projects, not enough time (smile).

Thanks Pasquale !

[oldmaker]

Hello André,
yes, I know Lottomatica; with lotteries, bets and various games they became a power and now they offer many other services.

I discovered your firmware because, when I bought the Green Clock, on the Waveshare web page there was a link to your page; now I see they added a lot of documentation, but there are no more links to external contributors.

The "hardware" hysteresis is not an alternative to software hysteresis; your algorithm works very well and is necessary anyway. I added the capacitor because I noticed some variability in read values and I suspected some interference; obviously, the side effect of the RC net is a different time response (RC time constant ... variable, due to the presence of the photo-resistor).

The plastic case I received is thinner on top of the photo-resistor, but not very trasparent; but that which effectively improved the sensitivity is the new 1.5 M resistor in place of the original 100 K R8; I simulated various values in Excel before choose it.

I have a Waveshare "Pico-RGB-Matrix", too. I translated the comments and the calendar from Chinese to Italian (thanks, Saint Google Translator!!); I tried to improve the auto-brightness, but the dimming method they use is rudimentary, they don't drive the LED matrix in PWM and I have some glitches.
But I spent much more time for the case: I built a case in beechwood, including buttons; I should have a mini-circular saw, a mini-drill, mini-all (smile).

I agree, too many projects; I should complete my wooden workbench, for example.
People say that when retired, you'll have a lot of time and probably you'll get bored; but I never have enough time (smile).

Thanks for your answer, André. Bye.

[astlouys]

Hi Pasquale,

Should I understand from your last email that you're retired ? I retired three years ago and the Raspberry Pi's were bought a few months before since I was keeping them as potential "retiring projects" ! (of course, the Pico didn't exist at the time and came later on).

I spent a few hours on the Pico-RGB-Matrix a while ago (not much). Waveshare's brightness control implementation was about the same as on the Pico-Green-Clock and it is one of the first things that I already modified (if I'm not mistaking), along with an RGB LEDs test (which also serves to test the brightness).

My Firmware is not ready for a public disclosure, but if you want to navigate through it in order to implement a PWM brightness, feel free to send me a quick email (my address is in the manual of the Pico-Green-Clock) and I will forward you the current version (keep in mind it must be considered a "work-in-progress for your eyes only").

[oldmaker]

Hi André,
only a brief message (it's late) to inform you of another change I did in my fork: at line 3278, after a successful ntp_get_time, if in RELEASE_VERSION, the number of NTP errors is resetted, to avoid a sporadic NTP error is displayed forever in the periodic scrolling message; obviously, in DEVELOPER_VERSION the number of NTP errors will be preserved for testing purpose.

[astlouys]

Hi Pasquale,

Thanks for the info / comment.

In fact, I think I need to review part of the NTP algorithm... If ever, for some reason, your home network goes down and then back on, the connection ("socket") has been lost. According to what I've observed, NTP errors will add-up forever if that case happens... I have to make sure that if the network connection is lost, it will be reset to prevent that problem.

Of course, I've seen over the months that the real-time clock IC is real good to prevent time drift, so even if the NTP connection goes down, the clock may go on with the user not realizing the problem...

This is put aside for a future version ;-)

[oldmaker]

Hi André,
I made another little change (ver. 9.02.05).
At the end of August, after 2 weeks with temperatures of 35-38° C (and after another 3 weeks like this in July), it finally rained; and now, when it rains, it pours, it hails... and sometimes the electricity goes out.
So I realized that probably the restart of the Pico-Green-Clock is faster than that of the router, and the Pico-Green-Clock may fail to connect to the Wi-Fi network and will remain disconnected indefinitely.

To solve this problem, I added a loop in the connection initialization: in case of connection failure, ntp_init() will be repeated 3 times, with a one minute delay.
For now it seems to be working.

I had previously tried to insert the repetition in the main program loop so as not to delay the restart, but Pico-Green-Clock crashed, probabily because the time needed for ntp_init() execution is too long.

I also made some small corrections to the Italian translation.

[astlouys]

Hi Pasquale, I thought I had already put a loop during the power-on sequence in case the connection takes some time to establish. In fact, that's why you have to wait almost 60 seconds before entering your credentials (for the first time) during the start-up sequence... The Green Clock tries to logon many times (10 times if I remember well) and after this delay, it will proceed to detect the "Set button" press and go on with credential input. Maybe the router is still slower than those 10 logon tries by the Green Clock... In any case, it comes down to the problem we discussed together recently about "NTP errors". If the clock is able to reset its network ("socket") connection after a power cycle (Off and On) on the router, it should solve your problem at the same time: The clock would be too fast (and would not connect) during power-on, but thereafter, next time it tries to sync with NTP, it will realize that the connection is down ("lost") and it will reconnect automatically. Again, this is not implemented yet and this is something new I plan to add in a future version. I must confess that I didn't spend much time on the Pico this summer. I had many activities here and there, leaving less time for development. Hopefully the winter will be a better time to add new features.I will also check the changes you made to insert them in the new baseline code. André Le mer. 13 sept. 2023, à 06 h 29, Pasquale ***@***.***> a écrit :

…

Hi André, I made another little change (ver. 9.02.05). At the end of August, after 2 weeks with temperatures of 35-38° C (and after another 3 weeks like this in July), it finally rained; and now, when it rains, it pours, it hails... and sometimes the electricity goes out. So I realized that probably the restart of the Pico-Green-Clock is faster than that of the router, and the Pico-Green-Clock may fail to connect to the Wi-Fi network and will remain disconnected indefinitely. To solve this problem, I added a loop in the connection initialization: in case of connection failure, ntp_init() will be repeated 3 times, with a one minute delay. For now it seems to be working. I had previously tried to insert the repetition in the main program loop so as not to delay the restart, but Pico-Green-Clock crashed, probabily because the time needed for ntp_init() execution is too long. I also made some small corrections to the Italian translation. — Reply to this email directly, view it on GitHub <#26 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYPZOV7CZVC6ZHKRV44EUOTX2GDIBANCNFSM6AAAAAA3V576P4> . You are receiving this because you commented.Message ID: ***@***.*** com>

[BBBys]

Dear André,

Thank you for this software!

It worked fine, however, I also experienced problems with the autolight function - too dark in a ordinary living room.

I used e slightly other approach to solve the problem:
from void adjust_clock_brightness(void):

  
      /* Update current clock display brightness, based on average ambient light level for the last 2 minutes (hysteresis).
         Ambient light level goes from around 200 (very dark) to 1500 (very bright). */
      /** 20240819 BB
      Observation: 
      Light level from 210 (sensor covert) 
      to 220...250 (clock casing closed, normal livingroom light)
      to 790 (clock casing closed, placed below lamp)
      desired duty cycle: 100 (light) through 40 (livingroom) to 10 (dark)
      Mapping:  Average Level   Duty Cycle
                      790                   100
                      250                    40
                      210                    10
      Linear Regression:
                lighter: Avl 790...250, Dc=100...40: Dc=Avl*0,1098+13,255
                lower:   Avl 250...210, Dc= 40... 10: Dc=Avl*0,7676-151,206
      **/
      AverageLevel = AverageLightLevel;
/** original
      if (AverageLightLevel < 225) AverageLevel = 225;
      if (AverageLightLevel > 525) AverageLevel = 525;
      DutyCycle = (UINT16)((AverageLevel - 225) / 3.0);
original **/
/**new**/
      if (AverageLightLevel < 210) AverageLevel = 210;
      if (AverageLightLevel > 790) AverageLevel = 790;
      if (AverageLevel > 250)
          DutyCycle = (UINT16)((double)AverageLevel * 0.1098 + 13.255);
      else
          DutyCycle = (UINT16)((double)AverageLevel * 0.7676 - 151.206);
      pwm_set_duty_cycle(DutyCycle);

NB: It is not hysteresis but PT1-behaviour according to control theory.

Thank you again and regards

Burkhard Borys

[astlouys]

Hello Burkhard,

Many thanks for your feedback.

You're right, the "low" and "high" limits for the Pico-Green-Clock auto-brightness may not be properly adapted for all environments. I'm now actively working on another project (the "Pico-RGB-Matrix" - also in one of my repositories - and I solved the problem that you described by allowing to dynamically adjust the "low auto-brightness limit" and the "high auto-brightness limit" the way the user wants. This way, the hysteresis varies between two limits that may differ from one user to the other (or, for that matter, from one particular room in the house to another).

I may come back to the Pico-Green-Clock some time in the future to integrate some features / modifications suggested by GitHub users, That being said, I realized that the LED matrix display of the Pico-RGB-Matrix gives a lot more possibilities and I'm planning to extend its use as the basis for a Smart Home System. This gives me less time to work on the Green-Clock (smile).

Thanks again Burkhard. I hope you enjoy the Pico-Green-Clock features !

André St-Louys