Code: { "PAGO", -11 }, { "HONL", -10 }, { "ANCH", -9 }, { "L A ", -8 }, { "DENV", -7 }, { "CHIC", -6 }, { " NYC", -5 }, { "CARC", -4.5 }, { " YYT", -3.5 }, { "BRAZ", -3 }, { " UTC", 0 }, // !!! index 10, default = UTC_INDEX { "LOND", 0 }, { "PARI", +1 }, { "ATHN", +2 }, { "MOSC", +3 }, { "IRAN", +3.5 }, { "ARAB", +4 }, { "AFGH", +4.5 }, { "PAKI", +5 }, { "INDI", +5.5 }, { "NEPL", +5.75 }, { "BNGL", +6 }, { "MYAN", +6.5 }, { "THAI", +7 }, { "CHIN", +8 }, { "TOKY", +9 }, { "ADEL", +9.5 }, { "SYDN", +10 }, { "NOUM", +11 }, { "WELG", +12 },

Code: { "PAGO", -11 * 4 }, { "HONL", -10 * 4 }, { "ANCH", -9 * 4 }, //us { "UT-9", -9 * 4 }, { "L A ", -8 * 4 }, //us { "UT-8", -8 * 4 }, { "DENV", -7 * 4 }, //us { "UT-7", -7 * 4 }, { "CHIC", -6 * 4 }, //us { "UT-6", -6 * 4 }, { " NYC", -5 * 4 }, //us { "UT-5", -5 * 4 }, { "CARC", -4.5 * 4 }, { "UT-4", -4 * 4 }, { " YYT", -3.5 * 4 }, { "BRAZ", -3 * 4 }, //rioj ? { "UT-2", -2 * 4 }, { "UT-1", -1 * 4 }, { " UTC", 0 * 4 }, // !!! index now 18, default = UTC_INDEX { "LOND", 0 * 4 }, //eu0 { "PARI", +1 * 4 }, //eu1 { "UT 1", +1 * 4 }, { "ATHN", +2 * 4 }, //eu2 idx22 { "UT 2", +2 * 4 }, { "MOSC", +3 * 4 }, //might move to EU? { "UT 3", +3 * 4 }, //just in case { "IRAN", +3.5 * 4 }, { "ARAB", +4 * 4 }, { "AFGH", +4.5 * 4 }, { "PAKI", +5 * 4 }, { "INDI", +5.5 * 4 }, { "NEPL", +5.75 * 4 }, { "BNGL", +6 * 4 }, { "MYAN", +6.5 * 4 }, { "THAI", +7 * 4 }, { "CHIN", +8 * 4 }, { "TOKY", +9 * 4 }, { "ADEL", +9.5 * 4 }, //aus { "DARW", +9.5 * 4 }, { "SYDN", +10 * 4 }, //aus { "BRIS", +10 * 4 }, { "NOUM", +11 * 4 }, { "WELG", +12 * 4 },

OK, another weekend, another firmware build ;-)On this one I am 'experimenting' a little with some slightly less usual stuff (meaning different 'refresh rates' of the two lines of the display, which explains some of the extra tests that I had to do especially to check the CPU usage), and we do the very first 'foray' into some astronomical features.So initially a very brief talk on that astronomical subject - all 'human-defined time' was initially exclusively based on astronomical elements so this is in some way a 'return to the origins'. As we all know our normal/basic units of time are based on solar time - and 'by convention' that is split into units of 24 hours / 60 minutes / 60 seconds (today however 1 second is officially defined in an atomic non-astronomical way). However the solar time is not the only possible way - there are also moon-related calendars but far more interesting is the 'sidereal time' - which basically replaces the sun as the 'reference point' with distant stars, and which was used as accurate time-reference (of course, in very restricted circles of initiated people) more often than most people believe!The first interesting change is obviously the length of a 'full rotation' - as it is better displayed/explained atthe rotation is shorter than one day - basically after about 23h:56m:04s (those are normal/atomic seconds) the rotation in respect to the stars is complete - and that is one 'sidereal day'. The first problem from here is that we can also define 'sidereal hours/minutes/seconds' in the same 24/60/60 ratios - but obviously the 'sidereal second' will be slightly smaller (or 'faster') than the normal 'solar/atomic second! (this point will become important later in the post).However there is a very interesting side-effect of moving from solar time to sidereal time - mainly that with very simple devices (and a very clear sky, and without moving the observation point) it was possible to keep very, very accurate time - that explains why Harrison was using Sirius (and basically sidereal time) as his 'time reference' when calibrating his famous clocks!This advantage also becomes very clear once you start calculating the small 'variations from the mean' in different astronomical times - the 'mean cycle' is pretty well defined for all of the 3 main references (stars/sun/moon), however the cyclic small variations are quite very different in range - the 'equation of equinoxes' is what defines the variation (from the mean) in 'sidereal time' - and that one is pretty much in the range oftoat any given time - so the mean sidereal time is always pretty accurate (see also Approximate Sidereal Time - Naval Oceanography Portal ).The variation in the solar time (and the precise actual moment of the solar noon) is given by the 'equation of time' - which however is generating over one year a cyclical variation in the range of aboutto- so almost 1000 times more variation than in the case of sidereal time - and you now can see why Sirius was a much better 'time reference' for Harrison than the actual sun! (see also Equation of time - Wikipedia, the free encyclopedia And what about the moon? Well, while the 'mean cycle' is reasonably precise over many thousands of years (and we have seen a cheap marketing contest among very expensive mechanical watches on which one has the more precise MEAN lunar cycle), the actual reality is that cyclical perturbations on the moon are the absolute worst in this group - with aboutof full variation from the minimum to the maximum - so claims from IWC, Lange and UN (see http://ulyssenardin.watchprosite.com/show-forumpost/fi-13/pi-3426876/ti-556016/s-0/ ) should be taken as 'lunar precision somewhere under 24 hours'! (which to be honest is still impressive in a mechanical watch, but is so far from 'the real thing' :-d ).The above order of 'implicit precision around some average value' is basically reversed when we talk about the amount of calculations needed to correct those values and achieve a very high precision - with basically a large amount of complex calculations needed in order to bring the precise sun and moon times in the range of just a few seconds (as the mean sidereal time already is). As a side-note - high-precision calculations for actual sunrise and sunset times in arbitrary places on Earth are also pretty-complex :-(.This will also explain why from the above calculations sidereal time was the only one which could be done in a very, very restricted amount of code and without any use of floating point and yet with some decent accuracy (in the same range as the accuracy of the watch itself) - and as a result I was able to add a decent version inside the WorldTime/DST firmware - from which I still had to remove some debug and duplicated features, and even in that context it was still not possible to have that AND a way to manually set the longitude for which sidereal time is calculated! As a result the firmware does two smart things:- it can display (not at the same time :-d) TWO sidereal times - it always can do Greenwich mean sidereal time (GMST) but ...- in case a certain configuration information (the local longitude) is written into a special flash region it defaults to the calculation of the local mean sidereal time (LMST) for that longitude! (and with a button press can toggle from GMST to LMST)!Note that both the times above are MEAN sidereal times - so an error of at most 1.1 seconds is to be added to whatever the error is in the watch-time itself b-). To underline that fact the symbol used to signal that sidereal time is active is the AVG one at the bottom - it will be steady for the possibly-local sidereal time and blinking for GMST, will toggle with the bottom-right button and will be turned automatically OFF at most one minute after leaving SIDER mode!Another unusual trick is the actual display of values over 19:59:59 - the bottom line does not have a full digit for the very first position, just one single segment which can be either off (a zero), on (1) or can blink - and that marks in this version an ultra-economical display of the value 2 :-d. The current implementation is also probably only going to work for the next 50 years or so, and the accuracy will be influenced by future leap seconds - see Leap second - Wikipedia, the free encyclopedia ! (but there is now a setting for that in the INFO data).A very good site to check the precision of the displayed sidereal time would be- it is using atomic time and the 'full astronomical correction' so we should test the watch against that site (and please report back if you see more than 2-3 seconds of error while your time is correctly set)!A somehow better-looking page isbut that applet seems to start with the correct calculations but in a (rather short) time it 'drifts away' since it ticks inside your browser in 'solar seconds' instead of 'sidereal seconds' - which brings us to the other unusual thing in this recent change to the WorldTime/DST firmware - when the sidereal time is active on the bottom line and normal seconds on the top line you can see with your eyes how those are not updated at the same time and tick at ever-so-slightly different speeds - with the 'sidereal seconds' moving slightly faster - so that at about 365.25 normal seconds you have about 366.25 sidereal seconds (which is the base sidereal ratio - in one year the earth rotates one more time against a distant star reference once you take into account that it has completed 365.25 rotations around itself and one long rotation of 1 year around the sun) ;-).Other small changes in the WorldTime/DST firmware:- small fixes for wrong values in DST data for US and Australia;- the 'hour beep' flag has now 3 possible values - 0 (off), 1 (short 1-beep) and 2 =(meaning that the repeater is automatically activated at full-hour - that is basically 'eating' something like only 8 bytes of so since the rest of the repeater code is already there).There has been a small change in the timezone-related code in the 'bluerobin stopwatch' firmware (UTC should not have DST) and both the 'bluerobin stopwatch' and 'data-logger' firmware have been bumped to RC3 since I have re-compiled all versions in a compiler configuration heavily optimized for minimum size! (and generally we now have to test all those new RC3 versions with all the features and on the longer term since some internal things have dramatically changed as a result of those supplementary compiler optimizations).And in the end a quick reference to power consumption - I can only measure (with some margin of error) the CPU USAGE and not the actual power consumption, BUT in the Texas Instruments original PDF manual there was a list on the actual power subject, with a very wide range from one extreme to another - from time/date mode listed around 27.7 months of battery life (which is now probably closer to 26-24 given the thermo-compensation) down to an extreme 8 days of continuous SimpliciTI SYNC and only 2 days in continuous SimpliciTI ACC !!! The stopwatch mode is also a serious consumer in the first 20 minutes (when the 1/100 of seconds are shown and some parts of the display are updated 100 times each second), but after that it gets to a decent level - and the same decent level is also seen when the sidereal time is displayed on the bottom line - I would say certainly over 12 months of battery life even in this mode all the time (but that could also be 18 or even 24, unfortunately I do not have right now any way to precisely measure that). The CPU usage of course drops to normal soon (at most one minute) after you exit sidereal time.Thehave not been changed and can be found at:The(still 3 files right now in each archive, might later become 4 with the full ASTRO firmware) can be found at:And finally the timezones currently defined in the two firmware versions which have them - that is needed only if you want to write the persistent configuration in the INFO flash as described in the post at:(there are two separate lists, first for the 'only timezones' - or just manual DST - bluerobin stopwatch firmware, the second one for the full 'WorldTime/DST firmware)!