189 Wio: WioClock (189.html)

Keywords

WioIXkb py "Enter key" "189 Wio: WioClock (189.html)" WioTerminal SeeedStudio ICH180RR D@CC Raspberry-Pi-Compatible MicroPython uSD MicroPython .def uJoyStick Raspberry Pi setClock "improvised function" "Unix Time" "Unix Epoch" media/rtc TI BQ27441-G1A

(To enlarge .....Click it)
thumb: IXimage.jpg
IX or DC (IX by DC) or "|><"

This software is a part of the IX family of software.

WioClock

(To enlarge .....Click it)
thumb: IMG_5049.jpg
The tiny Wio Terminal

(To enlarge .....Click it)
thumb: IMG_5098.jpg
WioTerminal with WioClock.py v2o11

A working version (v02o11) of WioClock is shown in the image on the above right. When it starts up, it takes its current time from a small file previously written to the flash. The above image does not do justice to this great program named WioClock. This clock is updated in real time every 5 seconds. The date and time are both displayed on the bottom 3 rows in Unix nomenclature. The full code for this version is available in Source 09 as a text file that must be renamed to ".py" . This program was coded in MicroPython by the author (D@CC) of this article. Refer to the source code for the correct ".uf2" file that is needed for WioClock.

It is notable that the WioClock program has been coded as a function instead of as a main program. By doing this, it is possible for one program named "main.py" to invoke many other programs by calling the "improvised function" that "is really" the whole program. The author has coined the name "improvised function" for such a program. All that the "main.py" program needs to do is provide a submenu that lists the programs that can be selected to be run in this manner on the WioTerminal.

The current Unix Time can be looked up at Source 08.

Table of Contents 

189 Wio: wioClock (189.html)
WioClock
Table of Contents
Introduction
CLS - Clear Screen
Test_listAintoB_v01o01.py
iClock.txt
UTC, GMT, EST, EDT
mainBuild.py Plan
MicroPython vs CircuitPython
The Wio-Terminal-Battery-Chassis
Conclusion
End of Article
Sources

Introduction

The is the beginning of my documentation for the WioClock (or iClock).

CLS - Clear Screen

I need CLS code for the WioTerminal. I thought I could clear the WioTerminal LCD screen by sending CTRL+L. In REPL the following statement works fine using REPL on the RPi: 
>>> print("\x0c")
When I am using minicom with REPL on the RPi I am working in a Terminal window. This terminal window gets cleared by the statement above. However, simultaneously, the same print statement is sent to the WioTerminal and when I send the above print statement twice, it doesn't clear the LCD screen, it merely displays on the LCD 
print("\x0c")

print("\x0c")
without clearing the LCD screen

C/++ Code to initialise the LCD screen on the Wio Terminal

See Source 03 by Seeed Studio for an article describing code for the LCD including "TFT_eSPI.h" . This code sets the rotation and fills the screen with the color red. Other code controls the Backlight on the LCD of the Wio Terminal. See Source 04 for more info about MicroPython and the LCD screen on the WioTerminal.

Test_listAintoB.py

latest version v01o01

This function has evolved and been tested and is almost ready to be used. However there are many other functions needed before this tiny wio clock will be complete. 
#Test_list(AintoB_v01o01_i.py
def Test_listAintoB():
    # by D@CC on 2023DApr01
    # functions used
    #     show()
    #     listAintoB()
    #    iTest_listAintoB()
    # saved as Test_listAintoB_v01o01_i.py
    Doh=iTest_listAintoB()
    return ""
#def end

#listOfObjecInList.def
def show(objName,obj,isShow):
    if not isShow: return
    if not isinstance(objName,str):
        print("Error S01 in show, Name is not a str:";objname)
    if isinstance(x, str) or isinstance(x,list) or isinstance(x,int) or isinstance(x,bool):
        #is ok
        print(objName;":",obj,":")
    else:
        #bad Type
        typeObj=type(obj)
        print("Error S02 in show obj is not a str, list, int nor bool:";objname;"type:",typeObj,"value:",obj)
        return
    #if end
def listAintoB(atRow,atCol,listA,listB,isShow):
    # parm1 atRow
    # parm2 atCol
    # parm3 object can be a string or a smaller list
    # parm4 listTarget
    #
    # returns
    # parm1 a list that is the result
    
    #Purpose to place a rectangular list or string into a same size or bigger list
    #       that already exists.
    
    #constraints
    # 1. the elements of a string list must be single characters
    # 2. the elements canot be null
    # 3. the elements cannot be "/r" nor "/l"
    # 4. no find and replace is possible
    # 5. the row and column position must not be negative numbers
    # 6. the # of columns in every row must identical
    # 7. any error returns a null List
    # 8. a string is just a list of characters
    # 9.     return
#def end 

def iTest_listAintoB():
    result= True
    progName="iTest_listAintoB"
    print("entering ",progName)

    isShow=True
    show("good float",5.3)
    show("null",null)
    a=[ [1,"Joe"],[2,"Pete"] ]
    c=range[1,2,3]
    show("c",c,isShow)
    listNull=[]
    lenNull=len(listNull)
    show("lenNull",lenNull,isShow)
    lenA=len(listA)
    show("lenA",lenA,isShow)
    lenB=len(listB)
    show("lenB",lenB,isShow)
    print("exit from:",progName)
    return result
#def end
########################################################
# Main 2 line calling program starts here
Doh=Test_listAintoB_i()
print("result:",Doh)

#/Test_listAintoB.py
#/Test_listAintoB_v01o01.py is saved name

iClock.txt

Source 02 is the text of a Splash screen of an iClock program that is designed to operate with the WioTerminal

UTC, GMT, EST, EDT

Anyone who has programmed a real-time clock based on the Unix Time Clock will have a good understanding of these terms. First, I will define them, before using them.

This is being editted. Do not expect this section to be accurate (yet) ! ! ! ! ! 
UTC  Unix Time Clock        (set to 0 on 1970 Jan 1 at 00:00 ) counts seconds
GMT  Greenwich Mean Time    (should = the main UTC clock* at Greenwich)
EST  Eastern Standard Time  (5 hours earlier than GMT)
EDT  Eastern Daylight [saving] Time (4 hours earlier than GMT)
            * a clock at Greenwich that was 0 on 1970 Jan 1 at 00:00 o'clock.
"main UTC time"             (the time shown on the UTC clock located at Greenwich, England)
"main Unix Epoch"           (the exact moment at midnight New Years Eve in 1970 at Greenwich, England)
UTC is based upon a clock that started at the Unix Epoch, which was Jan 01 1970 (GMT) in Greenwich, England. I say that this clock shows the "main UTC time". The UTC (in seconds) has grown into a very big number over the years. As of the current time now, while writing (2023DApr06), the UTC is approximately 1680742000 (according to Source 08). Source 08 lets you explore conversions of UTC to/from your time zone. It uses the magic of the Internet to deduce what time zone you live in.

The changing number (in the largest font, top right) shown at Source 08 is supposedly the main UTC (and GMT at Greenwich, England). A Unix time-converter is also provided at Source 08. You can enter a time in Unix Seconds and it will be converted into GMT and into your time zone (which for me is EDT). You can convert the big bold number into Date & Time (by pressing "Copy" then CTRL-V to paste it into the box labeled "Enter a Timestamp"). It will copy the big bold number. Sometime it copies a number which is less about 3600 seconds (ie 60 minutes, I don't know why). So the number copied will be the main UTC (and GMT). To convert it to date/time, press the "Convert->" button. But the number actually "pasted" might actually show a slightly different time for the time in Greenwich, England. The actual date & time in the user's time zone is also shown (for me it shows the time labelled EDT), but the time shown is actually GMT-4 hours, wheras the clock on my computer is 1 hour later [GMT-3 hours]. This discrepancy only happens occasionally. In my case (EDT), it shows the time to be 4 hours earlier than the GMT. The label under the big number reads "seconds since Jan 01 1970. (UTC)". But whose time zone was used, to set the UTC being displayed? I think it should have been (and should still be) the main UTC in Greenwich, England.

Apparently, the current UTC clock that is displayed in big bold digits at Source 08, shows the main UTC located in in Greenwich, England. In fact, a New York UTC clock that measures the number of seconds since the dropping of the ball in NewYork city at midnight (at the end of Dec 31, 1969, Unix Epoch) should today show around 1680742000 seconds in EDT. In Greenwich, England, at that exact moment, it would have been 5am and the main UTC clock would show 1680760010. A person in Greenwich could have called a friend in NewYork when the Unix Epoch began (in Greenwich). He might have phoned to ask for the UTC time (according to a UTC clock in New York). The UTC time in New York would have been -14400 (yes earlier, of course) on a UTC clock located in New York. We have learned that the main UTC clock is located in Greenwich, England. And we can have our own UTC clock that is a number of time zones different than the main UTC clock. This is analagous to us having our own "normal" clock on the wall showing the "current" time in our time zone. This clock on the wall would show a different time than one in Greenwich.

Well, the guy in New York, (at the Unix Epoch, Jan 1, 1970 in Greenwich, England), should say, "my UTC is -14400 but the main UTC clock in Greewich is, now, of course, 0 at the Greenwich Unix Epoch". The person in Greenwich might say "the main UTC clock shows that my UTC time is 4 hours later (which is 4x3600 = 14400 seconds later) than that in New York. My UTC clock, in Greenwich, at the main Unix Epoch is of course 0." This means that people in different time zones can have "their own" UTC clock, showing their UTC. But the main UTC (that everyone can agree on at any time) shows the UTC in Greenwich, England. If you are perplexed, please go back and reread the previous paragraphs before continuing.

Using the Unix calculator, New Year 2023 began when the UTC clock in Greenwich (GMT) was 1672531200. The calculator shows that, in New York, the time (EST) was 5 hours earlier. The calculator even comments "3 months ago". In conclusion, we can use the UNIX converter to convert 1672531200 to GMT and EST. It will show that 1672531200 was midnight on New Year's Eve 2023 in Greenwich. So, I conclude that the UTC clock shown at Source 08 displays a UTC clock that was set to 0 in Greenwich, not in New York at the beginning of the main Unix Epoch. To verify this, I will help you calculate exactly how many seconds had elapsed in Greenwich on New Years eve 2024 since the main Unix Epoch. The calculation is (2023-1970) x 365 =19358 days. In these 53 years there were 14 leap-years -1 (in 2000). So adjust 19358+13= 19371 days. For the number of seconds: we need 19371 x 24 x 3600. My calculator computes this to be exactly 1673654400. (This ignores any leap seconds that have beeen recently introduced because of recent changes in the rotational speed of the Earth.) This is the number that should have appeared (on New Year's eve 2023) on the main UTC clock in Greenwich, a UTC clock that was set to 0 when the main Unix Epoch began in Greenwich. This is NOT exactly what the Unix converter shows. Starting with the main Unix time of 1673654400, the date/time using the UTC converter shows "Jan 14, 2023 00:00:00 GMT+0000". It also shows that the concurrent time in New York (EST) was 5 hours earlier (GMT-0500). These numbers are 13 days later than expected. Why?

why does the Unix Converter show a date/time exactly 13 days later than our calculations?
Indeed, Why? These 13 days do correspond to the number of leap days during the past 53 years. Either my above calculation was incorrect or the Unix Converter does the wrong conversion.

What would the main UTC clock in Greenwich be today? By my above calculation, it should be 1673654400 plus the number of seconds elapsed this year. In Greenwich, the current time is approximately 8:00 am on Apr 6, 2023. The number of days since New Year's Eve 2023 is 31+28+31+5=95. To convert this to seconds, we calculate 95x24x3600 = 8208000. At 8am in Greenwich, the number of seconds elapsed today (since midnight) was 8x3600=28800. Total seconds this year were 8208000+28800 = 8236800. The main UTC clock in Greenwich should be 1673654400+8236800 = 1681891200 at 8:00 am Greenwich time. At 13:15 EDT (today Apr 6,2023), so in Greenwich, the current time is later ie 17:15 GMT. To calculate the number of seconds to add we subtract 8 hours: 9 hrs 15 min = 9 x 3600+15 x 60 = 14400 + 690 = 144690 seconds. Using these calculations, the current main UTC clock in Greenwich should be 1681891200 + 144690 = 1682035890. The main UTC time shown at Source 08 shows 1680801542 which is 1234384 too little (exactly 13.2864 days too little.

At 1:31 pm EDT, the exact Unix time at website "is/Unix_time" (Source 10) shows 1680802206. Consider an accurate seconds counting device that had been started in Greenwich at the Unix Epoch. Today (at 8:00am) it would have shown exactly 1682035890 seconds elapsed. But we have learned to insert leap years, in order to keep our calendar dates in sync with the Earth's actual length of year. Of course, our calendar is adjusted using leap years to keep our calendar dates in sync with the Earth's actual length of year.

This tells me that the main UTC clock has been adjusted for leap years. Our normal dated clocksare adjusted by the introduction of leap years. This is the same type of problem that the world encountered in the time of Julius Caesar. Spring was occuring at a different time of the year over the long period of hundreds of years. The extra 1/4 day each year had not been taken into account on the caledar. To allow for this, every four years (approximately), we must either insert a day into (ie advance) the calendar or remove a day from the Date/Clock. In Unix it appears that the decision was made to remove a day from the Unix clocks every four years [or remove 1/4 day from the Unix clocks every year]. That is my current understanding.

The net result is that the accurate timer would show the exact number of seconds since the Unix Epoch. But the Unix clocks are being adjusted by removing an appropriate number of seconds each year or every four years. This simplifies the calculation of the actual date, given the Unix date. The correct calculation is to calculate the number of seconds/year using 365 day years. Then add to this the number of seconds since the beginning of the year. This calculation would result in the the current main Unix date/time.

Let's calculate the Date/Time based on the current Main Unix Time which (at 2:30 pm today) is 1680805333. We calculate the number of seconds in 53 years of 365 days which is 1671408000. Now 1680805333 - 1671408000 = 9397333. The number of full days since the beginning of the year 2023 is 31+28+31+5 = 95. This is 95 x 24 x 3600 = 8208000 seconds. Subtracting that period of time is 9397333 - 8208000 = 1189333 . Now remove the number of seconds in 13 leap-days which is 13 x 24 x 3600= 1123200. This results in 1189333-1123200 = 66133. This is equal to 18 hours 1333 minutes which is 18 hours 22 minutes 13 seconds ie 18:22:13.

Let's use the Unix converter at Source 08 to convert 1680805333 to GMT and EDT. It results in

GMT Thu Apr 06 2023 18:22:13 GMT+0000 and
EDT Thu Apr 06 2023 14:22:13 GMT-0400 (Eastern Daylight Time)

Both the calculator and my calculation agree. This means that the main Unix Clock includes all the leap seconds. They must be removed from the UTC seconds when calculating the Date/Time from the main UTC in Greenwich, England.

But I still cannot explain why the UTC tiime shown at Source 08 doesn't conver to the exact date/time on my wall clock. My wall clock is 2 hours later than the Unix time being updated at Source 08.

Fortunately, I am writing this article in the EST time zone, the same time zone as in New York. At the current time, it is 3am on Apr 6, 2023. How many seconds have elapsed since New Year's Eve 2023.

setting the time on the WioClock
The clock at Source 08 shows the number of seconds since the Unix Epoch in Greenwich, England. (By the way, negative UTC numbers permit recording the time of any time prior to the Unix Epoch.) GMT is the time at the Prime Meridian which is located at Greenwich, England. The main UTC is equivalent to the GMT. When WioClock starts up (in the absence of WiFi access) it reads the time that it should begin using from a small file in media/rtc/.

mainBuild.py Plan 

>>> invoke as . . . mainBuild Test_progName_v01o01_i d
>>> needs  Desktop/d.txt  as "2023DApr03"
>>> needs /home/pi/Desktop/IX_assets/WioIXkb/WioFunctions/WioFunctions.py
>>> needs Desktop/Test_progName_v01o01_i.py
>>> outputs Desktop/Test_progNamev01o01_i_2023DApr03.py

>>> cd /proc/pi/Desktop
>>> cat %1.py /home/pi/Desktop/IX_assets/WioIXkb/WioFunctions/WioFunctions.py >%1%_%2.txt  .py

MicroPython vs CircuitPython

I have trouble getting into the MicroPython environment vs the CircuitPython environment. I believe that the Arduino volume provides CircuitPython and the ArduPy volume provides MicroPython. Source 05 describes Circuit Python libraries. One can use REPL to try: 
>>> from machine import LCD
>>> #  the above needs MicroPython
>>> import board
>>> # the above needs CircuitPython
>>> import os
>>> os.listdir()   # shows ArduPy . . . . uf2
>>> dir(os)
>>> help(os)
>>> import sys
>>> dir(sys)
>>> help(sys)
This will test machine (MicroPython only), list the top directory, and display ???.

I have begun to include in the top folder of WioTerminal, each set of code (version&time-stamped) that can be flashed into the top folder as "main.py" . For example :

>>> import os
>>> os.listdir()
Arduino_wio_terminal_lastest.uf2
AvailablePinNames.py
main_WioClock_v02o11_2023DApr05.py
main.py
osDirWio11.py
WioClock_v02o11_2023DApr05.py
etc

The Wio-Terminal-Battery-Chassis

(To enlarge .....Click it)
thumb: IWioBatteryAccessoryStatus.jpg
Wio Battery Accessory Status display

There exists a Battery Accessory that neatly plugs into the WioTerminal. It is the Wio-Terminal-Battery-Chassis from Seeed Studio SKU 103990564 that costs US$ 25.20 . When this Battery Accessory arrives from Seeed Studio, it should be charged before it can be used as a stand-alone battery for the WioTerminal. The WioTerminal can be used while the Battery Accessory is plugged into it and being charged.

For the code that produces the above status display, refer to Source 13. This code outputs information from the TI BQ27441-G1A "fuel gauge". The author has not yet tested the code that is referenced. It appears that this code might only run on an Arduino microprocessor. :(

When the Battery Accessory is plugged in and is being charged, a tiny green Led (located on the upper left side of the back of the Battery Accessory) is ON. When fully charged, this Led turns OFF although the Battery Accessory might still be plugged into a 5V power source. Consider: when the Battery Accessory is connected to the WioTerminal which is powered by the USB cable from the RPi. If the Battery Accessory's battery is low, the green LED (on the Battery Accessory) will blink at 1 Hz. and the Battery Accessory will NOT be charging, but the WioTerminal will receive "keystrokes" from the RPi. But if the USB cable from the RPi is attached to the Battery Accessory instead, the WioTerminal will not receive "keystrokes" from the RPi, but the Battery Accessory will be charging (and its Green & Red Leds will be ON constantly.

There is another red/orange Led, lower down. The specs describe it as:

"Red LED: Light on is mean the OTG (battery discharge) enable."

The Red LED was ON when the Battery Accessory was providing power at one time.

The specs also mention a Yellow LED described as:

Yellow LED: Light on is mean the male interface output/input 5V.

But I believe Yellow LED no longer exists.

There are no buttons or switches, just the 2 Leds, the front and back GPIO pins, the 6 Grove connectors and the USB-C connector on the Battery Accessory. The Battery Accessory does NOT come with a USB cable. The male pins on the GPIO at the front of the Battery Accessory can easily be damaged. When not in use, these pins should be protected by some protective bubble wrap. No cable is needed between the Battery Accessory and the WioTerminal, the power is supplied via the GPIO pins. The specs list an On/Off button but its existence is not apparent. This device has internal magnets that permit it to be attached to a whiteboard. It is not known whether or not the Battery Accessory can provide sufficient additional power to supply an attached Raspberry Pi computer. I encountered no problems when the Battery Accessory and the RPi were both connected to the WioTerminal at the same time. I have not disconnected the power to the RPi to see if power would go "backwards" into the RPi via the serial USB-C cable. (My expectations are not high.)

The following [probably deprecated] Precautions are listed:

-If the battery is unattached, the chassis will switch to failure mode, and the green light blinks at a frequency of 1Hz.
-Please press the button (where is this button? Doh!) to let the chassis entering sleep mode for safety consideration, and the LED on the backside of the chassis will go off.

The description says that this device now has Overcurrent protection and Hiccup mode/Hiccup Protection (whatever that means). The wiki, in Source 11, says that Hiccup protection is protection against short-rcuits on the output. A brief note in the wiki says that 3v3 is not provided by the Battery Accessory. The Wio Terminal provides this voltage conversion. I have seen elsewhere that there is an app that can show the status (see above image) of the Battery Accessory. Since there is no LCD on the Battery Accessory, this app needs a WioTerminal to operate. The new version of this Battery Accessory has a built-in BQ27441-G1A fuel gauge. It enables the showing of information such as:
Battery Accessory Status
-State of Chage [s.b. Charge]
-Battery Voltage
-Average Current
-Remain Capacity
-Full Capacity
-Average Power
-State of Health

The above status report might indicate that the WioTerminal Battery can provide power to the WioTerminal for around 3 hours.

See Source 11 for the Wiki on the Wio Terminal Battery Chassis. A zip file (Source 12) is available for the schematic.

The information describing the Wio Terminal Battery Chassis needs to be thoroughly reviewed. There appear to be many references to features of the previous version of this device. Some of these old features have clearly been deprecated.

Conclusion

This program, WioClock.py, by David @ ColeCanada.com, is a work-in-progress as of 2023DApr06.

This article, by D@CC, is of course, also a work-in-progress as of 2023DApr06.

End of Article (Sources Follow)

Sources

Video Sources

Video Source V189:01:www Exploring the Wio Terminal ( 1:14 min) by Seeed Studio in 2021

Web Sources

Web Source S189:01:www Find D13 in 186 Pi: Wio Terminal for Raspberry Pi (186.html) by D@CC of ICH180RR on 2023CMar31
Web Source S189:02:www a Splash screen for an iClock by D@CC of ICH180RR on 2023DApr03
Web Source S189:03:www Basics of the TFT LCD Screen in c/c++ by Kenta IDA of Seeed Studio before 2023DApr03
Web Source S189:04:www HelloWorld on the WioTerminal LCD Screen in MicroPython (saved as .txt) by Seeed Studio before 2023DApr03
Web Source S189:05:www Circuit Python Libraries by Adafrut before 2023DApr03
Web Source S189:06:www WioClock_v01.py (as .txt) WioClock_v01.py by D@CC on 2023DApr03
Web Source S189:07:www WioClock_v01o33.py (as .txt) WioClock_v01.py by D@CC on 2023DApr03
Web Source S189:08:www The Current Epoch Unix Timestamp at Dan's Tools as of 2023DApr04
Web Source S189:09:www WioClock_v02o11.py (as .txt) WioClock_v01.py by D@CC on 2023DApr06
Web Source S189:10:www Time.is Unix time now by Apple as of 2023DApr06
Web Source S189:11:www Wio Terminal Battery Chassis Wiki by Seeed Studio as of 2023DApr06
Web Source S189:12:www Wio Terminal Battery Chassis Schematic (zip file) by Seeed Studio as of 2023DApr06
Web Source S189:13:www Wio Terminal Battery Chassis Status Display Program by Seeed Studio as of 2023DApr06

WebMaster: Ye Old King Cole

There is a way to "google" all the part-numbers, words and phrases in all my articles.  This 
search limits itself ONLY to my articles. Just go to the top of "ePC Articles by Old King Cole".
Click here to return to ePC Articles by Old King Cole

Date Written : 2023 D Apr 02
Last Updated : 2023 J Oct 11

All rights reserved 2023 by (c) ICH180RR

saved in E:\E\2022\DevE\MyPagesE\Globat\ePhotoCaption.com\a\189\189.html
backed up to ePhotoCaption.com\a\189\189_2023DApr03.html
Font: Courier New 10 (monospaced)
/189.html