Skip to main content

ESPCLOCK4 - Deciding which direction to traverse to catch up with the present time

For more obvious cases eg. clock time is 12:05 and present time is 12:00, we don't have to think too hard to decide which direction to take the second hand to match up the two times.

However, suppose the clock time is currently 12:00, and the present time is 6:00. We can move the second hand forward 8x, or backwards 4x. Which direction will result in quicker synchronization of the 2 times?

For both directions, the number of seconds to traverse is 6 x 60 x 60 = 21600 seconds.

If we take the forward direction, the time taken to traverse half the number of seconds i.e. 10800 is 1350 seconds. However, in that time, the present time would have advanced by the same amount, so the number of seconds left to traverse would be 10800 + 1350 = 12150 seconds. If we do this iteratively, we would find the total time required to achieve synchronization is 3085 seconds, with 4 seconds left to catch up.

If we take the reverse direction, the time taken to traverse half would be 10800 / 4 = 2700 seconds. However, the present time would have advanced by the same amount, so the number of seconds left to traverse would be 10800 - 2700 = 8100 seconds. If we do this iteratively, the total time required to achieve synchronization is 4320 seconds, with 1 second left to catch up.

So in this case, traversing in the forward direction will result in  quicker synchronization.

The Python code for performing this calculation is:

def calc_sync_time(direction, duration, speedup):
  result = 0;
  while(duration > speedup*2):
    half = int(duration/2)
    interval = int(half / speedup)
    result += interval
    duration = duration - (interval * speedup) + (interval * direction)
  result += int(duration/speedup)
  print(("Fwd","Rev")[direction == -1], "=", result, duration%speedup)

fwd_duration = 7*60*60 + 2
calc_sync_time( 1, fwd_duration, 8)
calc_sync_time(-1, (12*60*60) - fwd_duration, 4)

With a little trial and eror, I can determine that the dividing line is when fwd_duration = 7*60*60+2 = 25202 eg. when clock time is 4:59:58 and needs to sync to 12:00:00. The forward and reverse timing in this case are both exactly 3600 secs i.e. exactly 1 hour. 

So in my clock logic, I can decide to move the second hand forward if fwd_duration < 25202, and go in reverse if fwd_duration >= 25202.

The logic to calculate the fwd_duration between 2 times (hh1:mm1:ss1) and (hh2:mm1:ss2) is:

d1 = (hh1*3600) + (mm1*60) + ss1; 
d2 = (hh2*3600) + (mm2*60) + ss2; 
fwd_duration = d2 - d1;
if fwd_duration < 0: fwd_duration = (12*60*60) + fwd_duration;

However, as the ULP is 16-bit, signed number range between -32767 and 32768, so the above operation is out of range (12*60*60 = 43200), unless we cook up some 32-bit integer math code.

Another way is decompose everything into even simpler operations:

def time_diff(hh1, mm1, ss1, hh2, mm2, ss2):
  ss3 = ss2 - ss1;
  if ss3 < 0:
    ss3 = ss3 + 60
    mm1 += 1
    if mm1 == 60:
      mm1 = 0
      hh1 += 1
  mm3 = mm2 - mm1
  if mm3 < 0:
    mm3 = mm3 + 60
    hh1 += 1
  if hh1 >= 12: hh1 -= 12
  hh3 = hh2 - hh1
  if hh3 < 0: hh3 = hh3 + 12
  return [hh3, mm3, ss3]

def time_less_than(hh1, mm1, ss1, hh2, mm2, ss2):
  if hh1 < hh2: return True
  if hh1 > hh2: return False
  if mm2 < mm2: return True
  if mm1 > mm2: return False
  return ss1 < ss2

print(time_diff(11, 55, 10, 0, 10, 20))

print(time_less_than(7, 0, 2, 7, 0, 2))

time_diff() is able to compute fwd_duration in [hh, mm, ss] format.

time_less_than() tells you whether one duration given in [hh, mm, ss] format is less than another. Our previous threshold of 25202 secs is [7, 0, 2] in [hh, mm, ss] format.


Popular posts from this blog

Adding "Stereo Mixer" to Windows 7 with Conexant sound card

This procedure worked for my laptop (Thinkpad E530) with a Conexant 20671 sound card, but I suspect it will work for other sound cards in the Conexant family. I was playing with CamStudio to do a video capture of a Flash-based cartoon so that I can put it on the WDTV media player and play it on the big screen in the living room for my kids. The video capture worked brilliantly, but to do a sound capture, I needed to do some hacking. Apparently, there was this recording device called "Stereo Mixer" that was pretty standard in the Windows XP days. This allowed you to capture whatever was played to the speaker in all its digital glory. Then under pressure from various organizations on the dark side of the force, Microsoft and soundcard makers starting disabling this wonderful feature from Windows Vista onwards. So after much Googling around, I found out that for most sound cards, the hardware feature is still there, just not enabled on the software side. Unfortunately, to

Attiny85 timer programming using Timer1

This Arduino sketch uses Timer1 to drive the LED blinker: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 /* * Program ATTiny85 to blink LED connected to PB1 at 1s interval. * Assumes ATTiny85 is running at 1MHz internal clock speed. */ #include <avr/io.h> #include <avr/wdt.h> #include <avr/sleep.h> #include <avr/interrupt.h> bool timer1 = false , led = true ; // Interrupt service routine for timer1 ISR(TIMER1_COMPA_vect) { timer1 = true ; } void setup() { // Setup output pins pinMode( 1 , OUTPUT); digitalWrite( 1 , led); set_sleep_mode(SLEEP_MODE_IDLE); // Setup timer1 to interrupt every second TCCR1 = 0 ; // Stop timer TCNT1 = 0 ; // Zero timer GTCCR = _BV(PSR1); // Reset prescaler OCR1A = 243 ; // T = prescaler / 1MHz = 0.004096s; OCR1A = (1s/T) - 1 = 243 OCR1C = 243 ; // Set to same value to reset timer1 to

Hacking an analog clock to sync with NTP - Part 5

This is how it looks after I have put everything together. The Arduino sketch is available here . The 2 jumper wires soldered to the clock mechanism are connected to pins D0 and D1 on the ESP-12 (in any order). When the device first boots up, it presents an access point which can be connected to via the PC or smartphone. Once connected, the captive portal redirects the web browser to the configuration page:     A custom field has been added to the WiFi configuration page to enter the current clock time in HHMMSS format. Try to set the clock time to as close to the current time as possible using the radial dial at the back of the clock so the clock will have less work to do catching up. In the config page, the HTML5 Geolocation API is also used to obtain your current location (so if your web browser asks if you would like to share your location, answer "yes"). This is then passed to the Google Time Zone API to obtain the time and DST offset of your time z