Skip to main content

ESPCLOCK4 - A Rethink On Tick Pulse Generation

Having dabbled recently with PWM (Pulse Width Modulation) for motor control, it struck me that maybe the same technique can be applied for pulsing the Lavet stepper motor in the analog clock.

Just a recap. The Lavet stepper motor within the analog clock is design to function at ~1.5V. However, the output on the ESP8266 and ESP32 is 3.3V, and in ESPCLOCK3, the ATtiny85 is powered at ~3V. For reasons I don't fully understand, the pulse width needs to be as long as 100ms in this case, otherwise the clock will not tick reliably. This also leads to high power draw, because higher voltage + longer pulse width. In contrast, the original clock signal is 32ms pulse width at ~1.5V (which can go as low as ~1.1V since it is running on a normal AA battery).

So in ESPCLOCK3, a diode bridge is introduced, where 2 diodes in each direction drops the 3V output by the ATtiny85 down to ~1.8V (3V - 0.6V x 2), which worked remarkably well in reducing the power draw and making the clock tick with 100% reliability.

Much like PWM in DC motor control, the idea is to eliminate the diode bridge and instead output a PWM modulated pulse signal, which should reduce the effective voltage to the clock.


With some experimentation, the ideal duty cycle of the PWM was found to be 62.5%. The output is 1.25ms on, 0.75ms off, repeated 20 times (for a total of 40ms). Both 62.5% and 40ms were found to be lower bounds for reliable operation.

The 62.5% duty cycle surprised me, because from my naive calculation, for an effective voltage of say, 1.5V, the duty cycle should be 1.5 / 3.3, which is 45%. 62.5% duty cycle implies an effective voltage of ~2V, which is much higher than I expected. I suspect my naive formula for calculating the duty cycle is wrong.

It was quite easy to modify the test program to output PWM pulses. This macro was added:

// Pulse given tickpin - 40ms duration = 20 x (1.25/2ms) PWM => 62.5% duty cycle ~ 2V
#define X_TICK_PIN(pin) \
    I_MOVI(R0, 20), \
  M_LABEL(_PULSE_##pin), \
    X_GPIO_SET(pin, 1), I_DELAY(10000), \
    X_GPIO_SET(pin, 0), I_DELAY(16000-10000), \
    I_SUBI(R0, R0, 1), \
    M_BGE(_PULSE_##pin, 1)

The macro is then used in the ticking logic:

    // Decide which pin to tick
    X_RTC_LOAD(TICK_PIN, R0),                           
    M_BGE(_HANDLE_TICKPIN2, 2), 
    // Pulse tick pin 1
    X_TICK_PIN(TICKPIN1),
    X_RTC_SAVEI(TICK_PIN, 2),
    I_HALT(),
  M_LABEL(_HANDLE_TICKPIN2),
    // Pulse tick pin 2
    X_TICK_PIN(TICKPIN2),
    X_RTC_SAVEI(TICK_PIN, 1),
    I_HALT()

I was pleasantly surprised this worked very well. It made the clock tick reliably without the diode bridge. Even better, this approach brought the power draw from 1.37mA down to 1.13mA, so it's a keeper!

Comments

  1. What would the code equivalent for X_TICK_PIN be if I want to drive the clock using PCA9685 https://www.nxp.com/products/power-management/lighting-driver-and-controller-ics/ic-led-controllers/16-channel-12-bit-pwm-fm-plus-ic-bus-led-controller:PCA9685 via ESP32 ?

    ReplyDelete
    Replies
    1. Apologies, but I am not mighty familiar with the PCA9685. But it's just a standard PWN signal. As long as you can program it to output a PWN signal on one of its pins, you can play around with the duration and duty cycle of the signal. It doesn't take long to find the approximate duration/duty-cycle to use for a particular clock. It takes longer to home in on the right values for reliable operation. Sometimes slippages will occur after 10 or 20 minutes, so it is not sufficient to let the clock run for only a few minutes.

      Delete
    2. Will try that next week. Was being lazy and trying to get the conversion of your X_TICK_PIN code to more standard PWM code :)

      Delete

Post a Comment

Popular posts from this blog

Update: Line adapter for Ozito Blade Trimmer

Update (Dec 2021): If you access to a 3D printer, I would now recommend this solution , which makes it super easy to replace the trimmer line. I have been using it for a few months now with zero issue.

Cooling mod for the X96 Air

I realized after my Ugoos box died that overheating is a big problem with cheap Android TV boxes. A teardown of the Ugoos box shows that it does not have any heatsink or fan at all!  The X96 Air does have a heatsink, but the heatsink is located at the bottom of the casing with no ventilation. In this default configuration, with the ambient room temperature at 25c and playing a 1080p video, I was seeing the CPU temperature at 67c. I drilled a couple of holes at the bottom of the casing. The CPU temperature fell to 59c with the box raised about 2cm with plastic blocks. I retrieved an old 5V laptop fan: Then cut and strip away a spare USB cable: Solder the red and black wires on the fan and the cable: Secure the fan to the bottom of the casing with double-sided tape, then plug the fan into the box's USB connector. Here's a view of the box with some 3D-printed risers installed at the bottom to give the mounted fan sufficient clearance: The CPU now runs at 43c, a huge drop from the ...

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 ...