Project: 6-Digit LED Clock (Very Accurate)

MMcLaren

Joined Feb 14, 2010
842
The boards I make are single sided, and I don't have any problem using wire jumpers. It is my norm. Home brewed boards like this run less than $5, the only hard part is the template for the board itself. That is where the time goes.

I was thinking of laying out one for this project.

How I make PCBs
Thank you for the time and effort you put into that very nice "how to" article Bill.

If you're interested... for simple boards I still use point-to-point wiring using the cheapie phenolic Radio Shack prototype boards, but a paper silkscreen laminated with plastic tape and glued onto the board really makes a big difference...

Cheerful regards, Mike



 

Attachments

Yako

Joined Nov 24, 2011
245
For homemade that looks bloody good.

I have done many home made PCBs using a light box (photo-sensitive negative acting riston) developer, etch, stripper, wash, lacquer, cut & drill -- jesus christ a day's worth of work almost.

I recall spending about six (6) hours wiring up the single chip six digit Charlie Clock/Calendar/Timer (below)... Whew!!! (lol)...
You got a link to this project?
 
Last edited by a moderator:

Wendy

Joined Mar 24, 2008
22,141
THE_RB web site has several really good projects along that vein, a precision crystal oven (about 4 times the diameter of the crystal) and a precision time base where the time is tweaked by ticks of the oscillator.
 
Last edited:

Yako

Joined Nov 24, 2011
245
C software is using an interrupt I can see (that's a good thing)

Your Xtal / crystal will have a rating too.

20ppm means that it could drift +/- 20Hz for every given every MHz

I notice that the Xtal in use is a 16MHz type.

Can you see the problem given what I have just told you?
 

MMcLaren

Joined Feb 14, 2010
842
C software is using an interrupt I can see (that's a good thing)

Your Xtal / crystal will have a rating too.

20ppm means that it could drift +/- 20Hz for every given every MHz

I notice that the Xtal in use is a 16MHz type.

Can you see the problem given what I have just told you?
What problem, please?
 

Yako

Joined Nov 24, 2011
245
But if it works within +/- 1 min p/month then who cares.

+/- 2 min is the bench mark for a satisfactory clock.

What problem, please?
Most clocks use a rather much lower crystal frequency for greater accuracy.

Around 32.768KHz

But if it works within +/- 1 min p/month then who cares.

+/- 2 min is the bench mark for a satisfactory clock.
 
Last edited by a moderator:

MMcLaren

Joined Feb 14, 2010
842
Most clocks use a rather much lower crystal frequency for greater accuracy.

Around 32.768KHz

But if it works within +/- 1 min p/month then who cares.

+/- 2 min is the bench mark for a satisfactory clock.
How does frequency affect accuracy?

A 50 ppm 32768 Hz crystal should be accurate to ± 1.6384 Hz, so that's a range of 32766.3616 Hz to 32769.6384 Hz. When you divide those frequencies by 32768 for a one second period you'll be off by some value between ± 50 us. Now let's look at a 50 ppm 10 MHz crystal which should be accurate to ± 500 Hz. When you divide the 10 MHz crystal frequency (9,999,500 to 10,000,500 Hz) by 10,000,000 for a one second period you'll be off by some value between ± 50 us. So it seems that if you take any 50 ppm crystal frequency and divide it down to 1 Hz, you should have a 1 Hz period that's within 50 ppm (0.00005 seconds at 1 Hz)... Yes, no?

Regards, Mike
 

Yako

Joined Nov 24, 2011
245
You are right with what you're saying, but we're talking software here. It dosen't quite always work like this with software.

How does frequency affect accuracy?
Higher frequencies consume more power to begin with as well. it's complex.

Prescalers in software MCUs are complex too.

For a software clock, 4MHz isn't the ideal frequency either really.

So I am calling the kettle black.

Most clocks rely on a 32.768 KHz frequency because it averages out I believe.
Consumes less power too.
 
Last edited by a moderator:

MMcLaren

Joined Feb 14, 2010
842
You are right with what you're saying, but we're talking software here. It doesn't quite always work like this with software.
Actually, it works exactly like that in software. You divide a 16,000,000 Hz crystal frequency by 16,000,000 for a 1 Hz frequency (1 second period) and you divide a 32,768 Hz crystal frequency by 32,768 for a 1 Hz frequency (1 second period).

Originally Posted by MMcLaren
How does frequency affect accuracy?
Higher frequencies consume more power to begin with as well. it's complex.

Prescalers in software MCUs are complex too.
I'm sorry, I don't understand your comments. Are we still talking about accuracy?

For a software clock, 4MHz isn't the ideal frequency either really.

So I am calling the kettle black.
I'm sorry (again). I don't understand your comment. The "ideal" crystal frequency probably depends on the application. A 32768 Hz crystal may indeed be the best choice for a battery powered application, but, the frequency doesn't really have anything to do with accuracy...

Regards, Mike
 

Yako

Joined Nov 24, 2011
245
If you say so.

You win boss.

I give up.

MMcLaren ...

Do you see anywhere in my source code where I am simply dividing 4,000,000 Hz by 4,000,000 ?
 
Last edited by a moderator:

MMcLaren

Joined Feb 14, 2010
842
THE_RB web site has several really good projects along that vein, a precision crystal oven (about 4 times the diameter of the crystal) and a precision time base where the time is tweaked by ticks of the oscillator.
Hi Bill,

Roman has some nice articles on his web site and I am familiar with his zero-error methods. Thank you...

Regards, Mike
 

Wendy

Joined Mar 24, 2008
22,141
The only reason that 32.768Khz crystals were used is they were already being made in quantity for color TVs of that era, and a simple division by a ripple counter (2^15) spit out one second. When digital watches were being invented the small savings in silicon added up.

There is no magic frequency involved. A 4Mhz crystal, designed properly (especially with crystal ovens, which is true of any crystal) is just as accurate as any other crystal. Higher frequencies are actually more adjustable, as you add or remove ticks per RB's method to improve accuracy. This kind of thing can only be done on programmable devices though, such as µC.

<snip>

Do you see anywhere in my source code where I am simply dividing 4,000,000 Hz by 4,000,000 ?
Whose source code?
 
Last edited:

Yako

Joined Nov 24, 2011
245
There is no magic frequency involved. A 4Mhz crystal, designed properly (especially with crystal ovens, which is true of any crystal) is just as accurate as any other crystal. Higher frequencies are actually more adjustable, as you add or remove ticks per RB's method to improve accuracy. This kind of thing can only be done on programmable devices though, such as µC.
Yeah, if I just allow the µC's timer to overflow with (n) count it doesn't equate to an accurate clock like I have now. Logically it should but it just doesn't work like this. I have some offsets in place through trial and error real world testing.
 

Yako

Joined Nov 24, 2011
245
I am not the only one complaining either. I know of an engineer who designed an excellent wireless nurse call system, and the only complaint about it is the clock!

Crazy part is, he then proceeded to develop a DIY clock that was sold at Jaycar electronics for a little under $200 (it was a real show piece that had leds on the outside for seconds that sequentially lit up with each second) -- using the same schema as his last, knowing that the thing could literally drift minutes in a week!

I'd flip if I paid $200 for a clock and it did this. Possibly some politics behind it. Who knows.
 
Last edited:

Yako

Joined Nov 24, 2011
245
Perhaps you're not running the timers correctly. Have you considered asking for help?
Not sure what to think. Quite a few programmers have raised this issue. One guy with a phd posted some code on a forum with acknowledgements of the problem coupled with claims about averaging overflow of tmro. Accurate over the long period but inaccurate in the short I believe.

I built his clock and it was accurate for what that says.
 
Last edited:

Yako

Joined Nov 24, 2011
245
We are after all using high-level languages with some inline asm. Could be a trait of the C compiler for all I know.
 
Top