Re: [time-nuts] A look inside the DS3231
Interesting part,
I do note that they elected to use a 32-bit UNIX time register, and
they don't have an alternate part with a 64-bit - which means it would be
susceptible to the UNIX epoch bug in 2038 if the data was simply consumed
right out of the register. Shame that the part didn't come with just 4
more byte registers, that puts the burden of patching on the software
people - meaning the CPU would have to be awake more to handle the
correction for 32-bit unsigned to 64-bit signed and keep track of
rollovers, potentially eroding some of the low power benefits. If someone
has the inside track at Micro Crystal, they should poke at the engineers
about this and get a revised part out. It would be very useful - I work on
a few security products that would really like this part's other key
points, but the native UNIX time is nifty.
-Tim
On Sun, Apr 19, 2020 at 9:00 AM time-nuts-request@lists.febo.com wrote:
From: "Graham / KE9H" ke9h.graham@gmail.com
To: Discussion of precise time and frequency measurement
time-nuts@lists.febo.com
Subject: Re: [time-nuts] A look inside the DS3231
Message-ID:
<CAPyJ-YU+ZEB4YVCgHU06P4epZu4Ds5D=_
mb+weGRFV-tcMGEPg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Well, time and technology move on.
As wonderful as the DS3231 is, there is a newer chip from Micro Crystal
that is smaller, more accurate than the DS3231M, much cheaper, and draws
less power.
Micro Crystal is the Semiconductor division of Swatch (Swiss Watch Company)
If this sort of thing interests you, look at the
https://www.microcrystal.com/
https://www.microcrystal.com/en/products/real-time-clock-rtc/
https://www.microcrystal.com/en/products/real-time-clock-rtc/rv-3028-c7/
The RV-3028 is 3.2x1.5 mm in size, 1.5ppm, additionally trimmable, 45 nA
standby current, under $3 USD in price and in stock at Mouser and Digikey.
Of particular interest to me, besides all the normal features, this one
also directly keeps time in Linux Epoch time, seconds and fractions since
(your choice of epoch) so smaller data movements on the bus, and I don't
have to keep converting back and forth between time formats/structures.
--- Graham
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