Hi, I’m using DS3231 RTC module and max7219 dot matrix display with 4 modules. When i made a clock that displays time, I realized that it drifts about 15 seconds an hour. There was no reason for such a behaviour so I started troubleshooting and came to the conclusion that power supply could be making all the problems. When i removed the dot matrix module, it didn’t drift anymore. I put the module back and removed just the dot matrix 8x8 displays and it didn’t also drift. That made me think that putting these displays in, when refreshing the screen, they draw to much current in the split of a second and cause some power supply ripple or voltage dip that could mess with the RTC module. I’m using 5v 2a power adapter with barrel jack and everything is wired on a breadboard. Currently, I don’t have any equipment to measure power supply ripple so I don’t know if this is actually the reason for such a behaviour. Did anybody have similar experience with such a huge RTC drift and what was the problem. The RTC module is not some fake chip because it works flawlessly when tested sepparately.
I use the ones that are powered by a coin cell and don't have any problems.
try use decoupling capacitor 0.1 and 1000uF on max7219 power pin.
The underbelly of the DS3231 is sensitive to electrical noise, the crystal is near there. The datasheet says not to run noisy PCB traces, SPI under the IC. It should have a good ground pour. RTC runs fast if this is a problem.
It can also be noise on the SPI if the RTC is on the same bus as the MAX7219. If your grounding is not great, the high LED currents will make the MAX7219 ground noisy.
The underbelly of the DS3231 is sensitive to electrical noise, the crystal is near there. The datasheet says not to run noisy PCB traces, SPI under the IC. It should have a good ground pour. RTC runs fast if this is a problem.
It can also be noise on the SPI if the RTC is on the same bus as the MAX7219. If your grounding is not great, the high LED currents will make the MAX7219 ground noisy.
In the original post it is stated to be on a breadboard, so lots of possible problems with the wiring. Voltage drops can easily be caused when the LED's in the matrix displays are turned on due to resistance in the connections on the breadboard.
A better way of setting this up is to use a prototype PCB and solder the modules together to ensure proper connections.
Tell you a funny thing...
A have a design which has an optional DS1302 RTC.
Fortunately nobody ever bought that option
The RTC gains a few seconds every day. And the gain is related to how often you read it.
Never found out the reason, and never spent much time on it because it wasn't selling anyway
I see the data sheet
https://www.analog.com/media/en/technical-documentation/data-sheets/ds1302.pdfis dated 2015. I did the design and the code c. 1991. If this was a bug and was fixed, they did it quietly. Could be the way I am reading it, some register access order which exposes an issue, or radiation from a PCB track nearby (doubt it). So try to see if the issue persists if you read the RTC only rarely.
It's an old chip. But until very recently (see a recent RTC thread here) it had the lowest power consumption of any RTC, at ~200nA.
Tell you a funny thing...
A have a design which has an optional DS1302 RTC.
Fortunately nobody ever bought that option The RTC gains a few seconds every day. And the gain is related to how often you read it.
Never found out the reason, and never spent much time on it because it wasn't selling anyway
I see the data sheet
https://www.analog.com/media/en/technical-documentation/data-sheets/ds1302.pdf
is dated 2015. I did the design and the code c. 1991. It's an old chip.
With many RTC chips there is a limit on how is the max period/duration for making the read. Usually a read process lasting more than 1sec will cause issues. That is because the I2C process stops updating the internal time counters.
..
Fortunately nobody ever bought that option The RTC gains a few seconds every day. And the gain is related to how often you read it.
Never found out the reason, and never spent much time on it because it wasn't selling anyway
..
From your DS for example (but there are chips without the secondary register afaik, like the old Philips old PCFxx one with even smaller current afaik):
When reading or writing the time and date registers, secondary (user) buffers are used to prevent errors when the internal registers update. When reading the time and date registers, the user buffers are synchronized to the internal registers the rising edge of CE.
The countdown chain is reset whenever the seconds register is written. Write transfers occur on the falling edge of CE. To avoid rollover issues, once the countdown chain is reset, the remaining time and date registers must be written within 1 second.
I am doing it in some 100s of microseconds (bit-banged I/O, 14MHz H8) and even allowing for an interrupt in the middle it cannot be anywhere near 1 sec.
So the OPs and your issue could be caused by the 3V voltage drop during R/W process as during the R/W process the power consumption of the chip is way much higher. It depends on the battery/Vcc wiring.
So try to see if the issue persists if you read the RTC only rarely.
That's what I thought at first. I started printing all the variables to the serial monitor and realised that every few minutes its time would somehow skip. So for example, let's say that it's 15:00:00 o clock and on the next SQW pulse it should be 15:00:01, it would somehow skip a second and it's time would be 15:00:00 again. That didn't make any sense so I adjusted the code that it only reads RTC time at the start of the program or every hour but the problem was identical. When SQW signal goes LOW, it increments counter instead of reading directly from RTC. That made me believe that it's SQW signal was not accurate. SQW signal also triggered when display refreshes. I started monitoring it and realised that it doesn't tick at the same rate as for example the accurate clock on the internet. And that difference adds up to a second every few minutes. RTC's internal time would also be behind one second so that probably means the crystal is not working correctly. To confirm that RTC is not faulty, I uploaded example code and realised that it works as it should. That made me think that something with the max7219 was causing all the problems. I removed the module and modified the program to print on serial monitor instead of max7219 and the problem was gone. That means, either the max7219 was causing the problems or my code. Then I uploaded the original code and just disconnected the max7219 module and the problem was gone. So, to not repeat myself, the rest is in my first post.
The max7219 could be dipping Vcc very briefly, during the display multiplexing or whatever.
UPDATE:
I separated the power supplies for the max7219 and the RTC module, max7219 is connected to the 5V DC power adapter and RTC module is powered with arduino that's connected via USB port to the laptop. It works flawlessly now so that means the power supply was indeed the problem. I'll try to use couple of decoupling capacitors as tanveerriaz said in a previous post.
I wonder why you power it from the supply instead of using a coin cell all the time. You're need a cell anyway to keep time when power is down and the cell will last years.
Yes, but if he's using the typical DS3231 module, he needs Vcc power during I2C activity - to power the pullup resistors.
Pull-up resistors can be powered separately from the DS3231 without affecting timekeeping. The DS3231 is powered by the coin cell.
I wonder why you power it from the supply instead of using a coin cell all the time. You're need a cell anyway to keep time when power is down and the cell will last years.
Pull-up resistors can be powered separately from the DS3231 without affecting timekeeping. The DS3231 is powered by the coin cell.
Ummm… no?
The DS3231 runs from the backup battery ONLY when Vcc is unavailable. The idea is to run from the battery only when necessary, to maintain the battery life, running from Vcc whenever possible.
There is no point trying to save battery by powering it with the main supply, the coin cell lasts a long time already. I have a couple of modules that have been running for a couple of years continuously. Some designs have a couple of diodes for dual supply if you are that fussy.
As I said, the I2C pins can be pulled up by the main supply, they are open drain so won't affect the RTC timekeeping.