fire station clock revival

[Simon]

A friend of my dad's has asked me to knock up a circuit for him that generates a pulse every 30 seconds to tick the mechanism over. now there is some help on the back in the form of a label that states that the clock coil should be fed between 170 and 270 mA. But I have no idea how long the tick should take.

I'm currently running on 100mS, it's giving a healthy clonk every 30 seconds-ish (it will take hours if not days of running to notice any drift, luckily the instruction time of a pic at 32.768 KHz divides into 30s with a whole number so in theory I can get it bang on). The coil resistance is about 14 ohms that for 270mA dictates 3V but as I'm driving from 4.5-4.8V and the voltage at 170mA is 2.38 I guess i can use "PWM theory" and half my pulse time from the ideal at the voltage that it would otherwise run at.

I'm hoping to make it battery powered for him with 3 batteries, with 100mS pulse that is 0.8mA per hour of ticks just for the clock. I don't know the capacity of AA batteries but that is 40ish days per A.

Has anyone ever played with this sort of stuff before ?

(oh and if you want one - the driver circuit that is I may be marketing it - who knows who else has "acquired" an old fire station clock).

The idea was that the clocks of which there were many in the same station were all connected in series and a single battery supplied the pulse power that was pulsed by a pendant operated switch. I guess this was in the days when timing circuitry was very expensive so it made sense for the timing to be central

[grumpydoc]

I guess this was in the days when timing circuitry was very expensive so it made sense for the timing to be central

Well, more that you want all the clocks on the station to show exactly the same time, synchronous clocks were also common in factories for the same reason.

[Simon]

true, these days we have sufficient accuracy and size to have multiple independent clocks with built in time keeping and know that they will stay dead accurate and "synchronized".

Now I'm trying to work out how long my code takes to execute as on 8192 instructions per second that's just over 122uS per instruction so i need to have a partial delay period in my timing sequence to allow for the code execution time and the time spent doing a 40mS output pulse (I've decided to lower it)

[Jon Chandler]

The same system was also used in schools to keep all the clocks synchronized. 

Wikipedia-Master Clock

[PA0PBZ]

Now I'm trying to work out how long my code takes to execute as on 8192 instructions per second that's just over 122uS per instruction so i need to have a partial delay period in my timing sequence to allow for the code execution time and the time spent doing a 40mS output pulse (I've decided to lower it)

Hmmm yeah, how about timer->interrupt->pulse?

The same system was also used in schools to keep all the clocks synchronized. 

Railways!

[Simon]

looks like i have a market that stretches a bit further than my dads friend.

how would interups help ? ok might be sliker but this is just a timed pulse, no multitasking

[PA0PBZ]

how would interups help ? ok might be sliker but this is just a timed pulse, no multitasking

It's not really the interrupt that helps, it's the hardware timer. You just set one of the timers in the pic to count to 30 seconds, and then let it generate an interrupt. In the interrupt routine you output the pulse and after that go back to sleep. No need to count instructions, the timer takes care of the period.

While you are at it, put a dipswitch in to set the timing to the most useful intervals, like 30 secs, 60 secs and whatever could be handy.

[Simon]

well I've not delved too deep yet but yes I'd like to make the variants for other timings. can the pic count to 30s on a 32.768 KHz clock ?

The problem I'll have with making other timings is I'll need to compensate for the fact that each 1/2 second cycle takes a certain amount of time and if I lower or increase the timing then that will alter the program run time, unless I really can count to 30S on one timer take but that is 245'760 counts which is well over the 16 bit or can it be prescaled ? it would need to be prescaled by at least 5

[PA0PBZ]

What pic are you using? I can have a look at the datasheet.
Your clock is 32.768 Khz?

[Simon]

12F615

32.768 clock crystal

[PA0PBZ]

I will have a look, but if you are running out of bits just count seconds and keep track of how many you counted 

[Simon]

yes but that is what I'm already doing although with 1/2 seconds, so that means adding program time overheads which screw up that last cycle if i want to do a changeable time delay as I'd need to keep adjusting it (not to mention testing it out)

[lewis]

If you have a PIC with the ECCP (enhanced capture and compare) module built in and a separate oscillator for TMR1, you can use the 32kHz crystal to run TMR1 and get the hardware to generate the pulse when TMR1 and the ECCP period register match. (Well, the match condition actually generates an interrupt so your interrupt routine consists of generating the 100ms pulse on whatever output pin). This way you don't have to worry about the instruction execution time at all. It enables you to make changes to your code later on without having to recalculate the instruction time again. You don't actually need the separate TMR1 oscillator, use the 32kHz crystal as the PIC's main oscillator and feed TMR1 with it if your PIC is not doing anything else that requires a faster clock.

If you don't have the ECCP module, then interrupts are mandatory for accurate timing. If you're manually checking the T0IF or TMR1IF bit in a loop to detect an overflow, it's virtually certain that your code will not check the bit at exactly the same time as the overflow occurs. This way, timing errors accumulate, especially if you're having to prime the timer on each overflow. With interrupts, you can be sure that the interrupt occurs bang on time every time. You still have to know the exact duration of the interrupt routine, but code changes become much easier and the timing is more reliable. But not as reliable as the ECCP module - definitely use it.

PIC12F1822 is a very good low cost 8-pin device, it's got everything in the world on it, and it's on par cost-wise with a 12F615. If you're being really tight, a 10F204 will do it, but do use the TMR0 interrupts to increment/decrement your timing registers, and don't prime the timer on overflow.

It sounds like you're not actually using the timers at all - manually incrementing or decrementing registers with INCFSZ or DECFSZ instructions can get pretty good accuracy,  but it's a hell of a lot of work. Also, one minor change to the code will bugger up the whole thing. And you MUST do it in assembler.

ECCP module - that's the way to go mate...

I designed an analogue clock movement for a local clockmaker years ago, it used a big stepper motor to drive the hands (his clocks are anywhere between 2-20 feet in diameter). It used the Rugby (now Anthorn) MSF transmission to set the time automatically, the clocks go on the side of buildings where setting them twice a year is impractical. In the event of a lost MSF signal, the clock had to keep accurate time all by itself indefinitely, and the ECCP module was essential. It was about 30 pages of assembler - that was before I knew C.

[Simon]

hm good points, I should learn interups I guess, yes I see now the counter just runs to when it hits the value it tripes the pulse and resets good plan.

I guess I need to look through my compilers guide, although I was planning on starting to use AVR's rather than invest more time in pics (getting fed up with the snobbery)

[PA0PBZ]

Well. looks like Lewis beat me to it. The 12F615 has the ECCP on timer 1, and it also has a prescaler of maximum 8. So you could set it to a 10 seconds period but it would be easier to just let the timer count 1 second and then increment a register till you have what you need, then output the pulse and set the register back to zero.

[Simon]

hm looks like i have a lot of learning, I might head over the AVR forum and start looking at the tutorials, in fact I recently read a very, very good tutorial on using timers that will probably do exactly what I want and I have some ATtiny13A's around so no difference to me (other than no one has done tutorials for pic's that are of the same quality as the ones done for AVR).

I only started using this pic setup as I have a current 2 minute (no precision) timer circuit and program done for work that I was adapting (not trying to start a pic/avr war - promise  )

[PA0PBZ]

It's only because you mentioned the pic in your first post that I continued on that, and the whole timer idea is just general common sense, it does not depend on what processor you use (as long as it has a timer of course  ) And yes, it is basically a lot of reading, then programming, then more reading, debugging, throwing stuff around, then more programming... What you learn from that you can use in your next projects, no matter if it is pic, avr, arm...

[lewis]

If you decide to stay with the PIC there is an EXCELLENT, and I really mean EXCELLENT, set of tutorials here: http://www.gooligum.com.au/tutorials.html (scroll down a bit, they're free).

Without meaning to hijack the thread, if anyone knows of something similar for AVR (or ARM!) I'd like to know, really want to broaden my MCU horizons.

[Simon]

go to AVRfreaks.net and onto the forum, there is a tutorials category with many excellent tutorials by various members

[Simon]

The problem I find with many tutorials is that the authors assume you know so much to the point of making you wonder why you should need their tutorial if you knew so much. I often find more advanced things explained and no basics, pic tut's are very good at this

[IanB]

A friend of my dad's has asked me to knock up a circuit for him that generates a pulse every 30 seconds to tick the mechanism over. now there is some help on the back in the form of a label that states that the clock coil should be fed between 170 and 270 mA. But I have no idea how long the tick should take.

I'm currently running on 100mS, it's giving a healthy clonk every 30 seconds-ish (it will take hours if not days of running to notice any drift, luckily the instruction time of a pic at 32.768 KHz divides into 30s with a whole number so in theory I can get it bang on). The coil resistance is about 14 ohms that for 270mA dictates 3V but as I'm driving from 4.5-4.8V and the voltage at 170mA is 2.38 I guess i can use "PWM theory" and half my pulse time from the ideal at the voltage that it would otherwise run at.

You might get away with that, but the clock movement is mechanical and "slow" in electronic terms. If you make the pulse current deviate too far away from the specification it may not work reliably.

Since you have a specified current between 170 and 270 mA I would suggest configuring a simple constant current source at about 220 mA and using that to feed the clock output.

[Simon]

The current requirement will have been a min to make sure it ticked and a max to make sure it was not overheated (leading me to assume decent pulse times), many clocks could be strung in series and I guess there were only so many standard batteries voltages available, I figure the voltage was to be between 2.4 and 3.8 volts (based on 14 ohm coil resistance), I plan on using 3 AA batteries (3.6-4.8V) and a slightly shorter pulse than what would have been or to use a resistor, as long as enough magnetic energy is generated in the coil to attract the arm it will work, the return motion is done by mechanics, all the electric does is attract an arm to the electromagnet and that pulls on a cog, another sprung arm does the rest

[IanB]

Yes, but it takes a certain amount of time for the magnetic field to build up in the coil and the arm to be attracted. If you make the pulse too short it may not work. I guess as long as it works when you test it you will be fine.

[Simon]

well the arm is quite close and with 100mS I get a healthy clunk plus I'll be running a slightly higher voltage. I don't know much about electromagnetic's but as you say experimentation will provide me with the solution. I guess if i can get an MCU to tick every 30s I can pick and choose my pulse length at will.

[grumpydoc]

Why do you need a microcontroller for this anyway? An oscillator built from a  32.768Khz crystal divided down by 2^14 (a 4060) will give 2Hz, divide this by 60 with a couple of 4017's and you have a 1/30Hz square wave.