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.

ESPCLOCK1 / ESPCLOCK2 / ESPCLOCK3 / ESPCLOCK4

Comments

Popular posts from this blog

Cooling mod for the X96 Air #2

Previously, I added a USB cooling fan to the X96 Air TV box . The problem with this mod is that the fan is always running, and it runs at full speed. Ideally, the fan should kick in only when the CPU temperature is above a certain threshold. It would be even better if there is a way to control the fan speed. Dan McDonald left me a comment pointing to his project on Github . He basically connected the fan to a USB relay that can be controlled by Python script. His project inspired me to make a similar mod that would make use of the spare D1 Mini boards I have lying around. The plan is to hook up the fan to a MOSFET (2N7000) and control it via PWM. Here's the very simple circuit: The code simply reads a single character from the serial port (0 - 9). 0 will turn the fan off, while 1 - 9 will generate a proportional PWM to drive the fan, with 1 being the lowest and 9 being the highest. Here's the Arduino code: #include <Arduino.h> void setup () { Serial . begin ( 9600 ...

Installing and customizing CoreELEC in X96 Air

I previously installed CoreELEC on another TV Box ( Ugoos X3 Pro ), which unfortunately died after only 9 months during the summer (due to the unit overheating, which I learned is a common problem for cheap Android TV boxes). So this time I purchased a X96 Air  (4GB/32Gb) and had to do the whole thing again. So this is a note-to-self in case I ever have to install CoreELEC again on some other device. Installation of CoreELEC is simple enough by following this guide . Basically, it involves downloading and writing the firmware to a microSD card using usbimager . Then insert the microSD card, reset the unit and hold the reset until the logo appears. The unit will then proceed to boot into CoreELEC. First thing is to connect to WiFi, then enable SSH. This allows me to login via ssh and execute: ceemmc -x from the terminal. This writes CoreELEC to the built-in eMMC storage, after which I am able to remove the microSD card and reboot the unit into CoreELEC via the built-in sto...

DC-DC Buck Stepdown Converter for ESP8266

I am working on a project that requires a step-down converter from 12V to 5V, that will then power a WeMOS D1 Mini. I saw this new mini buck converter based on the usual LM2596 MP2307 , so I thought I'd give it a try. Unfortunately, it didn't work. Although it is supposed to be able to supply up to 1.8A, the D1 Mini was not able to boot up. The 5V pin was being properly supplied, but the 3.3V pin measures at only ~1.3V. So I had to go back to my usual LM2596 module, which is much larger, but works to power the D1 Mini with a 12V source. Here's a great review of the mini buck converter I found while trying to figure out how to make it work. The fact that it has high quiescent current (~60mA) is also mentioned in a few other sources.