Movement for The Present clock from The Present. Kickstarter here...
https://www.kickstarter.com/projects/scottthrift/the-present-day-moon-year
- Uses proven existing UTS 24h mechanical gearbox gears and lavet motor
- Can be software configured at programming time for 24h, lunar month, or year period
- Autoset feature lets user automatically move the hand to the correct time position when commissioned in the field
- Uses a very accurate internal RX8900 real time clock (RTC) chip with temperature compensation that is good to +/-3ppm
- Uses cheap and common ATTINY25 microcontroller (MCU) chip
- Extremely low power - can run for decades or more on 2xAA batteries
Press the button when it is solar noon at the location where the clock will be used. The hand will make a full rotation to indicate that it is now set. For now on, the hand will indicate the current time of day where pointing up to the "noon" position is solar noon and pointing down is solar midnight.
Press the button when you are ready to start using the clock. The hand will make a full rotation and then will continue to the current time. Since the time of lunar month and year are the same every where on Earth, no further input is required. Use in places with non-terran synodic periods is not supported in this version.
A version of the clock with an inverted face is available on request for use below the equator.
Should the environment ever become out of sync with the clock hand and it is not possible to correct the environment, you can manually adjust clock hand position using the blue thumb-wheel to bring the two into agreement.
We start with a UTS gearbox that rotates an hour shaft once every 24 hours with a "step" once per second (86,400 steps per rotation). We remove the gear that drives the hour shaft and then we glue the now free hour shaft to the minute shaft. This results in an hour shaft that rotates once every 3600 steps. We connect our single hand to this combined hour-minute shaft.
This change in gearing reduces the number of ticks needed for a full rotation by 60 fold. This is good since ticks use power and make noise. This also means we can move to our autoset location 60x faster than we would have been able to if we had left the original gearing in place.
The only real downside to this modification is reduced torque on the hours shaft, but since we know that the minute shaft must be strong enough to be able to rotate a minute hand, this is not a problem - especially since we no longer have to rotate the extra gears that would have also been driving the hours shaft.
The gearbox is driven by a lavet-type stepper motor. This motor is normally energized with a 1.5V signal across the leads for 50ms which causes the motor to rotate about 1/4 turn. When the coil is de-energized, the motor then rotates an additional 1/4 turn. The combination of these two phases results in a 1/2 turn "step" of the motor. The polarity of the 1.5V across the motor coil is reversed between each alternating step.
Ticks are periodically generated by the RTC chip. This tick period is programmed into the RTC at start up by the MCU based on the set mode according to this table....
| Mode | 1 Tick every | Period for a 3600 step full rotation |
|---|---|---|
| Day | 24 seconds | 1 day |
| Moon | 11 minutes 48.734 seconds | 29.53059 days |
| Year | 2 hours 26 minutes 6 seconds | 365.25 days |
Upon receiving a tick signal from the RTC, the MCU will...
- Wake from deep low-power sleep
- Energize the lavet coil (polarity alternates on each phase)
- Sleep for 50ms to give the lavet rotor a chance to rotate to the intermediate position
- Wake and de-energize the lavet coil and renable to pull-up
- Go back to deep sleep to wait for the next tick
This cycle results in two movements of the lavet rotor which result in the hand moving 1/3600th of a rotation around the clock face. This step size is small enough that it is not visible to the naked eye.
We use the ~INT signal from the clock chip to transmit the ticks to the MCU. The clock chip can only pull this line low, so we use a pull-up resistor in the MCU to keep it high until the clock pulls it low. When the clock does pull it low, it holds it low for 7.813 ms and we can not control this time. To avoid wasting power though the pull-up during this period, we disable the pull-up for the first 16ms of the time when we are waiting for the motor to rotate.
We use the MCU's built-in watchdog timer to wake us up after this initial 16ms snooze, and then again 36ms later when it is time to de-energize the lavet coil. The watchdog timer only has a fixed number of possible timeouts so we picked these values to work around the fixed time periods of the ~INT signal and the lavet rotation.
The lavet motor is typically driven by alternating the polarity of a single 1.5V AA battery. We need 2xAA to give us >3V needed to run our chips (both require at least 1.8 volts to run reliably), so we connect one of the motor's leads to the midpoint between the two batteries. We then drive the other lead to either 0V or 3V using an MCU IO pin. This results in the motor seeing either +1.5V or -1.5V across its leads so it is happy. It also means that each battery is only driving the motor on every other step, which further extends battery life.
The maximum speed the motor can reliably be driven at is 1 step every 100ms (each step consists of an energized and non-energized phase, each about 50ms). This means that it takes about 6 minutes for the hand to rotate all the way around the face at full speed (3600 steps * 100ms/step). We use the MCU's internal watchdog timer for timing these 50ms phases, and that timer is only accurate to +/-10% so the 6 minute time period is only approximate.
- The current UTC time is stored in the MCU's EEPROM memory when it is initially programmed in the factory.
- When it boots up initially after programming, it reads this time from the EEPROM and then uses it to set the RTC.
- The MCU then goes into deep sleep while waiting for a button press to wake it up. The RTC now continues to internally keep the current time as long as there is power.
- When the button is pressed, the MCU wakes up and does a full speed victory lap around the clock face to indicate to give visual feedback to the user. This takes about 6 minutes.
- The MCU then sleeps until the next tick from the RTC.
- On waking, the MCU asks the RTC for the current UTC time. It uses this value to figure out where it is in the current 3600 step cycle around the clock face it should be
- The MCU moves the hand to this location at full speed. Since it only takes 6 minutes to get to any hand position, and we know that moon and year ticks happen farther than 6 minutes apart, we do not need to account for time changes that happen while we are autoset positioning the hand.
- Once the hand reaches the correct location, the MCU sleeps and waits for the next tick from the RTC to move the hand forward one tick. It repeats this until either the battery voltage drops to <1.6V or the heat death of the universe - which ever comes first.
Since the hand position in day mode depends on the longitude where the clock happens to find itself on Earth, knowing the UTC time is of no use to us here. Therefore instead, we have the user press the button at solar noon.
- The user unpacks the clock and patiently waits until local solar noon.
- At the precise moment the sun crosses the meridian, the user anxiously presses the button.
- This wakes the MCU, which immediately reads the current UTC time from the RTC and then does a full-speed victory lap (as above) to give visual feedback, coming to rest again at the noon position on the face.
- The MCU sleeps while it waits for a tick from the RTC (which will come within 24 seconds).
- The MCU again reads the current time from the RTC and computes how many 1/3600th of a rotation steps are needed to bring the hand to the correct position.
- The MCU steps the hand at full speed the the lesser of (1) the number of steps needed to get to the correct position, or (2) 200 steps.
- The MCU sleeps and waits for the next tick.
- On waking, the MCU updates the target location forward 1 step and goes back to #6 to continue the race to catch up to the correct position.
When the hand reaches the correct position, the clock goes into normal run mode where it moves the hand advances one step per tick forever and ever.
The reason we only do 200 steps per tick when trying to catch up is so that we never miss a tick which could give us an offset error. Even though the maximum offset error would be visually undetectable, it would still bother us.
The ATTINY uses <0.1uA while sleeping and it spends the vast majority of its life sleeping (depending on mode).
The RX8900 uses on average ~0.7uA at 3V.
Total constant current draw is ~1uA between ticks.
Each tick additionally consumes an average of ~3.5mA over ~50ms, for a total of about 6.1mW. Remember that each tick only draws on one of the two batteries.
(1 rotation/day)/(3600 ticks/rotation) = 3600 ticks/day (3600 ticks/day) * (365 days/year) = 1314000 ticks/year
(1314000 ticks/year) * (50 ms/tick) * (3.5 mA)
(2600 milli amp hour / battery)
(1uA constant draw)
Run time = ~35 years
No point in doing the other modes since we are already way past where battery capacity is the limiting factor on lifetime!