Facade
Note the red or green triangle on the outer edge of the dial. This triangle marks the hour hand position for the second time zone (or the first time zone if there is no second timezone selected). This triangle will be red to indicate AM and green to indicate PM. For example, the clock face on the left shows the local time of 10:10AM, the clock face in the middle shows the local time of 10:10PM, and the clock face on the right shows the local time of 11:33AM when it's 5:33PM in Central European Time.
The main timzone is always the analog clock in the center of the display with hour, minute, and second hands. If a second timezone is selected then the hour of that timezone is shown by the triangle on the edge of the face. If the second timezone is not Local then the 3-5 letter abbreviation for that timezone is shown at the bottom of the watch face. Note how the triangle on the outer edge tracks the minutes that have elapsed between the two hour markers. This is important for timezones that don't have a 0 minute offset as you can read the time in the second timezone just from the triangle marker (if the second timezone has a 0 minute offset the the analog minute hand is correct for that timezone).
Daylight Savings Time (DST) is automatically detected for USA/CANADA/EU. The indicated time will be moved forward during DST and the timezone abbreviation displayed with be the one for DST. For other timezones there is a setting that can be set (using Connect IQ or Garmin Express, this is no available on the watch itself as it would make the watch settings too The Main DST and Second DST settings can be set to one of 3 different values:
Timezones can be selected from one of 327 countries.
The user can select which metric to display in the 4 different corners of the watch face.
You can obtain this watchface from the Connect IQ store. or by going to this direct link.
Facade is licensed under the GPL V3.0. The latest source tree is available for browsing here and tarballs for the latest and older versions are located at the following links:
Battery percentage.
Shows the current battery level as a percentage
of the maximum charge.
An arc surrounds the number giving an
analog indication of the charge percentage,
going from a full circle for 100% to a half
circle for 50% to nothing for 0%
(although the whole screen will probably
be blank if the battery is truly at 0%).
Also the color of this metric changes
to indicate the level of charge going
from green (50% - 100% charge),
to yellow (25% - 50%),
and finally red (less than 25%).
Heart rate.
Current heart rate measured in Beats Per Minute (BPM).
Step count.
Steps taken since midnight.
Moon Phase.
This will show an icon that shows an approximation
of the moon phase.
More details about the moon phase icon are found in the
Moon Phase Indicator section.
Calories expended.
Calories expended during the day, measured in kCals since midnight.
Distance traveled.
$istance traveled throughout the day, measured in kilometers since midnight.
Meters ascended.
Vertical distance ascended, measured in meters since midnight.
Active minutes.
Time not spent lazing on the couch.
Respiration.
How fast you are breathing, measured in Breaths Per Minute (BPM).
Temperature.
Shows the cached value for the temperature as reported by the watch.
This creates two problems with the temperature metric:
Every time you use the Connect IQ or the Garmin Express app to set a new timezone (either the main or secondary timezone) the watch will store that timezone in a timezone cache (the cache contains no more than 16 entries and the same cache is used for both the main and secondary timezone) on the watch itself. When setting the timezone through the on device settings you can only select a timezone that is in that cache. For example, I live in the US where we have 6 major timezones. I use the Connect IQ app to configure each of those timezones once and then I can easily use the on device settings to set any US timezone I want. Note that you can always set any of the 327 timezones from the Connect IQ or Garmin Express apps, it's only the on device settings that are limited to the timezone cache.
There are two issues that make identifying the correct moon phase extremely hard:
Having said that, Facade attempts to be fairly accurate. It calculates the current lunar day by comparing the current date to the reference date of the new moon on January 6, 2000 (I wanted to use the reference date of Januaray 1, 1900 but the Garmin date/time routines don't like dates before the Unix epoch of January 1, 1972), modulo 29.5(30588853). This calculation seems to be fairly accurate (the same calculation is certainly correct for the 44,206 days from the new moon on January 1, 1900 to the new moon on January 12, 2021). This results in a lunar day of 1 - 29 (actually, some months it turns out to be 1-30 because of roundoff with the lunar period).
The lunar day is then converted into one of 30 different icons (representing the moon waxing from new moon to full moon and then waning back to a new moon). Note that the icons for the day of the new and full moon are obvious since they are in white. Conversely, the icons for the gibbous moon a few days before and after the full moon look very similar to a full moon, this is where the tan and green colors are handy.
The problem comes in if you need to change the timezone data like adding a new timezone or deleting one. By definition the Garmin architecture requires at least 2 linked source files, the settings.xml file that shows the timezones presented to the user in the settings app and the actual timezone data that is encoded in the Tz.mc file.1 The basic design is to do just that, the settings.xml entries have an index and then that index is used to select the appropriate entry from a table in the Tz.mc file.
There are 2 problems with this basic design:
The second problem was exacerbated by the
original design which was to encode the
timezone info into an array where each
element of the array had 5 items to identify
the timezone - minute offset, standard time abbreviation,
daylinght savings abbreviation, automatic timezone
algorithm, and full name, e.g.
var TzData = [
[ +(0*60+0), "", "", -1, "Local" ],
[ -(5*60+0), "EST", "EDT", 0, "USA, East" ],
.
.
.
];
This design,
which was obvious and made
things simple at run time,
blew the memory available on
devices like a Forerunner 55.
The original solution to the
memory problem
was solved by breaking up the timezone
data into 25 entry chunks and then storing each chunk
is a separate MC file,
the TzData0.mc
to TzData13.mc files.
This way the code only has to have in memory
25 timezone entries at a time rather than 327.
The code in Tz.mc did the translation
from one of the 327 timezone indices to
an appropriate index in the appropriate TzData
file.
With this design the code barely fits
in a Forerunner 55
(with only 4K of memory to spare).
Unfortunately, expanding the moon phase from 8 to 30 icons expanded the memory and the code no longer fit on a Forerunner 55 (and no amount of futzing with the TzData chunk size made it fit). A new design is required.
Rather than storing separate data items for each timezone entry the code now just stores a long string for each timezone, where each data item (fullname, minute offset, standard time abbreviation, daylinght savings abbreviation, and automatic timezone algorithm) is separated by a semicolon within that string, e.g.
var TzData = [
"Local;0;;;-1",
"USA, East;-300;EST;EDT;0",
.
.
.
];
The downside to this design is that
we now have to parse the appropriate string
at runtime but the upside is a consderable
savings in memory.
This design saved approximately 20K of
memory and the code with 30 moon icons
now fits on a Forerunner 55 with plenty
of room to spare -
the
core/speed2
trace offwas definitely worth it.
Although the new design obviates the need for multiple TzData files there is still a problem that we have to keep 2 related files in sync with each other - the settings.xml used to select timezones and the Tz.mc which contains all of the actual timezone info. The solution is to maintain a canonical timezone data base file, support/country.txt and use the Pearl script support/tz.pl to extrace everything we need from the data file.3 Running the command tz.pl support/country.txt will generate a settings.xml file and the Tz.mc file. After generating these files you have to manually (sorry about that, there doesn't seem to be a way to do includes in settings files) add the generated lines in settings.xml to the appropriate places in the actual resources/settings/settings.xml file. Then copy Tz.mc into source/Tz.mc and you should be ready to build.