Posted by tokyobreakfast 6 hours ago
The most interesting part, IMO, is the "SRAM with EEPROM backup" chip. It allows you to persistently save the clock hands' positions every time they're moved, without burning through the limited write endurance of a plain old EEPROM. And it costs less than $1 in single quantities. That's a useful product to know about.
So the way this works seems to be this: It's an SRAM and an EEPROM in one little package along with a controller that talks with each, with a little capacitor (this clock uses 4.7uf) placed nearby.
The SRAM part does all of the normal SRAM stuff: It doesn't wear out from reading/writing, and as long as it has power it retains the data it holds.
The EEPROM does all the normal EEPROM stuff: It stores data forever (on the timescale of an individual human, anyway), but has somewhat-limited write cycles.
The controller: When it detects a low voltage, it goes "oh shit!" and immediately dumps the contents of the SRAM into EEPROM. This saves on EEPROM write cycles: If there are no power events, the EEPROM is never written at all.
Meanwhile, the capacitor: It provides the power for the chip to perform this EEPROM write when an "oh shit!" event occurs.
When power comes back, the EEPROM's data is copied back to SRAM.
---
Downsides? This 47L04 only holds 4 kilobits. Upsides? For hobbyist projects and limited production runs, spending $1 to solve a problem is ~nothing. :)
(Hey Dang. Can we get a ban button? There's a few people here that are impossible to conduct rational discourse with. My sanity would improve if they were simply gone from my view.)
Please stop fucking with people in this way. It's callous, unnecessary, and antithetical to the greater good. We don't come here to get accused of things.
(edit: Today, I learned about the existence of a chip that does a clever thing. That made me curious: After all, I've been passively wondering for -decades- about how electronic things remember their previous state without power, and without hammering an EEPROM.
I could have learned more about this at any time over the years, but I just never bothered with doing so.
And today, it was right in front of my face -- with a part number! That gave me a very easy place to start, so I started.
I read up on it a bit using the datasheet and a whitepaper. I learned some about how it does that clever thing, and I wrote a few sentences about this new-to-me stuff in a way that I felt would be approachable and appreciated by this particular audience.
That's what we're here for -- to be curious, to share ideas, and to learn stuff from others. Not for fucking with people.)
An extra UI element or two should be enough. Maybe with sticky options for collapse-by-default or hide-by-default at the top of each HN comment section.
And the list of usernames can be stored and edited in the purveyor's HN bio (in plain text, like a monster), so that it works automatically across devices.
Particularly I like that I can get those large enough to stick a ring buffer from debug out on them as well and get crash logs from embedded systems despite the debug uart not being tethered to a dev machine.
The red projection is just the right brightness (at night) but it sucks that it's not wifi-enabled so you can't just get it to NTP sync (or hook up a GPS receiver). The projector part of the clock is a separate device that's attached to it via a ribbon cable. I would reverse engineer it myself but I haven't got the time.
Ideally, I'd want a matrix of LEDs projected on to the ceiling so I could get more info than just the time. Such clocks exist but they're super duper expensive! Example: https://buyfrixos.com/
There are UK and Japan clocks that work similarly, but use national time sources. There are G-Shock watches which synchronize from multiple sources. While running on solar power. Those keep accurate time with no maintenance. That's an impressive achievement.
YMMV depending upon location. I've never gotten a WWVB clock to work in North Carolina. If you're lucky, the signal works on the east coast at night in an outdoor location:
https://tf.nist.gov/tf-cgi/wwvbmonitor_e.cgi
I've never been lucky indoors and never had a WWVB clock synchronize successfully overnight.
They also don't transition DST automatically, so you're pulling them off the wall twice a year unless you're in one of the rare US locations that don't adhere to the DST silliness.
> The DST status bits indicate United States daylight saving time rules.
Days spent modifying cheap electronics is absolutely encouraged.
Turns out it's possible to emulate the atomic clock signal quite easily with a Raspberry Pi, or in my case I put together Arduino code that can emulate atomic clock broadcasts from around the world using an ESP32 module using NTP servers: https://github.com/tanvach/clocksync
The history of these atomic clock broadcast signals and their differences in different countries is quite fascinating.
I got one for my daughter. The erratic ticking eventually became a distraction when she was studying, so we have retired it for now. But we got a lot of amusement out of it.
That's pretty genius for many ADHD-type folks. Only problem is a modern household has many clocks in view, so you'd need to commit to just not setting them.
Easy enough for wifi enabled ones: a UDP broadcast to discover other clocks on the network, then sync how you will.
For non-wifi-enabled clocks, perhaps something like a CH572 would do the trick: a $0.20 RISC-V microcontroller with BLE support that all the clocks in the same vicinity could use to talk to each other.
You could really mess with your neighbors if they had the same clocks and you were within range...
Those signals are just weird mess of coils, switches and resistors.
ESP32 clock speed may also be a contributing factor.
As the author points out, the cheap quartz mechanism has no way of reporting the position of the hands (other than the hands themselves) and that you have to set the PULSETIME constant by the right number of milliseconds. If you're off by even a millisecond, that's going to accumulate quick enough that it would make a difference over even a single day, wouldn't it?
EDIT: as some have pointed out, the Lavet stepper theoretically accounts for this in that it steps exactly one tick after so many oscillations. That number of oscillations does not change so that's all you need to get right.
However, that basically just kicks the can down the road a bit in that if each step is not exactly 1/60th of a circle or bits wear down or get sticky or you have analog noise in there you will presumably still have a source of biased drift that you won't be able to detect. But maybe those affects are small enough that they don't matter for a wall clock.
I’m not saying these things matter much in this context.
The clock will still be far more accurate than purely mechanical version. And, re-synchronizing it is as trivial as turning the knob, just as you would for the all mechanical mechanism.
The smaller ones look the same but are less beefy.
I used one to make this clock:
https://www.secretbatcave.co.uk/projects/electromechanical-c...
Which instead of using a well disciplined time source, uses a tuning fork and 74xx logic to drive it
The receivers are inexpensive ($5-$10 for the kind of accuracy that's useful here) and it's not hard to parse the NMEA strings and PPS they output into a spooky-accurate internal clock. It only takes a few connections and an antenna to integrate GPS into an MCU like an ESP (or an SBC like a Raspberry Pi or a whatever).
Like, really: The hardware is ridiculously easy.
The only difficult part is the code. But as we can see from this posting, the clock-driving bits are already written and are available for use.
Just graft in the GPS parts instead of the NTP parts, add your DST/location rules if you really must (hint: that part is harder than it sounds), and send it.
(And if the code still seems arduous, then remember: This is the kind of work that a reasonably-focused person who is armed with a decent bot can put together over a cup of coffee or two, even if they don't speak C. It may be popular here to poo-poo the bot here, but it's completely OK to get some help. Don't let pride get in the way of having fun, learning things, and building neat stuff.
The tailor doesn't lament the invention of the cotton gin.)
[0] - https://www.nist.gov/pml/time-and-frequency-division/time-di...