3 different RPi3 RTC's (DS3231) don't retain the time on IIAB 6.5/master

[holta]

It's possible they're all past their shelf life? But unlikely in the case of all 3 RTC's, from 2 different vendors?

What should I test to further evaluate?

ASIDE: the OS (Raspbian 2017-11-29) retains the time on disk/microSD upon next bootup ("time literally stops until then!") [Possibly due to "fake-hwclock" ? Which acts a (bit) like a fake NTP server...] So if it's any consolation at least time does not go backwards (as was typical in older OS's :-)

[tim-moody]

I ran quite a few tests on the rpi3 I have with me and I conclude that the battery is dead. Will need to replace it to verify.

I initially thought the config had gone wrong, but I can't find anything.

boot/config.txt is OK. The OS sees the device. cat /proc/driver/rtc shows valid data and changes to the hwclock are retained until reboot.

The only inconsistency is that reboot loses the value whereas I would have expected only to lose it on power off.

I followed https://trick77.com/adding-ds3231-real-time-clock-raspberry-pi-3/

[holta]

I conclude that the battery is dead.

@georgejhunt can you try to corroborate the results @tim-moody & I have experienced above?

Do we conclude that most DS3231 batteries are essentially garbage so far, and as such that we need to qualify our RTC/battery vendors MUCH more carefully somehow? (So that people stop shipping/installing garbage in Developing World schools/clinics, that deserve infinitely better?)

[holta]

I conclude that the battery is dead.

@PhirePhly do you have any data on those additional two DS3231 batteries, corroborating this terrible pattern?

[PhirePhly]

The two RTCs you gave me in Huajuapan are fully functional and retain time. Their batteries read 3.000V and 3.014V.

[holta]

[tim-moody] followed https://trick77.com/adding-ds3231-real-time-clock-raspberry-pi-3/

The two RTCs you gave [PhirePhly] in Huajuapan are fully functional and retain time. Their batteries read 3.000V and 3.014V.

@floydianslips do you have any DS3231 RTC's on hand (or available from nearby makerspaces) to confirm if Raspian Lite/Desktop work prior and then after IIAB 6.5/master's 1-line installer? (http://download.iiab.io/6.5/rpi)

[tim-moody]

@PhirePhly Can you give us the steps to produce your results? What I did is

cold boot
root@box:~# date
Thu  3 Nov 17:18:00 UTC 2016
root@box:~# hwclock --show
2016-11-03 17:18:29.801005+0000
root@box:~# hwclock --set --date 2/1/2018
hwclock --show
date is retained and progresses as expected
poweroff
boot
hwclock --show
date is back to 2016-11-03 17:18:xx

This is on iiab on rpi3

[PhirePhly]

I hooked the RTC hat up to an Arduino and used the DS3231 driver example sketch to dump the RTC memory map.

DS3231_test.ino

I used a DVM to measure the battery voltage between the two battery solder points.

I plugged it into a Raspberry Pi booted with the dtoverlay=i2c-rtc,ds3231 overlays and I2C enabled and ran hwclock -D -r to also validate functionality per the AdaFruit RTC guide, which is my standard reference for configuring RTCs on the Pi.

[georgejhunt]

I think the battery-socketed rtc as per https://www.amazon.com/Makerfire%C2%AE-Raspberry-Module-DS1307-Battery/dp/B00ZOXWHK4 would be a way to get more reliability. The battery is a standardly available item. But it adds $8 to the materials cost.

Might get quantity discount.

[holta]

I think the battery-socketed rtc as per https://www.amazon.com/Makerfire%C2%AE-Raspberry-Module-DS1307-Battery/dp/B00ZOXWHK4 would be a way to get more reliability. The battery is a standardly available item. But it adds $8 to the materials cost.

I can't judge whether the above DS1307 approach offers more longevity / reliability, but hopefully others can weigh in!

(Either way I'm very concerned the above might be significantly worse ergonomically — everyday implementers cannot fit this inside standard RPi3 cases — due to the 5 rigid wires that stick up too high. As such it does not appear to be a scalable approach, out of the starting gates anyway!)

[tim-moody]

@PhirePhly 's results lead me back to wondering about configuration. The only difference I see between what he did and what we do is enabling i2c in raspi-config. I thought this was not necessary with raspian stretch and the config.txt we use, but it is worth a try.

[holta]

[enable] i2c in raspi-config

I and everyone should try this possible fix in coming days!

Thanks @tim-moody for catching this.

[georgejhunt]

I still had 3 out of the 10 ordered from china. All of them had dead batteries.

I ordered https://www.amazon.com/gp/product/B072DWKDW9/ because it has a battery socket, and looks like it will fit in the case

[holta]

I still had 3 out of the 10 ordered from china. All of them had dead batteries.

Horribly disappointing news. Thanks @georgejhunt for keeping us honest!

For the entire Raspberry Pi community that seeks a far cleaner solution here (even if current nanoserver communities basically don't care at all, when the server is used as a read-only reference especially) still this is critically important community productization research.

i.e. the above assumption will quickly change in future years, as usage grows — similar to client machines, where the lack of an RTC-or-similar (*) is inexcusable, in most all educational environments where students/teachers want to preserve their work, building up portfolios etc.

(*) e.g. a highly reliable "offline NTP" server/regime if nec, GPS gadgetry & time-zone guesstimations, whatever. In any case, whatever clock regimes evolve to make low-end RPi-class hardware increasingly relevant to schools/clinics/etc — we also need to be better about coexisting with fake-hwclock inside each client machine — so that time-marches-forward-not-backwards, when batteries later die...on clients AND/OR if the ntp server just no longer delivers.

[tim-moody]

could a client machine that is a re-purposed laptop with a working clock be a time server?

[holta]

could a client machine that is a re-purposed laptop with a working clock be a time server?

XO laptops likewise can work, which remain even more common than re-purposed "large" laptops in many countries we know. Many ways to skin the cat for sure, in situations where RTC's are a genuine priority e.g. among older students, who actually want to save their work or portfolio! (Important Note of Caution below)

Simultaneously a proven reliable supply chain of RPi RTC's that lasts many years (that fit inside RPi3 cases) remains a very central question, if we anticipate the Raspberry Pi Foundation can find inroads towards its original goals, Getting Real about universal education (not just upscale makerspaces) in coming years. Separately the flood of RPi Zero W nanoservers, as sold by James Heilman etc, work just fine as read-only reference servers, functioning perfectly (entirely without RTC's, in most all cases...)

Note of Caution: training consistency & ergonomic/inventory consistency are GIANT issues just below the surface, to be VERY careful of, in almost every developing world school. Oddball laptops (or any oddball HW, unlike every other in the room) will almost inevitably be unmaintained due to human not technical reasons:

• plugged in wrong when moved to a new classroom
• misunderstood after summer break / forgot to turn it on the next semester
• misplaced after janitorial cleaning
• totally abandoned due to benign neglect
• etc, etc

Regardless what the technology is for: if its ongoing value is not immediately+constantly apparent to on-site teacher/staff/kids, and able to survive high turnover/succession of teachers/principals/kids year after year!

A lone server dedicated to NTP/RTC falls very dangerously into this territory, and even more so in most primary/middle schools, among people who (generally) don't care at all about timestamps.

The age-old pattern(s) of OLPC deployment failure is not fun to talk about. But I mention it as it constantly resurfaces, rearing its ugly head across most all countries — and only worse when there's a diversity of on-site hardware — the most vital basic training & pedagogy guidance are inevitably squeezed out of existence, during the mad race to install shiny technologies :/ Time and again the ugly result is:

• Lack of a conscientious handoff
• Earnest teachers/staff's feeling unsupported when their most important questions around "what's the program behind the program" are papered over rather than in-depth tutorials/roadmaps they want and need to partake in and appropriate and apply this new knowledge
• Tech support combined with pedagogy support being a glib afterthought in most all far too many edtech rollouts

[georgejhunt]

a Bug report to debian describes how udev fails to set hwclock on rpi. Thread suggests writing our own udev rule which does not disable setting hwclock if systemd is running. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203

[holta]

Should #71 be closed or is it still relevant?

("Needless routines on Rpi (RTC, TZ)")

[holta]

Raspbian upgraded "fake-hwclock/stable 0.11 to 0.11+rpt1 today — will this possibly affect Internet-in-a-Box?

3 recent threads:

• "Raspbian systemd-timesyncd saving system time instead of using fake-hwclock"
  https://www.raspberrypi.org/forums/viewtopic.php?t=200385
• "Fake-hwclock still needed?"
  https://www.raspberrypi.org/forums/viewtopic.php?t=215602
• "rtc DS3231 not updating system with new raspbian GNU Linux 9 stretch"
  https://raspberrypi.stackexchange.com/questions/79318/rtc-ds3231-not-updating-system-with-new-raspbian-gnu-linux-9-stretch

[holta]

@jvonau recommends removing the bug tag here, which I just did, as the "bug" is basically in the hardware.

In short, this tkt will be kept open for now, for informational purposes.

[holta]

@avni let's review above, as DS3231 hardware is being investigated.

Quick summary of this RTC landscape (priority questions, for RPi 4 especially) is emerging on top of:

http://minutes.iiab.io (under "Sept 3, 2020")

[jvonau]

close?

[holta]

close?

Tough question.

(As a long-term goal, this appears still relevant...)