I need a 1 pulse per minute time base for a clock project. A string of 4017 counters was used to count to 60hz line (/10/10/6/6). A jumper changes the divider to /10/10/5/6 for 50hz. I used a transistor in an 'and' circuit to get a pulse from the last counter's output and the previous counter to create a shorter pulse.
Also under consideration was a processor based system but I was missing counts when I left the counting loop to send the longer output pulse.
The 4017 design works perfectly, a week plus so far, but, are there any other 'cleaner' thoughts, or comments?
Len
Time Base
Time Base
Len
“To invent, you need a good imagination and a big pile of junk.” (T. Edison)
"I must be on the way to success since I already have the junk". (Me)
“To invent, you need a good imagination and a big pile of junk.” (T. Edison)
"I must be on the way to success since I already have the junk". (Me)
Re: Time Base
From the sounds of it, your processor solution didn't use interrupts to track time. That would have fixed your missing count problem.
Over the longer run, any solution based on a crystal will drift. Even a 20 ppm crystal will lose up to a bit more than 50 seconds per month.
The best solution is to sync with WWVB (in the US/Canada). I've seen receiver modules that give you access to the time data stream. If you sync daily, you can be spot on.
Over the longer run, any solution based on a crystal will drift. Even a 20 ppm crystal will lose up to a bit more than 50 seconds per month.
The best solution is to sync with WWVB (in the US/Canada). I've seen receiver modules that give you access to the time data stream. If you sync daily, you can be spot on.
Re: Time Base
Hello,
Len, by all means you can get a very very simple circuit using a microcontroller chip.
I did the same thing only with a much longer time period: two pulses per day with
one ic chip!
You can use a crystal with it or crystal oscillator dip package for precise timing, or
even take an input from the line to sense line frequency if you want to do it that
way, or even sync to WWV if you have a receiver.
It sounds to me like you could get away with using the internal oscillator for the
timing so you could get away with only one small ic chip, although you didnt
really mention the accuracy needed for this timer.
The uC chips make ideal timers because you can program them for almost any time
length. The program is rather simple too, just a delay loop with a few I/O commands
such as:
That's about it.
Len, by all means you can get a very very simple circuit using a microcontroller chip.
I did the same thing only with a much longer time period: two pulses per day with
one ic chip!
You can use a crystal with it or crystal oscillator dip package for precise timing, or
even take an input from the line to sense line frequency if you want to do it that
way, or even sync to WWV if you have a receiver.
It sounds to me like you could get away with using the internal oscillator for the
timing so you could get away with only one small ic chip, although you didnt
really mention the accuracy needed for this timer.
The uC chips make ideal timers because you can program them for almost any time
length. The program is rather simple too, just a delay loop with a few I/O commands
such as:
Code: Select all
Initialize
;put any initialization code you need for the chip here
Start
bsf GPIO,0 ;use bit 0 of the output register as the pulse output, set it high
call Delay_High
bcf GPIO,0 ;set bit 0 of the output register low again
call Delay_Low
goto Start
Delay_High
;put delay code for the high pulse length here
Delay_Low
;put delay code for the low period here
END
LEDs vs Bulbs, LEDs are winning.
Re: Time Base
Thanks Philba and Al for your input.
The appliccation is a drive pulse to a mechanical device that accumulates elapsed time. Since the accuracy need not be better than a typical wall clock, I decided to use 60hz because the long term accuracy is adequate and the cost is nil since the device needs a 24vac impulse.
Maybe my programming knowledge is behind the times, since I still use various versions of basic.
The attempts I originally made were to use a loop to count the 60hz pulses with a branch to a 250ms output pulse routine when the count was satisfied, then back to the counting loop again. Obviously, when the pulse routine was being executed, the 60hz input pulses continued but were not counted. A similar attempt was also tried using an interrupt for the pulse couting with the same result, lost time.
I considered prescaling the pulses with a 4017 to give the processor more time between pulses to do the output pulse but quickly settled on the present 4017 divider chain instead.
A quick search even showed several designs using a quartz clock movment to get a 2 phase 1 sec pulse but that is too much bulk and a kludge for what I need.
There are untold millions of quartz clocks and watches out there, all doing a similar task making 1 sec pulses, so I must be missing something here!
When the desired number of pulses are counted, by any means, from any source, the output pulse is sent. During that time the pulses are not being counted since the processor is busy timing the output pulse. Is the desired input pulse count adjusted to accomodate the lost time? [count=pulses per minute-(output pulse length+uC overhead clock cycles)]. Maybe the problem was that the uC's I used have an internal time base and not a crystal!
I would really rather consider a uC design since it would be more compact and 'modern'. I'm not sure the uC design would result in any savings since the output hardware would be about the same for either design, the cost of the uC, crystal and likely a cleaner power supply compared to 4-CD4017's for under $1.60 and a more few discreete parts might be hard to match! The real savings would be board size and fabrication cost.
Push me back on track!
(All comments welcomed!)
Len
The appliccation is a drive pulse to a mechanical device that accumulates elapsed time. Since the accuracy need not be better than a typical wall clock, I decided to use 60hz because the long term accuracy is adequate and the cost is nil since the device needs a 24vac impulse.
Maybe my programming knowledge is behind the times, since I still use various versions of basic.
The attempts I originally made were to use a loop to count the 60hz pulses with a branch to a 250ms output pulse routine when the count was satisfied, then back to the counting loop again. Obviously, when the pulse routine was being executed, the 60hz input pulses continued but were not counted. A similar attempt was also tried using an interrupt for the pulse couting with the same result, lost time.
I considered prescaling the pulses with a 4017 to give the processor more time between pulses to do the output pulse but quickly settled on the present 4017 divider chain instead.
A quick search even showed several designs using a quartz clock movment to get a 2 phase 1 sec pulse but that is too much bulk and a kludge for what I need.
Al, from your code snip it seems that there are two timing loops, one for the pulse width, the other for the time between pulses, the two together being the pulse timing, or frequency. There appears to be no external pulse reference so I assume the uC's oscillator is the reference.MrAl wrote:Initialize
;put any initialization code you need for the chip here
Start
bsf GPIO,0 ;use bit 0 of the output register as the pulse output, set it high
call Delay_High
bcf GPIO,0 ;set bit 0 of the output register low again
call Delay_Low
goto Start
Delay_High
;put delay code for the high pulse length here
Delay_Low
;put delay code for the low period here
END
There are untold millions of quartz clocks and watches out there, all doing a similar task making 1 sec pulses, so I must be missing something here!
When the desired number of pulses are counted, by any means, from any source, the output pulse is sent. During that time the pulses are not being counted since the processor is busy timing the output pulse. Is the desired input pulse count adjusted to accomodate the lost time? [count=pulses per minute-(output pulse length+uC overhead clock cycles)]. Maybe the problem was that the uC's I used have an internal time base and not a crystal!
Philba, what crystal do the popular $5 clock use? Thay are way more accurate than this!philba wrote:Over the longer run, any solution based on a crystal will drift. Even a 20 ppm crystal will lose up to a bit more than 50 seconds per month.
I would really rather consider a uC design since it would be more compact and 'modern'. I'm not sure the uC design would result in any savings since the output hardware would be about the same for either design, the cost of the uC, crystal and likely a cleaner power supply compared to 4-CD4017's for under $1.60 and a more few discreete parts might be hard to match! The real savings would be board size and fabrication cost.
Push me back on track!
(All comments welcomed!)
Len
Len
“To invent, you need a good imagination and a big pile of junk.” (T. Edison)
"I must be on the way to success since I already have the junk". (Me)
“To invent, you need a good imagination and a big pile of junk.” (T. Edison)
"I must be on the way to success since I already have the junk". (Me)
Re: Time Base
Hi again,
Yes, a crystal oscillator will loose time over say a month, but one that is cut properly
will work pretty well at 25 deg C. The crystal should be spec'd to work over a
certain temperature range, but should be very close at 25 deg C.
In any case, if you are looking for very long term accuracy they yes a 60Hz line
frequency based timer is better overall. This should not be that hard to do either,
since all it has to do is detect the zero cross of the power line. This is accomplished
with a carefully designed voltage divider to allow the uC to sample the line frequency.
It should never miss a beat if it is designed correctly.
This could be as simple as a single resistor from the line to the uC with maybe one
protection zener. The algorithm would wait for a zero cross, then generate a
timing pulse, then wait for some time to reduce false triggering, then wait again
for the next zero cross.
Probably the best language for this is assembler because that will put you in complete
control of ever microsecond that uC ticks at (or even a smaller time interval like
one half microsecond).
The algo might use an interrupt on change type of detection, or even for this app
possibly a simple polling routine to check for a change in the state of an input
pin (the line frequency).
The input circuit could probably be as simple as a resistor from the line to a port pin,
with a zener to clamp to maybe 4.7v and a reverse diode to clamp to -0.7v. For
an example you can probably look at some Microchip design notes for some triac
applications, which would use line sync'ing as well. If you need a link, let me know.
A basic polling routine might go like this:
A basic interrupt driven system might go like this:
There are obviously other ways to do it, these are just a couple simple examples using pseudo code.
Yes, a crystal oscillator will loose time over say a month, but one that is cut properly
will work pretty well at 25 deg C. The crystal should be spec'd to work over a
certain temperature range, but should be very close at 25 deg C.
In any case, if you are looking for very long term accuracy they yes a 60Hz line
frequency based timer is better overall. This should not be that hard to do either,
since all it has to do is detect the zero cross of the power line. This is accomplished
with a carefully designed voltage divider to allow the uC to sample the line frequency.
It should never miss a beat if it is designed correctly.
This could be as simple as a single resistor from the line to the uC with maybe one
protection zener. The algorithm would wait for a zero cross, then generate a
timing pulse, then wait for some time to reduce false triggering, then wait again
for the next zero cross.
Probably the best language for this is assembler because that will put you in complete
control of ever microsecond that uC ticks at (or even a smaller time interval like
one half microsecond).
The algo might use an interrupt on change type of detection, or even for this app
possibly a simple polling routine to check for a change in the state of an input
pin (the line frequency).
The input circuit could probably be as simple as a resistor from the line to a port pin,
with a zener to clamp to maybe 4.7v and a reverse diode to clamp to -0.7v. For
an example you can probably look at some Microchip design notes for some triac
applications, which would use line sync'ing as well. If you need a link, let me know.
A basic polling routine might go like this:
Code: Select all
Start
CheckInputPin
Same?
Yes: goto Start
No: fall through
SetOutputPin_High
Wait_PulseTime
SetOutputPin_Low
Wait_4ms
goto Start
A basic interrupt driven system might go like this:
Code: Select all
IntRoutine
OutputWentLowToHigh?
Yes:
SetOutputPin_High
Wait_PulseTime
SetOutputPin_Low
Wait_4ms
No:
Wait_4ms
Start
WaitForIOC
goto Start
LEDs vs Bulbs, LEDs are winning.
Re: Time Base
Maybe my programming knowledge is behind the times, since I still use various versions of basic.
The attempts I originally made were to use a loop to count the 60hz pulses with a branch to a 250ms output pulse routine when the count was satisfied, then back to the counting loop again. Obviously, when the pulse routine was being executed, the 60hz input pulses continued but were not counted. A similar attempt was also tried using an interrupt for the pulse couting with the same result, lost time.
Push me back on track!
(All comments welcomed!)
Len
Hi Len -
Here's something to nibble on. You're losing time because you're making the uC do two things at the same time. Try this - since the CD4017
divider chain is working "perfectly", keep it. Let it do the counting and it's output can trigger the interrupt pin of the uC. The interrupt
service routine (ISR) is the program - or subroutine - you write to tell the uC what to do when interrupted such as 'clear the input, clear
the interrupt flag, output a 250ms pulse, update the info on the screen, etc., etc.' This all takes place in less then half a second so the uC
can return to what it was doing before the interrupt until the next interrupt. And programming knowledge is never behind times - I am
typing this on a three year old Apple I-Mac, but, I'm still working with my Commodore VIC-20!!! It may be limited in memory but THAT is the
challenge! Anyway - something to think about. The only hard and fast rules are your own. Thanks for listening to my lowly squawkings.
Phil Potter.
The world is - oh my gosh - round!!!
Re: Time Base
Phil,
You are correct in that the processor was busy making the output pulse while the timing pulses were slipping by. I'm not clear what your suggestion of the addition of a processor to the working 4017 divider chain would accomplish. I am getting the output pulse using an AND gate with one input from the last stage and another from a preceeding stage. (last stage pulse is too long). As an alternative, the last stage could trigger a 555 one shot to make the pulse.
Since this post was started, I went back to a PICAXE processor design and now seem to have apparent success. Here's the logic...
Set an interrupt to watch for the timing pulses
With an input pulse...
Increment a counter
If the count is 3560 set the output pin high
If the count is 3600 set the output pin low, zero the counter
Return to the interrupt
In this manner there is no lost processor time for the output pulse, and no obvious lost counts
The difference between the 3560 and 3600 counts is the output pulse duration (1 sec)
At power up I can read jumper options and set the test counts for 3600 (60hz), 3000 (50hz), or 60 for one second pulse testing.
The code works and is is extremely small. I'll post the finished version if there is interest but for now I am cleaning it a bit, and looking for any bugs!
One big plus is a much smaller board and a lot less holes, The PicAxe processor is only 8 pins verses 64 for the 4017's!
Len
You are correct in that the processor was busy making the output pulse while the timing pulses were slipping by. I'm not clear what your suggestion of the addition of a processor to the working 4017 divider chain would accomplish. I am getting the output pulse using an AND gate with one input from the last stage and another from a preceeding stage. (last stage pulse is too long). As an alternative, the last stage could trigger a 555 one shot to make the pulse.
Since this post was started, I went back to a PICAXE processor design and now seem to have apparent success. Here's the logic...
Set an interrupt to watch for the timing pulses
With an input pulse...
Increment a counter
If the count is 3560 set the output pin high
If the count is 3600 set the output pin low, zero the counter
Return to the interrupt
In this manner there is no lost processor time for the output pulse, and no obvious lost counts
The difference between the 3560 and 3600 counts is the output pulse duration (1 sec)
At power up I can read jumper options and set the test counts for 3600 (60hz), 3000 (50hz), or 60 for one second pulse testing.
The code works and is is extremely small. I'll post the finished version if there is interest but for now I am cleaning it a bit, and looking for any bugs!
One big plus is a much smaller board and a lot less holes, The PicAxe processor is only 8 pins verses 64 for the 4017's!
Len
Len
“To invent, you need a good imagination and a big pile of junk.” (T. Edison)
"I must be on the way to success since I already have the junk". (Me)
“To invent, you need a good imagination and a big pile of junk.” (T. Edison)
"I must be on the way to success since I already have the junk". (Me)
Re: Time Base
Hi Len,
Did you also consider two one shots? Sill more complex than a uC though.
Did you also consider two one shots? Sill more complex than a uC though.
LEDs vs Bulbs, LEDs are winning.
Who is online
Users browsing this forum: No registered users and 17 guests