I don't have much experience with mechanics, so I had to apply the simplest way to have the clock hand, which is 9.12" long, stable enough and free from nodding (by the way, the hand is made of the longest sewing needle that I could find). Three were more requirements:
1. high transmission ratio (simple stepper without reduction won't work)
2. low profile of the assembly
3. low voltage operation
4. if it's a brush DC motor, the encoder feedback on the motor (high-speed) side of the gear train
The best match was the motor JGY-370 DC 6V, but it was not available with the high enough transmission ratio (it was 10 rpm). So I ordered the motor GW370 also (with 1 rpm), and used the motor only from the first to the second unit, and everything was fine. The motor works well at lower voltage, even at 1.5 V - somehow slower, but it turned out to be good, as it enabled the more precise encoder control. Both motors were ordered from Banggood.
I was surprised to see that the Hall Effect encoder does not count one step per turn, but eleven. It caused some problems, as the motor controller could not assure fast and precise enough stop after one turn, even in brake mode. So the firmware had to be more complex, as it had to follow and take into account the angular error after every phase of the motor operation. After some experimenting, the firmware was totally resistant to all the whims of the mechanical assembly and free of the error accumulation.
To calculate the transmission ratio, I had to count teeth on every gear. There are 5 pairs of gears, with the following transmission ratios:
1. 1 : 25 25 (worm gear)
2. 10 : 30 3
3. 10 : 30 3
4. 10 : 30 3
5. 10 : 45 4.5
total ratio: 1 : 3037.5
turns/day: 3037.5 : 365 = 8.3219178
seconds/turn: 86400 : 8.3219178 = 10382.222
So the motor has to make one turn at every 10382.222 seconds, but this was rounded to 10382.2 sec/turn. However, the MEMS oscillator IC (which is SIT1534AC-J5-DCC-00.001D) outputs 1 Hz signal, the firmware perform counts to 10382 every time except at every fifth case, when it's 10383.
Of course, MCU sleeps between 1 Hz ticks, and this looked simple at the beginning - I was unlucky enough to have a bunch of MCUs PIC30F3012's, and used them. I didn't know that they have a terrible bug in wake-up-from-sleep procedure. Believe it or not, it couldn't return to the address from which it was invoked, but you had to do some acrobatics. You had to perform CALL to SLEEP command from the very last address available at the address space, which is 0x1FC0 in this case, and to let the MCU detect and perform the Address Error Trap Service Routine (TSR). You should also prepare the service for the Address Error Trap TSR, so that it replaces the invalid return address saved on the stack with the address of the instruction immediately following the CALL instruction at 0x1FC0. This ensures that the device continues executing the correct code sequence after waking up from Sleep mode.
It's awful, but it works. In almost one year of operation, it did not fail, but there were two suspicious stalls, when I had to use manual commands (+/- hand move) to wake the device...Read more »