Accurate Digital clock using only Atmega32 ?

Go To Last Post
40 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to build a digital clock using Atmega32 and LCD. My problem is with trying to get accuracy of 95+%. Is this even possible? 

The code runs well but the problem is after some time running the clock, I find that there is a delay of some seconds this delays stacks to become minutes after a long period of time.

Kept trying a lot of methods to over come this problem but I could not find a one that solves the problem.

I found a tutorial which used an external real time lock (RTC) but I don't want to do this right now. I want to figure out if it is even possible to achieve a 95+% accuracy or even 100 % with no delays at all.

I think that the problem lies in sending a string to the lcd which takes some time like 8-10ms delaying the program. 1ms for each character in order to achieve high to low pulse for the enable pin for the lcd.I have tried to lower this delay as low as possible but 1ms was the minumum that I can reach.

Sorry for the long sentences but I am trying to explain the full situation xD 

so as a beginner, I really want to know the answers to these questions

1)Is it possible to build a full accurate digital clock using the MCU alone and without using external RTC.

2)Is there any mistakes in my code? Better logical approach to achieve digital clock?

3)Any advice to keep my code more clean?

my way of thinking

timer overflow -> overflow interrupt -> overflowCounter++ -> certain number of overFlows occurs corresponding to 1 second -> secondCounter++ -> reset timerCounter ->update time string ->send timeString to lcd (I think the problem is in here because in lcd code, I delay 1 ms to achieve high to low pulse for the enable pin in lcd) -> repeat for 60 seconds -> minutesCounter++ -> repeat  for 60 minutes -> hourCounter++ etc...

/*
 * LCD_Joe.c
 *
 * Created: 7/21/2019 1:27:24 PM
 * Author : JIGamer
 */ 

#include <avr/io.h>
#define F_CPU 1000000L
#include <util/delay.h>
#include "LCD_Joe.h"

void lcd_init(){
	lcd_ddr = 0xff;
	lcd_control_ddr |= (1<<RS) | (1<<RW) | (1<<EN);
	lcd_send_cmd(0x0E);
	lcd_send_cmd(0x38);
	lcd_clear();
	lcd_send_string("  INITIALIZED!");
	_delay_ms(500);
	lcd_clear();
}

void lcd_send_cmd(unsigned char cmd){
	lcd_port = cmd;
	lcd_control_port &= ~(1<<RS);
	lcd_control_port &= ~(1<<RW);
	lcd_control_port |=  (1<<EN);
	_delay_us(700);
	lcd_control_port &= ~(1<<EN);
}

void lcd_send_char(unsigned char sentCharacter){
	lcd_port = sentCharacter;
	lcd_control_port |=  (1<<RS);
	lcd_control_port &= ~(1<<RW);
	lcd_control_port |=  (1<<EN);
	_delay_us(700);
	lcd_control_port &= ~(1<<EN);
}

void lcd_send_string(char sentString[]){
	unsigned char  i = 0;
	while (sentString[i]!='\0')
	{
		lcd_send_char(sentString[i]);
		i++;
	}
}

void lcd_clear(){
	lcd_send_cmd(0x01);
}

void lcd_go_to_xy(unsigned char x,unsigned char y){
	if(x==0){
		lcd_send_cmd(0x80+y);
	} else if (x==1)
	{
		lcd_send_cmd(0xC0+y);
	}
}

Here is my code

/*
 * Digital Clock on LCD.c
 *
 * Created: 7/30/2019 3:46:44 PM
 * Author : Youssef
 */ 

#include <avr/io.h>
#define F_CPU 1000000L
#include <util/delay.h>
#include "LCD_Joe.h"     
#include <avr/interrupt.h>

//Functions prototypes
//setTime is used for setting time in main function before burning the code to the MCU
void setTime(unsigned char hour,unsigned char minute,unsigned char second,unsigned char *timePointersArray[3]); 

//updateTimeString is used for updating the string that contains time with new value
void updateTimeString(unsigned char hour,unsigned char minute,unsigned char second,char timeString[9]);

unsigned char timerOverFlowCount = 0; //Global Variable used by overflow interrupt service routine

ISR(TIMER0_OVF_vect){
    timerOverFlowCount++;
}
int main(void)
{
    lcd_init(); //Initializing lcd
    sei();      //Enabling global interrupts
    
    TCCR0 = (1<<CS00) | (1<<CS01); //set up timer with  = 64
    TCNT0 = 0;			//Initializing counter 
    TIMSK = 0x01;		//Enabling overflow interrupt 
    
    //time variables 
    unsigned char hoursCounter=0,minutesCounter=0,secondsCounter=0;
    //Array of pointers containing the addresses of time variables to change them through a function outside main
    unsigned char * timePointersArray[3];
    timePointersArray[0] = &hoursCounter;
    timePointersArray[1] = &minutesCounter;
    timePointersArray[2] = &secondsCounter;
    //A string containing time
    char timeString[9];
    //setting initial time before burning
    setTime(8,3,40,timePointersArray);
    
    
    while (1) 
    {
        
        while(hoursCounter!=12){
            while (minutesCounter!=60)
            {
                while (secondsCounter!=60)
                {
                    updateTimeString(hoursCounter,minutesCounter,secondsCounter,timeString);
                    if (timerOverFlowCount>=61)
                    {
                        if (TCNT0>=9)
                        {
                            TCNT0 = 0; //Resetting counter
                            timerOverFlowCount=0; //resetting overFlow counter
                            lcd_go_to_xy(1,4);  //Just to put time in the center of the lcd
                            lcd_send_string(timeString); 
                            secondsCounter++;	
                        }
                    }
                    
                }
                secondsCounter = 0;
                minutesCounter++;
            }
            hoursCounter++;
            if(hoursCounter==12&&minutesCounter==60){
                hoursCounter = 1;
            }
            minutesCounter = 0;
        }
            
    }
}

void setTime(unsigned char hour,unsigned char minute,unsigned char second,unsigned char *timePointersArray[3]){
    //This function is simply used for changing time variables in main function
    //It takes hour,minute and second as arguments. + arrayOfPointers -> pointing to time variables in main function
    *timePointersArray[0] = hour;
    *timePointersArray[1] = minute;
    *timePointersArray[2] = second;
}

void updateTimeString(unsigned char hour,unsigned char minute,unsigned char second,char timeString[9]){
    //This function is simply used for updating a string which contains the time
    //It takes hour,minute and second from variables in the main function and update the time string with it.
    timeString[0] = '0' + hour/10;
    timeString[1] = '0' + hour%10;
    timeString[2] = ':';
    timeString[3] = '0' + minute/10;
    timeString[4] = '0' + minute%10;
    timeString[5] = ':';
    timeString[6] = '0' + second/10;
    timeString[7] = '0' + second%10;
    timeString[8] = '\0';
}

 

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How are you clocking your AVR? Crystal or internal RC?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the internal clock.

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

would you consider using a GPS module?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisenßerg wrote:

I am trying to build a digital clock using Atmega32 and LCD. My problem is with trying to get accuracy of 95+%. Is this even possible? 

The code runs well but the problem is after some time running the clock, I find that there is a delay of some seconds this delays stacks to become minutes after a long period of time.

What on earth does "accuracy of 95+%" even mean ?  A 5% clock error, means you gain or lose 3 minutes every hour , which is noone's idea of  'Accurate Digital clock'

 

You did not mention Crystal anywhere, are you trying to use the internal RC Osc ?!

With an external Crystal, any MCU should be good to a few tens of ppm immediately, and single digit ppm if you calibrate the crystal offset.

You could push that to lower single digits with temperature checking, but at that stage you are probably best to move to a TCXO.

 

Mouser/Digikey show ECS-TXO-2016-33-160  (16MHz 2.5ppm, CMOS) at a good price, but stock is coming. Other larger packages are in stock, for slightly higher prices.

For sub ppm precision, you could look at the Murata tho they do not offer 16.000MHz

https://www.murata.com/search/productsearch?cate=cgsubCrystalOscillators&partno=XTCLH*J&pageno=1&sort=a_output

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisenßerg wrote:

I am using the internal clock.

Then you can expect to gain or lose minutes per hour. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am still new to embedded world so I am trying to build this digital clock using only my basic knowledge with timers atm but building a digital clock and updating time based on location using GPS module is definitely on my to do projects list. 

 

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would connecting an external 16MHZ solve the problem completely? 
What about the 10 ms delay that I am sacrificing to update the time string on the LCD? They would stack a bit, right ? Any ideas to fully eliminate this problem? 

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I find that the best AVR real-time clock is to use an external module based on the DS3231 IC.  These modules sell on eBay for about $1 each:https://www.ebay.com/itm/Arduino...

 

Yeah, I know, you want to do everything in software and make it just right with wonderful accuracy and no external parts.  But the monetary value of the time involved in making a clock this way ends up being many times more than the cost of the DS3231 module.   And as a learning experience, making I2C (TWI) work is more valuable than doing a real-time clock involving timers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just assumed that it is not possible to get 100% accuracy :') I know , I know that it's a weird assumption but till now I had no thoughts that the problem would be caused because of not using a Crystal as I haven't learnt anything about Crystals till now. 
I will certainly get a one now and learn about it. 

I just have one more question what if I added a Crystal, Will the problem be completely solved? What about the 10ms delay that it takes to send the time string to the lcd? Wouldn't they stack up ?

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are completely right, I have wasted almost 2 days trying to solve this. I will try to learn and start dealing with I2C communication and use an external module to re-do the project.

 

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisenßerg wrote:

I just assumed that it is not possible to get 100% accuracy :')

I know , I know that it's a weird assumption ...

Nothing weird, it is actually strictly quite correct. All time measurements have some finite precision, but you can certainly do way, way better than 5% :)

 

A simple sanity check of one second a day...

 1/(60*60*24) = 11.574ppm  (ppm = parts per million )

 

Heisenßerg wrote:

..but till now I had no thoughts that the problem would be caused because of not using a Crystal as I haven't learnt anything about Crystals till now. 
I will certainly get a one now and learn about it. 

 

Good, you should also learn about TCXO - eg Mouser search : 

https://www.mouser.com/Passive-Components/Frequency-Control-Timing-Devices/Oscillators/TCXO-Oscillators/_/N-7jdmj?P=1z0wnuk&Ns=Pricing|0

 

Heisenßerg wrote:

I just have one more question what if I added a Crystal, Will the problem be completely solved?

No timing problem is 'completely solved' but yes, using a Crystal and your timing creep will be far reduced, maybe 1000x better.  

Using a TCXO and you are better still, and the Murata ones are premium and reduce your RC creep 150,000x better...

GPS discipline is the next step...

 

Heisenßerg wrote:

What about the 10ms delay that it takes to send the time string to the lcd? Wouldn't they stack up ?

Yes, if you use simple delays, they are nominal, and can vary, so you will need an interrupt to anchor this to.

 

Usually you would code the timing in one block, and then update the LCD at some slower rate in a separate block.

Life is simpler if you keep variables byte sized, and select prescalers and dividers to allow that.

 

You could read this recent thread, around interrupt variables : - and bytes vs integer and atomic access...

https://www.avrfreaks.net/forum/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisenßerg wrote:

You are completely right, I have wasted almost 2 days trying to solve this. I will try to learn and start dealing with I2C communication and use an external module to re-do the project.

 

 

The internal RC clock of the AVR is hopeless for accurate timing, as you've found out.

 

By far the best solution (as you've found out again) is to use a real RTC (real-time clock) chip.  RTC chips also have other fun tidbits, like temperature compensation, ultra-low power consumption (use a 1F backup cap, and your clock will maintain time for weeks without power), automatic dealing with daylight savings time (in some chips, not all).  Et cetera.  I'll never build a clock without one again.

 

I'll say again:  If you're doing a new board, look into a big backup cap.  They really work - and if you need space, stick 'em on the back behind the display, or even on flying leads a few cm away.  RTC chip spec sheets tell you all about them.

 

That said...  I have on my desk a clock using a 32.whatever kHz clock crystal, not an RTC chip, and although it's miserably slow and somewhat temperature sensitive, I got around it by adding a little calibration routine.  Basically, about seven and a half times a day, it increments the time from hh:00:14 (fourteen seconds after the hour) to hh:00:16 without going through hh:00:15 on the way.  The 7.5 number was measured by lengthy observation - it was consistently slow by about seven and a half seconds a day.  It still waffles about with temperature - RTC chips correct for that (somewhat), as do TXCOs (Temperature-controlled oscillators, moreso, but at cost) but not enough to make me replace it.

 

Have fun!   S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that the problem lies in sending a string to the lcd which takes some time like 8-10ms delaying the program.

 

So, a couple comments, somewhat repetitious of the comments above.

 

The Internal RC Oscillator is great, IF you don't need great accuracy.

Using an External Crystal with the internal crystal circuitry greatly increases the accuracy, but it will still drift a little bit with temperature and operating voltage.

Using an External Real Time Clock module will give even better performance, but know that there is a range in performance for these devices. 

One of the nice things about them is that they often include an ultra low power backup capability, so you don't have to keep re-setting the date and time.

They also often include the date, so after your display shows the time correctly you can work on version 2 of the software that alternates between the Time and the Date.

 

At some point you have to play with GPS, it is just too much fun to see it working to not experience this.

Soooo very cool to have a breadboard on your bench tell you your location anywhere on the surface of the Earth.

The "benefit" of using a GPS module for a clock is that IF it can see the sky and get a satellite lock then it will continually update the Date and Time, so there are no cumulative errors, even after your clock is running for several years!

 

Two different types of External crystals were mentioned above.

You can run the micro from an 8 MHz, 10 MHz, 16 MHz, 11.xyz, or whatever.

This clocks the micro at this speed.

The upper limit is in the data sheet, ( 16 MHz for many AVRs, 20 MHz for others, and 32 MHz for the Xmegas).

Or you can, on some micros, connect a "clock crystal", (32.768 kHz), to one of the Timer/Counter's pins and that T/C module will run at 32.768 kHz, which turns out to be a great frequency to divide down for a real time clock signal.

(You can work on the math to verify this.)

 

In engineering we rarely talk about 100 % accuracy, but rather talk about how close to that we wish to be.

The closer you want, the more it costs.

You can buy a small atomic clock module from Microsemi that contains a miniature rubidium laser as its time source.

It, like all clocks, will drift.

It won't be 100 % accurate.

But it will lose about 8 seconds in 31,689 years.

 

That's about 1 second every 3,962 years.

 

The module is about $2,000 USD and is 51 mm x 51 mm in size, (very tiny, given its accuracy!).

 

Next a comment about the delays or time for the display update.

In a well structured program that should not matter at all, not even a little bit!

 

The time keeping is typically processed using interrupts.

The interrupts fire at the accuracy of the clock source.

The code increments a counter or two in the interrupt.

The overall software should never "miss" an interrupt, so 5 years from now the clock still hasn't ever missed an interrupt, or a timing "tic".

 

How long it takes to process the "clock" software, and update the display, doesn't effect the underlying time keeping.

For a general purpose clock that updates the display once every second, even if the display only updates 10 mSec after the actual time incremented, the User will never know that looking at the display.

The "clock" software, (updating seconds, minutes, hours, etc., and the display routine, should all be done in the Main Loop, with just the underling time keeping, (counting tics), being done in the interrupt service routine.

 

Building a clock based upon the micro's internal clock, (RC Osc), is a great project.

Building a clock based upon the micro's clock, with an External Crystal, is a great project.

Building a clock based upon an external RTC clock module is a great project.

Building a clock based upon a GPS module is a great project.

Building a clock based upon a Microsemi rubidium laser atomic clock is an expensive project.

 

You can learn a lot from the first four.

 

Keep us all updated on how your project progresses.

 

JC

 

Edit: Typo

 

 

 

Last Edited: Thu. Aug 1, 2019 - 11:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can also use the 60Hz AC line freq, there are many app notes for using this and many/most  digital clocks do this.   

That's because the power company employs many elves to count the number of AC cycles and keep it at exactly 60.000000 Hz over a long time, like a whole year.

 

It's cheap, easy, and a good way to kill yourself if you don't know what you are doing--SO DON"T   

Using a transformer is at least somewhat safe, but you still need to use plenty of care and common sense n wiring.

 

For your needs, an XTAL, oscillator module , or RTC chip/module are good choices.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

You can also use the 60Hz AC line freq, there are many app notes for using this and many/most  digital clocks do this.   

That's because the power company employs many elves to count the number of AC cycles and keep it at exactly 60.000000 Hz over a long time, like a whole year.

...

 

Those elves are less common, (or are they getting too old?) - this was a headline from last year..

"European clocks lose six minutes after dispute saps power from electricity grid"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, Heisenberg, the mere act of measuring your clock's accuracy will certainly  change it!  smiley

 

JC

 

Edit: Typo

Last Edited: Thu. Aug 1, 2019 - 11:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just don't kill the cat!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Just don't kill the cat!

Most [un]certainly not.

 

Heisenßerg wrote:
I just assumed that it is not possible to get 100% accuracy

Tell what "100% accuracy" means to you.  Tell how you might test that.  In that vein, please note that even the world-wide standard atomic clock sources are averaged.  So, CTA:

"Does Anybody Really Know What Time It Is?"
 

As I was walking down the street one day
A man came up to me and asked me what the time was that was
on my watch, yeah
And I said
Does anybody really know what time it is
I don't
Does anybody really care
care
If so I can't imagine why

about time
We've all got time enough to cry
Oh no, no
And I was walking down the street one day
A pretty lady looked at me and said her diamond watch had
stopped cold dead
And I said
Does anybody really know what time it is
I don't
Does anybody really care
care
If so I can't imagine why
about time
We've all got time enough to cry
Oh no, no
And I was walking down the street one day
Being pushed and shoved by people trying to beat the clock,
oh, so I just don't know,
I just don't know
And I said, yes I said
Background Vocal:
People runnin' everywhere
Don't know the way to go
Don't know where I am
Can't see past the next step
Don't have to think past the last mile
Have no time to look around
Just run around, run around and think why
Does anybody really know what time it is
I don't
Does anybody really care
care
If so I can't imagine why
about time
We've all got time enough to die
Oh no, no

Heisenßerg wrote:
but till now I had no thoughts that the problem would be caused because of not using a Crystal as I haven't learnt anything about Crystals till now. 

Think about it -- it doesn't matter about "crystal" per se.  ANY timekeeping device has accuracy dependent upon the accuracy of the underlying timebase source.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisenßerg wrote:
I want to figure out if it is even possible to achieve a 95+% accuracy or even 100 % with no delays at all.

 

Good luck.  Using the Internal RC is not a good choice even with an external clock as your RC will drift with temperature so your delays will drift with temperature, etc...

 

AS mentioned use a Crystal for your timebase for the AVR.

 

As suggested you can use an external RTC that can supply you an interrupt every second so you can service the RTC, and update your LCD very efficiently.

 

Then again, all of this has been done many times over so why go through this all again?

 

You could use one of these for your clock source:

https://www.microsemi.com/produc...

 

They even have a Request for Sample(Although I highly doubt they will send any, I might try just for the hell of it though myself)

 

OTher than some VERY expensive alternatives the AC line as a clock source is an option, but the safest >>and easiest<<  solution is the RTC IC.

 

JIm

 

EDIT:

 

WOWEE!!  Mouser has them in stock ready for shipment:

https://www.mouser.com/ProductDe...

 

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Fri. Aug 2, 2019 - 01:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

Those elves are less common, (or are they getting too old?) - this was a headline from last year..

"European clocks lose six minutes after dispute saps power from electricity grid"

 

They went on strike.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

No timing problem is 'completely solved' but yes, using a Crystal and your timing creep will be far reduced, maybe 1000x better.  

Using a TCXO and you are better still, and the Murata ones are premium and reduce your RC creep 150,000x better...

I am gonna head to the electronics store tomorrow to see what's available. 

 

Who-me wrote:
, so you will need an interrupt to anchor this to.

hmmm I am not sure if I got this right. An interrupt to interrupt the delay whenever an overflow occurs, right? 

Who-me wrote:

Life is simpler if you keep variables byte sized, and select prescalers and dividers to allow that.

 

You could read this recent thread, around interrupt variables : - and bytes vs integer and atomic access...

Will definitely look into this.

Thank you very much for your help. It really means a lot for me as a beginner with lack of knowledge and experience. 

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
use a 1F backup cap, and your clock will maintain time for weeks without power

The idea of using a cap as a backup source is really new to me which makes it a really great idea. Is there any possible way to calculate how long it will last?

Scroungre wrote:
The 7.5 number was measured by lengthy observation

I have tried to observe mine as well to try and do some sort of calibration it but tbh it was a painful thing to do xD

Scroungre wrote:
RTC chips correct for that (somewhat), as do TXCOs

I am gonna try both :')

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisenßerg wrote:

hmmm I am not sure if I got this right. An interrupt to interrupt the delay whenever an overflow occurs, right? 

Not quite- see the thread I linked to above.  https://www.avrfreaks.net/forum/...

 

That has good stuff about byte vars, and avoiding write outside interrupts, and choices of prescaler and where to split the interrupt out to polling.

You need to check what prescalers  and timer-reloads are valid, for your CPU.

As one example, a 10.000MHz oscillator, with a /64 prescaler and a 16 bit reload-timer gives choices like 

10M/64/50 = 3125  or that means /64 then reload repeat of /3125 will interrupt 50.00 times a second, or  16.384MHz /64/5120 give the same interrupt rate.
Whilst you could pick much longer int times, like 16.384M/1024/16000 for a 1 int per second, it means you have lost access to faster accurate delays, for timing keypad beeps for example.

Ballparks like 20ms/10ms/5ms are generally more useful, and you can run byte-sized beep duration timers inside those.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

At some point you have to play with GPS, it is just too much fun to see it working to not experience this.

Soooo very cool to have a breadboard on your bench tell you your location anywhere on the surface of the Earth.

The "benefit" of using a GPS module for a clock is that IF it can see the sky and get a satellite lock then it will continually update the Date and Time, so there are no cumulative errors, even after your clock is running for several years!

I am already excited to that project. Although, GPS module is kinda expensive but I guess it's worth it. :')

DocJC wrote:

In engineering we rarely talk about 100 % accuracy, but rather talk about how close to that we wish to be.

The closer you want, the more it costs.

You are totally right.

DocJC wrote:
The module is about $2,000 USD and is 51 mm x 51 mm in size, (very tiny, given its accuracy!).

Wow, Such an expensive piece of technology! 

DocJC wrote:

The time keeping is typically processed using interrupts.

The interrupts fire at the accuracy of the clock source.

The code increments a counter or two in the interrupt.

The overall software should never "miss" an interrupt, so 5 years from now the clock still hasn't ever missed an interrupt, or a timing "tic".

That was my thinking and actually that's how I built my code. Although, it doesn't look pretty xD but that's what I did.

I just assumed that this is the problem or part of the problem as I had no prior knowledge that internal clock isn't that accurate.(Have learned my lesson the hard way)

DocJC wrote:

Building a clock based upon the micro's internal clock, (RC Osc), is a great project.

Building a clock based upon the micro's clock, with an External Crystal, is a great project.

Building a clock based upon an external RTC clock module is a great project.

Building a clock based upon a GPS module is a great project.

Building a clock based upon a Microsemi rubidium laser atomic clock is an expensive project.

 

You can learn a lot from the first four.

 

)

I am going to start building as soon as I get the parts tomorrow from the electronics store except for the 5th project :') and sadly the GPS one as I am short on money atm.

DocJC wrote:
Keep us all updated on how your project progresses.

Don't worry, I will definitely keep you guys updated :)

Thank you very much for your help and time. I really appreciate it. <3

 

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alright, Gonna check it out! but first I need to sleep as it is 7:15 AM in Egypt. :( 
Thank you very much for your help.  

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Time to burn down my home. :') Is there any thread related to this so I can check it out?
I will try the safe solutions at first for sure but I really wanna know more about this AC line method.

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will certainly put this into consideration.

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Just don't kill the cat!

Forgive me, Zoe! :(

 

 

(Zoe is my cat)

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
"Does Anybody Really Know What Time It Is?"

I have checked the song. I really liked it <3 Gonna play it while working on the project. Thanks for sharing it with me.

theusch wrote:
Think about it -- it doesn't matter about "crystal" per se.  ANY timekeeping device has accuracy dependent upon the accuracy of the underlying timebase source.

You are right. Gonna keep that in my mind. 

 

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
They even have a Request for Sample(Although I highly doubt they will send any, I might try just for the hell of it though myself)

I also highly doubt it. 

 

jgmdesign wrote:

OTher than some VERY expensive alternatives the AC line as a clock source is an option, but the safest >>and easiest<<  solution is the RTC IC.

I will try the safe solutions for sure but I really wanna know more about the AC line as a clock. Is there a thread that I can check?

jgmdesign wrote:

WOWEE!!  Mouser has them in stock ready for shipment:

https://www.mouser.com/ProductDe...

That is just TOO EXPENSIVE!!! xD

~Heisenßerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Be "safe" use a transformer

 

http://ohbah.com/mods/binclock/

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisenßerg wrote:

I will try the safe solutions at first for sure but I really wanna know more about this AC line method.

You need to get some safely isolated, low noise, lower voltage copy of the mains.

Step down transformers are one way, you may be able to find an old AC-output plug-pack ?  That is very simple, and safe.

 

Needing a little more care, would be an opto coupler. You can get those with 500uA spec points, which keeps the dropper resistors to more practical power levels.

A mains rated series diode, or an anti-parallel small signal diode is added for a DC optocoupler, or no diode is needed for a AC optocoupler.

You need to insulate the mains-side in a closed plastic case, for safety.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisenßerg wrote:

Scroungre wrote:

use a 1F backup cap, and your clock will maintain time for weeks without power

 

The idea of using a cap as a backup source is really new to me which makes it a really great idea. Is there any possible way to calculate how long it will last?

 

There are ways.  The easiest is to model the current drain from the chip(1) as a simple resistor, and see how long it takes the cap to drop below the rated chip (Vbat) minimum voltage(2).  This will yield an underestimate, but to be more accurate involves some more interesting math(3).

 

I like caps better than coin cells for timer backup.  Coin cells die over time, while capacitors last forever(4).  They take some charging, though...

 

You will want some sort of inrush current limiting(5) and a diode from the power to the cap itself(6).

 

Heisenßerg wrote:

Scroungre wrote:

The 7.5 number was measured by lengthy observation

 

I have tried to observe mine as well to try and do some sort of calibration it but tbh it was a painful thing to do xD

 

I had a few advantages.  I was using a real crystal, although not temp-controlled, and although it was slow, it was consistently slow.  It was still f--king tedious, though.  This is one of the reasons why I'm not building a clock like that ever again.

 

Heisenßerg wrote:

Scroungre wrote:

RTC chips correct for that (somewhat), as do TXCOs

 

I am gonna try both :')

 

Have fun!  Experimenting is how you learn - even old dogs can learn new tricks.  S.

 

(1) You will find this number on the spec sheet

(2) See (1)

(3) Involving raising things to the power of 'e'

(4) Longer than batteries, anyhow

(5) Couple hundred ohms or so.  Depends on your power supply

(6) Should be a low-drop schottky, but in practice a 1N400x will do fine

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Be "safe" use a transformer

 

http://ohbah.com/mods/binclock/

 

There are other ways involving AC line-rated capacitors (if the cap isn't the size of your thumb, it isn't rated for AC line work(1)) but as pointed out before this is a good way to electrocute your mother, your cat, and your little brother.  If that's what you want to do, don't tell us about it, but generally that sort of thing should be left to the greybeards who at least act like they know what they're doing.  S.

 

(1) As a rule of thumb.  cheeky

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone tried using mains hum as a timebase? Maybe with a phase locked loop or some sort of filtering?

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:

Has anyone tried using mains hum as a timebase? Maybe with a phase locked loop or some sort of filtering?

 

Opto-coupling was mentioned, but I have to admit that it never occurred to me to try audio coupling.  At 60Hz*, I guess it would work, but you'd need quite a speaker and microphone combo.  S.

 

* - in the USA, or some harmonic thereof, 50Hz elsewhere

 

Edited to add:  They did use audio devices as storage and delay lines in some of the earliest computers.  They don't do that anymore for obvious reasons.  For one, a single bit might be twelve feet long.  S.

Last Edited: Sun. Aug 4, 2019 - 09:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Has anyone tried using mains hum as a timebase? Maybe with a phase locked loop or some sort of filtering?

 

You mean as in `fingers on a scope probe` stray fields pickup ?

That could work, but you would need a short antenna / pickup wire, and need to ensure there was actually mains nearby & it would be prone to dropouts.

I had wondered if there was enough 'crap' emitting from the very cheap 5V USB Mains units,  to extract a mains signal from those... but that's more of a lottery, and probably not something you would base a time-keeper on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Has anyone tried using mains hum as a timebase? Maybe with a phase locked loop or some sort of filtering?

If your circuit has a source of low voltage ac, then using a "zero crossing detector" is a common method of sync'ing a clock to ac mains.

Using this method your clock accuracy will drift a bit, but over a long time frame will be fairly accurate.

Just be careful with AC mains, and only use a low voltage source, such as a secondary winding on a power transformer, say the one feeding a bridge rect. and 5 volt reg.

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you're in North America or the UK, there's WWVB / MSF:

https://www.universal-solder.ca/product/canaduino-60khz-atomic-clock-receiver-module-wwvb-msf-jjy60/

 

This one supports WWVB's more recent phase modulation, suitable for outlying regions (but not MSF):

https://www.universal-solder.ca/product/everset-es100-cob-wwvb-60khz-bpsk-receiver-kit-with-2-antennas/

 

If you're in Europe, there's DCF77:

https://www.universal-solder.ca/product/canaduino-dcf77-atomic-clock-receiver-module-77-5khz-for-europe/

 

There are other sources for these and similar parts (e.g. Amazon).

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]