Vetinari's Clock

[abecedarian 330]

I know this is oriented at an analog clock, but would it be any less disconcerting if applied to digital?

 

I know I'd be left wondering if a set of LED's sat reading "09:14:48" for a bit then suddenly counted up to "09:15:30" only to pause for a bit then up to "09:16:00"... or even ran backwards for a bit.

[enl 227]

Did something similar for the classroom I teach in. Clock runs at about 2/3 speed for the first 30 min, then speeds up to about 4/3 speed, with about a 5 minute smooth change in rate. REALLY messes with the students. You thought class seemed to drag before.....

[abecedarian 330]

Did something similar for the classroom I teach in. Clock runs at about 2/3 speed for the first 30 min, then speeds up to about 4/3 speed, with about a 5 minute smooth change in rate. REALLY messes with the students. You thought class seemed to drag before.....

I'm a masochist. I'd run it fast, first, then slow it down at the end.

[rockets4kids 204]

Funny you should mention this -- a digital version of Vetinari's clock has been on my back burner for a while now.  ;-)

[enl 227]

I'm a masochist. I'd run it fast, first, then slow it down at the end.

migh be the next version....

[ILAMtitan 86]

If the motor can be reliably controlled at different speeds, probably even the regular tick motion could be created (although more silent), and thus also the irregular tick.

But currently, stopping and starting the motor will cause step-loss which of course is not an option. If this can't be overcome, i.e. the motor needs to keep running as fly-wheel, indeed only an irregular sweep is feasable, but I think this still may be interesting to notice.

This project uses a solenoid driven clock, not a motor driven one, so the code will be significantly different.  You'll have to generate a steady PWM value, and then vary it depending on the speed you want the clock to run.  I'd love to see it if you get it working.

 

 

 

The current, voltage, and switching speeds are so low that you can use practically any transistor in this project.  The only requirements are that you have two NPN and two PNP transistors.

 

You can even get away without the transistors, driving the coil directly from the MCU pins.  I wouldn't recommend this on the MSP430, but people have done it.  With the small, cheap mechanism I am using, the current required to drive the mechanism does not exceed the absolute maximum values.  Nonetheless, I am using an H-bridge just for safety.  For MCU's with greater drive current, there is absolutely no need for external drive circuitry, so if you have any PICs or AVRs laying around, it would be best to just use those.

 

One thing I have wondered is whether you could use multiple GPIO pins to distribute the load.  Using two GPIOs on each side (a total of four pins) should bring things within recommended values.  Does anyone know of the issues involved in doing this?

I used the transistors as a method to get bidirectional drive on the solenoid, not really as a current delivery mechanism.  I don't really see any issue with using multiple pins to fan the current load out, I just don't see a good way to get around the directional driving for a clock mechanism.  if you set both bits in PnOUT at the same time, it should propagate to the pins at the same time (please don't quote me on this though).

 

 

 

Funny you should mention this -- a digital version of Vetinari's clock has been on my back burner for a while now.   ;-)

I like the idea of a digital one too.  Maybe I'll integrate this into one of my other clock designs that are in the works too.

[rockets4kids 204]

I used the transistors as a method to get bidirectional drive on the solenoid, not really as a current delivery mechanism. 

 

 

It sounds like you are unaware that you can implement an H bridge by driving between two tri-state pins.

[ILAMtitan 86]

It sounds like you are unaware that you can implement an H bridge by driving between two tri-state pins.

 

Hmmm, that hadn't even crossed my mind.  I'm not a huge fan of tri-state implementations due to their complexity, but I would love to see an example.  Do you of any on the 430 (my googling has failed me)?

[rockets4kids 204]

Hmmm, that hadn't even crossed my mind.  I'm not a huge fan of tri-state implementations due to their complexity, but I would love to see an example.  Do you of any on the 430 (my googling has failed me)?

 

It the the same principle used by charlieplexing, only a simpler implementation.  Take any two GPIO pins in output mode.  Pull one high and the other low and current will flow between them.  Reverse the settings and current will flow the opposite direction.  Set the pins to input mode and no current will flow.  You can easily test this with a two-color bi-directional LED or two individual LEDs.

 

Be careful of current consumption.  Draw too much current (or worse, short the pins) and you are almost guaranteed to fry them.

[grahamf72 169]

It the the same principle used by charlieplexing, only a simpler implementation. Take any two GPIO pins in output mode. Pull one high and the other low and current will flow between them. Reverse the settings and current will flow the opposite direction. Set the pins to input mode and no current will flow. You can easily test this with a two-color bi-directional LED or two individual LEDs.

 

Be careful of current consumption. Draw too much current (or worse, short the pins) and you are almost guaranteed to fry them.

Also, because we are talking about an inductive load, it is also essential to have each pin protected by reverse biased diodes from the pin to each power rail to absorb any transient spikes. When switching coils, it's not hard to get transients in the +/- tens or even hundreds of volts which could easily be fatal to our little 430 mcu's. Common bipolar transistors as used in the original circuit will generally handle these transients no problem.

 

 

Sent from my iPad using Tapatalk

[rockets4kids 204]

Ditto on the flyback warning.  I have read that voltage spikes can have a cumulative effect, so that even if your circuit works fine initially, it could easily start showing odd behavior or outright fail down the road.

[lastaid 15]

can confirm the voltage spikes, build one of those for a friend, broke after one and a half month.

[rockets4kids 204]

can confirm the voltage spikes, build one of those for a friend, broke after one and a half month.

 

Were you using an external h-bridge or just the MCU pins?  Did the entire MCU get fried?

[lastaid 15]

used tristate mode, only the pins got fried. one of the bigger problems is that sometimes the power of the mcu doesn't cut it [ or the delay between "move clockhand" is just to short ]. in this case it does not move the clockhand. unfortunatly this only occured after a few weeks ... don't think it was the batteries. 

 

will do a version with a proper hbridge.

[rockets4kids 204]

When I was developing mine, I noticed that both pulse duration and operating current can cause this.  If your current limiting resistor is too large or your pulse is too short you will see this behavior.