Here’s another new board, the Precision RTC Plug – this is is a revision of a design by Lennart Herlaar from almost a year ago – my, my, this year sure went by quickly:
The current RTC Plug from JeeLabs will be kept as low-end option, but this one reduces drift by an order of magnitude if you need it: that’s at most ≈ 1 second per week off over a temperature range of 0 .. 40°C. Or one minute per year.
Drift can go up to twice that for the full -40 .. +85°C range, but that’s still one sixth of the crystal used in the original RTC Plug. Considerably better than this, in fact, if you need the extended temperature range. Here’s a comparison between both plugs, from the datasheet:
The way the Precision RTC works is with a Temperature Compensated Crystal Oscillator (TCXO): once a minute, the approximate temperature is determined and the capacitance used by the crystal oscillator is adjusted ever so slightly to try and keep the 32,768 Hz frequency right on the dot. Since the chip also knows how long it has been running, it can even apply an “aging” correction to compensate this small effect in every crystal.
The temperature can be read out, but it’s only specified as accurate to ± 3°C.
No need to use any special software for this, all the normal clock functions are available through the same code as used with the original RTC Plug. If you want to use fancy functions, or perhaps calibrate things further for an even lower drift, you can access all the registers via normal I2C read and write comands.
The board will be added to the shop in a few days, and the wiki page on the Café updated.
It looks like you also hit the ‘6’ key when typing in “32,768 Hz”.
Nice plug with a small typo: claibrate ;-)
Does this one give the same accuracy as the JeeLink ?
Thx for the corrections :)
At room temperature the JeeLink is 10 ppm and the Precision RTC 5x more accurate (2 ppm). Over a wider temperature range, the difference in precision will be much larger – same as in the 20 ppm graph shown above, but with the dotted lines a bit tighter.
Maxim has a “newer” middle ground RTC between the sort-of-clock-like-it-basically-keeps-time DS1307 and the TCXO DS3231S, the DS3231M, where the M stands for MEMS. It’s supposed to be accurate within 5ppm, and it comes on a convenient little .150 SOIC-8 instead of the half NC 16 pin SOIC footprint that the 3231S comes on. I assume the TCXO requires more die space than the MEMS oscillator which is why the 3231S never shrank to 8-SOIC.
I’m waiting for my carrier boards to come in so I can test whether the 3231M can work as a plug-in replacement for a DS1307 with some careful soldering and machine pins. If space isn’t a concern, there’s no reason to not go to the 3231S though – pricing seems pretty similar between M and S.
Eye pleasant blue color for the second day in a row. What’s next? :)
@Patrick, the MEMS variant has much better shock tolerance, so it is a good fit for applications that expect a rough ride (e.g. off track data logging).
@martynj, I was wondering what the deal was – I mean, it’s convenient that you can make a SOIC to DIP adaptor that can basically fit where the DIP-8 DS1307 had been previously, and the error rate seems to be in the middle of the DS3231S’s +-2ppm and the DS1307’s anything-goes slew rate, but it seems like an odd part to make for no other reason than maybe a process shrink. But additional shock tolerance is certainly marketable.
Unfortunately, while you can get (possibly counterfeit) 3231S’s for cheap enough through the usual sources, the 3231M is still $8/chip, so you have to really want the additional precision. :)
@Patrick, agreed – the 3231M price tag is high at the moment. I think this (and further derivatives) are aimed firmly at the automotive and military sectors. Those 32kHz resonators just don’t stand up to g or vibration abuse.
Just get those volumes up so us one-off users can enjoy the economies of scale.
BTW, final test must be a challenge. Checking within a couple of ppm in a few seconds of testing time when the only official output is a one second square wave seems problematic. I doubt it can be die level probing since the encapsulation stage will invalidate the testing.