Time library - Synchronize with external pulse rather than internal clock

Hi guys,

I have an application where I am using a RTC on a ultra low power setup.

I'm using the atmega internal oscillator at 1Mhz, which not only results in the time running 16x as slow, it is also not accurate.

So rather than keep poling the RTC every so often I was wondering whenever it would be possible to increment the seconds variable using the 1Hz signal from the RTC output instead of calculating it using the millis function. By seconds variable I mean the time library (I understand I could run a different variable to calculate time, but that's not what I wish to do)

Any thoughts?

Maybe
setTime( now()++ ); every 1Hz ? Not sure if that's what you mean.

But what's wrong with getting the time from the RTC every 1Hz ?

guix:
Every 1Hz ? Not sure if that's what you mean.

But what's wrong with getting the time from the RTC every 1Hz ?

No I mean every second, polling the 1Hz square wave output signal.

Known issues with the I2C Library locking randomly. So best just read at startup to avoid this possibility. Sure there are better two wire libraries, but its a hassle to port the code.

You could use the 1Hz signal to wake up your processor every second via an interrupt. Then do what guix suggested. You'll never need to communicate with the RTC except to initially configure it to output the 1Hz signal.

jboyton:
You could use the 1Hz signal to wake up your processor every second via an interrupt. Then do what guix suggested. You'll never need to communicate with the RTC except to initially configure it to output the 1Hz signal.

+1

Yes I was just trying that. Seems like the reasonable approach. Thank you all.

casemod:
Known issues with the I2C Library locking randomly.

Can you link to some information? I have several clocks that have been running for almost a year continuously, getting perfectly reliable time from an RTC using I2C.

aarg:
Can you link to some information? I have several clocks that have been running for almost a year continuously, getting perfectly reliable time from an RTC using I2C.

And are you polling the rtc or the time library?

The issue happens in noisy environments. Basically if the communication is lost and no acknowledgment is received the device just waits indefinitely. I had this issue happening several times, so I migrated most of my hardware to SPI

Some references to people having similar issues:

1
2

casemod:
And are you polling the rtc or the time library?

The issue happens in noisy environments. Basically if the communication is lost and no acknowledgment is received the device just waits indefinitely. I had this issue happening several times, so I migrated most of my hardware to SPI

Some references to people having similar issues:

1
2

Okay, I had a look at the issues. Well, yes, the Wire library should have a timeout. That sucks. But if there isn't a freeze, there's no issue. Many strange things can happen when hardware is pushed beyond its limits. Suppose SPI was pushed beyond its limits? Some programs would fail. Where is the fault, with the software or the hardware implementation? I see that one example deals with a DS1307. It is said that it crashes once per hour. If that happened to me, I would not be looking at software solutions.

What I am doing for most of my clocks, is the following. The RTC is configured to supply a 1 PPS signal which is connected to an interrupt pin. The ISR records the time, and sets a flag. The main program checks periodically for the flag. When a PPS is indicated, it then executes an I2C read of the time from the RTC.

My latest clock changed that, because it was written for the public. I assumed that most people would not want to bother connecting the PPS pin (also some RTC modules don't bring it out). So in that implementation, I just poll the RTC 10 times a second.

I believe in nailing problems at the source. Otherwise the problem may produce symptoms in addition to the one that you have addressed. A noise problem is actually a great example of that. What makes you think that SPI is any more resistant to noise than I2C? I mean generally?

Of course, it's better if a read of a device can report an error, so a retry can be attempted. But even in that case, the application carries the responsibility of doing that. Does yours? In all the experiments that I have been doing in the last year, I have not noticed a single failure due to I2C communications that I did not find was due to software mistakes.

So maybe you need to look closely at your hardware.

Edit - additional thoughts. Error handling often has to be pushed up to the front end. For example, with the clock, I have to consider, "what should the app do if the RTC time read fails". The simplest solution would be to just display the last known time and gamble that it would not fail in the next attempt. A more sophisticated version would use the millis based time to fill in until a valid read is performed.

The problem with embedded apps is that you can't push an error to a user, because sometimes there isn't one, and also because if there is one, they are powerless to deal with it. So you can't have a printout, "Error #342 - clock failed. Contact 1-800-888-8888 for support", or likewise. So if you expect an error, you have to have an error handling strategy.

But it's impossible to encompass all possible error conditions. Only the ones that you are aware of.

If you are super paranoid about the I2C, the DS3231 anyway, has a 32Khz clock output that is on by default at power up. So you can actually get a timebase from it without any I2C connections. Or you can initially program it for the 1Hz output, verify that using processor timing, and then leave it alone for the lifetime of the program.

I also decided to generally avoid I2C after a few mysterious lock ups. When an SPI device hiccups you get a bad read or a bad write and then the world keeps spinning. But an I2C bus glitch can derail the whole show. I think SPI is more robust, as well as faster. Why not use a DS3234 instead of the DS3231? It's the same device except that it interfaces via SPI (and has internal RAM).

The main selling point for I2C is it uses fewer pins.

I would have thought that the selling point was the ability to easily accommodate many devices on one bus, and a well defined master/slave protocol.

If there's a real problem with the Wire library, the problem should be escalated. It certainly doesn't give me a warm fuzzy.

One reason not to use the 3234 vs. 3231 is cost. Available modules are about 10x the price.

aarg:
I would have thought that the selling point was the ability to easily accommodate many devices on one bus, and a well defined master/slave protocol.

SPI has those things as well. The limitation is number of pins for chip selects whereas with I2C you sometimes have to contend with address collisions.

aarg:
One reason not to use the 3234 vs. 3231 is cost. Available modules are about 10x the price.

Maybe it's a reason. I can afford to spend $10 on my hobby.

It's so weird that you can get a module, overseas shipping included, for slightly more than the cost of a first class stamp. Whereas if you purchased the RTC chip in quantities of 1000 or more it would cost more, just for the chip. How does that work?

Donald Trump will put a stop to this sort of thing. :slight_smile:

jboyton:
SPI has those things as well. The limitation is number of pins for chip selects whereas with I2C you sometimes have to contend with address collisions.
Maybe it's a reason. I can afford to spend $10 on my hobby.

It's so weird that you can get a module, overseas shipping included, for slightly more than the cost of a first class stamp. Whereas if you purchased the RTC chip in quantities of 1000 or more it would cost more, just for the chip. How does that work?

Donald Trump will put a stop to this sort of thing. :slight_smile:

I worked in costing analysis. You just don't realize how cheap IC's and boards really are. The reason you're paying more your way, is that you have fostered a system that allows too many greedy middlemen to squeeze your wallet.

As to Donald Trump putting an end to free enterprise, well...

aarg:
I worked in costing analysis. You just don't realize how cheap IC's and boards really are. The reason you're paying more your way, is that you have fostered a system that allows too many greedy middlemen to squeeze your wallet.

That's interesting. I can get a DS3231 module for $0.85 from China, shipping included. It's got an EEPROM chip and a battery holder too. So it must be pennies for each of the items and some sort of bulk shipping. And then a minuscule profit margin.

So you're saying that if I were to buy a thousand DS3231 chips from Digikey they would be overcharging me by ~1000%?

jboyton:
I also decided to generally avoid I2C after a few mysterious lock ups. When an SPI device hiccups you get a bad read or a bad write and then the world keeps spinning. But an I2C bus glitch can derail the whole show.

That's exactly how I would describe it.
The problem is not exactly with I2C, its with the Arduino 2Wire library implementation

There are a few good alternatives out there. I recall an example where I had to change because I was backing up data inside an interrupt just before a power failure and the damn thing didn't run inside an interrupt. I cant remember which one I used, but it ended up being an hassle changing all the declarations/syntax for the new library for each deice I wanted to use, so I ended up using an SPI EEPROM and accessed it directly. Saved me a ton of space as well, no libraries needed.

jboyton:
That's interesting. I can get a DS3231 module for $0.85 from China, shipping included. It's got an EEPROM chip and a battery holder too. So it must be pennies for each of the items and some sort of bulk shipping. And then a minuscule profit margin.

So you're saying that if I were to buy a thousand DS3231 chips from Digikey they would be overcharging me by ~1000%?

I have mixed experiences with DS3231 from china. Some are just fine, but not all. I have some with me that loose or gain a few seconds every week and with the DS1307 it used to be minutes.

Whatever the case its generally worse than the manufacturer specs for either device. So I'm guessing these are either clones or failed QC. Same with 24L01 Wireless modules.

casemod:
I have mixed experiences with DS3231 from china. Some are just fine, but not all. I have some with me that loose or gain a few seconds every week and with the DS1307 it used to be minutes.

Whatever the case its generally worse than the manufacturer specs for either device. So I’m guessing these are either clones or failed QC. Same with 24L01 Wireless modules.

One second in a week is about 2 ppm. That is within spec. More than that isn’t. But I would ask what time reference you are comparing them with.

aarg:
One second in a week is about 2 ppm. That is within spec.

But a "few" seconds a week implies something a bit out of spec doesn't it?

It's hard to accurately gauge the reliability aspect since it's anecdotal but it is one reason I sometimes pay more. My time is worth more then $10 to me.

But the cost differential is still an interesting thing. Is it really that inexpensive to make these modules or is something or someone being short changed in the process of providing a super cheap product? I wish I understood the whole picture better. I can afford to participate in fostering whichever system I choose and for me the bottom line isn't necessarily the bottom line.

jboyton:
It's hard to accurately gauge the reliability aspect since it's anecdotal but it is one reason I sometimes pay more. My time is worth more then $10 to me.

But the cost differential is still an interesting thing. Is it really that inexpensive to make these modules or is something or someone being short changed in the process of providing a super cheap product? I wish I understood the whole picture better. I can afford to participate in fostering whichever system I choose and for me the bottom line isn't necessarily the bottom line.

Nor is it for me. I try to take it on a case by case basis. I've often been disappointed by paying more and still getting a defective product. My theory is based on the large number of vendors selling one particular module, the ZS-042. The price has dropped, and also many, many are sold. Those things go together with mass purchasing and mass production. I don't have facts to present, but it isn't too much of a stretch to think that maybe the manufacturer has been able to leverage much lower costs with larger quantities. Thus the cost to retailers is much lower.

Also, as I have pointed out previously, when the modules are closely inspected, they appear to be well constructed. Actually more so than the average import board.