[time-nuts] A look inside the DS3231

[Tom Van Baak]

Tim, Hal, Graham,

A followup on an old thread...

I have some RV-3028 samples here, both from Digikey and also directly 
from Micro Crystal. Besides the typical 12 digit BCD date & time format 
that almost all RTC use, the RV-3028 also has a 4 byte binary seconds 
counter, which is compatible with unix-style timekeeping.

The BCD format is YYMMDD hhmmss. The chip is spec'd to work until the 
year 2099. This is typical of digital clocks that use 2-digit years. The 
year 2100 itself is tricky because it's *not* a leap year. I won't be 
around in March 2100 to see the off-by-one calendar chaos that follows.

Tim -- you were worried that the RV-3028 will fail in the year 2038. The 
answer is *no*. The feared 2038 date is related to sign + 31-bit time_t 
values in unix-like timekeeping. But this RTC uses a 4-byte (32-bit) 
binary counter, which is implicitly unsigned. So it's fully compatible 
with both 32-bit and 64-bit unix systems for the rest of the century. 
Nothing wrong happens to this RTC in 2038.

If you want a 64-bit timestamp just initialize the high 4 bytes to zero 
once, and then read/reread the RV-3028 counter into the low 4 bytes. 
This works because the entire upper half of a 64-bit unix timestamp is 
now and remains zero until 2106 (which is beyond the RTC's 2099 spec 
anyway). Also you were worried about power; I assume fetching 32-bits is 
half the power of fetching 64-bits. So maybe give the RV-3028 another 
chance.

Hal -- your carry detect method would work. But 1) it's not necessary 
because there is no Y2038K problem with this chip (see above). And 2) 
Tim says his unique low-power application can't or doesn't want to have 
to poll the chip or do any math.

Graham -- correct, although Micro Crystal makes some nice TCXO the 
RV-3028 RTC is not temperature compensated. So if it's extreme accuracy 
you want instead of extreme low power, this chip isn't for you.

/tvb