Jump to content
Sign in to follow this  
ILAMtitan

Vetinari's Clock

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×