1) The dramatic drop and bounce are intentional. They would be trivial to compensate for in software, but it would make the clock a lot less interesting to watch.
2) You don't need protection diodes for the meter coils because it's a push-pull drive that is low impedance throughout the PWM cycle. Further, the current through the coil is trivial, the inductance is relatively low, and with the SRL=1 slew-rate limit, the MCU switching speed is to the order of ~40 ns, so even with on-off drive, there wouldn't be much of a voltage spike.
I don't think there's any problem with smaller meters, you'll just get a smaller clock. I think they would work for a nightstand / desk clock, maybe not something you want to be able to read from a distance.
You need to draw your own templates. It's not hard, that's what I did. Just take one meter apart (two screws on the sides), then unscrew the faceplate (two screws in front), then measure the dimensions carefully and sketch it out in any vector drawing or CAD program.
I was able to load the code onto the AVR via the $10 snap today. Working well thank you! Time set buttons appear to work using jumpers on a breadboard, I was not able to get the time set to wraparound past the max value. It looks like from the code if the min or hour was maxed out then the system would set it to zero, is that correct?
Yes, that's the idea. Are you sure it *never* wraps around, or did you stop when it hit the upper end of the meter and didn't budge after a couple of additional inputs? If the latter, I'd try several more times, in case the meter just isn't calibrated well.
I don't see anything wrong in the key reading code - if pressing the keys advances the meter, it should wrap around once the hour hits 12:
/* Key 0 advances the hour dial without messing up any of the other dials. */
if (!(pd & 0b01)) {
if (++cur_hr == 12) cur_hr = 0;
}
I also don't see anything obviously wrong with the PWM output code. It's possible that I made some typo when preparing the file for publication, but it looks the same as the earlier published code for the v1 clock.
Thanks I will check that, I forgot that the button press subroutine will zero out the values once they are maxed. I know the subroutine is working becasue I can advance the dials so my guess is that I did not try enough. Thanks again
Thank you for this great writeup and approachable and straightforward set of instructions!
I will be making a clock myself using this guidance. I plan, however, to make one using the square style 62C voltmeters like your 2019 version. I was wondering if you may still have printable dial templates for the square voltmeters?
Thanks. It should be DB28. DA28 doesn't support external high-frequency clocks, so the circuit and the code would need to be modified slightly (to use a 32.768 kHz clock on different pins and to generate the interrupt a bit differently).
Interesting about the hum, I guess it depends on your luck. Another way to reduce it without software changes would be to toss in an appropriately-sized capacitor in parallel with each meter.
I did try a number of different size capacitors in parallel with the meters first before ultimately changing the software. I found that for the size capacitor I needed to eliminate the noise it significantly changed the dynamics of the motion of the second-hand. I.e. the hand would rise very slow at first then catch up at the end of a minute. I couldn't make sense of it as the hypothetical time constant by introducing the capacitor should have been minuscule, but it's nonetheless what I observed. I was hoping to hook things up to an oscilloscope to introspect further but never got around to it.
Fair enough! Yeah, audible artifacts are always fun with PWM and I don't think anyone can really predict them reliably. I had a fair number of brand-name switching power supplies that emitted various squeals.
I finished my clock! Do you mind if I upload my version of the code to a github repo? I ended up making some changes. I would of course attribute you and this blog as a source. I'll follow up with some notes from my build.
I love the use of the older 8-bit microprocessor and the minimalist approach. Where can I find a minimal tutorial of the interface needed to compile and download the code? It looks as simple as attaching a serial communication line to pin 19 ?
I do cover it in my book!=) But the TL;DR is that the path of least resistance is to buy a programmer such as MPLAB SNAP ($10) or Atmel-ICE ($80), which connects to your computer over USB. You then connect the business end of the programmer to the three pins marked in the schematic: UPDI (data), Vdd, and GND (reference voltages).
With this done, you can then download MPLAB IDE from Microchip to compile and upload the code. It's also possible to use an open-source toolchain (which is what MPLAB IDE is behind the scenes): avr-gcc + avr-libc + avrdude for operating the programming dongle, but this is a bit more finicky.
I really enjoyed reading this. Despite barely understanding any of it! I don't know much about MCU's, so I guess that has to be my first detective task.
I don't have the skills to do the wordworking part of this, but I'd love to do one of these but use something like an ESP32 so I could keep the clock sync'd to NTP wia WiFi.
Sure. Ultimately, a good crystal will lose or gain at most a few minutes per year, so accuracy gains alone are probably not worth it, but free DST adjustment might be.
I actually addressed that in my design, just didn't talk about it because I figured it's a niche need. But there's a supercapacitor (1 F) on the supply side that keeps the clock going without power for a good while.
That's a really nice use of a voltmeter :-) Bookmarked for future reference, for when I have the time to do a project like this (probably never, but still).
Very nice! I like how smoothly the second gauge moves.
Question: I've been toying with the idea of building my own MCU powered clock. The gimmick with mine is I want to use an OCXO, so it's a super accurate quartz clock (as accurate as possible without GPS or rubidium). Anyway, the designs I've looked at are similar to how you've done it. They connect the oscillator to the interrupt pin. But it occurred to me the oscillator could just be the MCU's external clock signal. Then the MCU doesn't need an interrupt handler. It can just examine its own tick counter. Can you see any issues with that? Is there a reason you went the interrupt route instead? Maybe the reason is "that's what worked for the parts I had laying around" but wondering if there's a technical reason.
I mean, if you're being serious, it's a losing game. It's labor-intensive to make, people are accustomed to electronic gadgets of this sort costing less than takeout, and then if you're even modestly successful, someone in China will undercut you.
I could do a $100k Kickstarter and then disappear, though...
Some postscripts, based on forum comments:
1) The dramatic drop and bounce are intentional. They would be trivial to compensate for in software, but it would make the clock a lot less interesting to watch.
2) You don't need protection diodes for the meter coils because it's a push-pull drive that is low impedance throughout the PWM cycle. Further, the current through the coil is trivial, the inductance is relatively low, and with the SRL=1 slew-rate limit, the MCU switching speed is to the order of ~40 ns, so even with on-off drive, there wouldn't be much of a voltage spike.
3) For internet sleuths: the earliest mention of a voltmeter clock that I could find is this 2007 article: https://makezine.com/article/maker-news/the-chronulator/
https://web.jfet.org/weston-clock/
https://web.archive.org/web/20060303053706/https://web.jfet.org/weston-clock/
Pedantic, but I think this clock is slightly earlier. It's quite a weird design (one meter, runs it off 180 V!) but probobly counts.
It's honestly magical to watch. Kudos!
I have a few spare SO45. Is it too small? How can I convert the templates?
I don't think there's any problem with smaller meters, you'll just get a smaller clock. I think they would work for a nightstand / desk clock, maybe not something you want to be able to read from a distance.
You need to draw your own templates. It's not hard, that's what I did. Just take one meter apart (two screws on the sides), then unscrew the faceplate (two screws in front), then measure the dimensions carefully and sketch it out in any vector drawing or CAD program.
I was able to load the code onto the AVR via the $10 snap today. Working well thank you! Time set buttons appear to work using jumpers on a breadboard, I was not able to get the time set to wraparound past the max value. It looks like from the code if the min or hour was maxed out then the system would set it to zero, is that correct?
Yes, that's the idea. Are you sure it *never* wraps around, or did you stop when it hit the upper end of the meter and didn't budge after a couple of additional inputs? If the latter, I'd try several more times, in case the meter just isn't calibrated well.
I don't see anything wrong in the key reading code - if pressing the keys advances the meter, it should wrap around once the hour hits 12:
/* Key 0 advances the hour dial without messing up any of the other dials. */
if (!(pd & 0b01)) {
if (++cur_hr == 12) cur_hr = 0;
}
I also don't see anything obviously wrong with the PWM output code. It's possible that I made some typo when preparing the file for publication, but it looks the same as the earlier published code for the v1 clock.
Thanks I will check that, I forgot that the button press subroutine will zero out the values once they are maxed. I know the subroutine is working becasue I can advance the dials so my guess is that I did not try enough. Thanks again
Thank you for this great writeup and approachable and straightforward set of instructions!
I will be making a clock myself using this guidance. I plan, however, to make one using the square style 62C voltmeters like your 2019 version. I was wondering if you may still have printable dial templates for the square voltmeters?
Yes! https://lcamtuf.coredump.cx/soft/embedded/meter_clock.pdf
Note: I noticed a discrepancy in your blog post which references the MCU AVR128DB28 while your shared source code mentions AVR128DA28.
The difference between these MCUs may be minor and perhaps the source would work for either, but I wanted to point it out incase it was a mistake.
Thanks. It should be DB28. DA28 doesn't support external high-frequency clocks, so the circuit and the code would need to be modified slightly (to use a 32.768 kHz clock on different pins and to generate the interrupt a bit differently).
Hooray, thanks! I'll follow up to share when I complete my clock :)
Find at the following github page a writeup and photo of my clock. I largely copied your original design, even down to the wood frame.
https://github.com/mike4192/voltmeter_clock/tree/main
Thanks again for the writeup and inspiration. I love how it turned out!
Interesting about the hum, I guess it depends on your luck. Another way to reduce it without software changes would be to toss in an appropriately-sized capacitor in parallel with each meter.
I did try a number of different size capacitors in parallel with the meters first before ultimately changing the software. I found that for the size capacitor I needed to eliminate the noise it significantly changed the dynamics of the motion of the second-hand. I.e. the hand would rise very slow at first then catch up at the end of a minute. I couldn't make sense of it as the hypothetical time constant by introducing the capacitor should have been minuscule, but it's nonetheless what I observed. I was hoping to hook things up to an oscilloscope to introspect further but never got around to it.
Fair enough! Yeah, audible artifacts are always fun with PWM and I don't think anyone can really predict them reliably. I had a fair number of brand-name switching power supplies that emitted various squeals.
I finished my clock! Do you mind if I upload my version of the code to a github repo? I ended up making some changes. I would of course attribute you and this blog as a source. I'll follow up with some notes from my build.
Go for it.
I love the use of the older 8-bit microprocessor and the minimalist approach. Where can I find a minimal tutorial of the interface needed to compile and download the code? It looks as simple as attaching a serial communication line to pin 19 ?
I do cover it in my book!=) But the TL;DR is that the path of least resistance is to buy a programmer such as MPLAB SNAP ($10) or Atmel-ICE ($80), which connects to your computer over USB. You then connect the business end of the programmer to the three pins marked in the schematic: UPDI (data), Vdd, and GND (reference voltages).
With this done, you can then download MPLAB IDE from Microchip to compile and upload the code. It's also possible to use an open-source toolchain (which is what MPLAB IDE is behind the scenes): avr-gcc + avr-libc + avrdude for operating the programming dongle, but this is a bit more finicky.
Excellent, this is just what I need to get started. Where can I find your book?
https://lcamtuf.coredump.cx/electronics/
I really enjoyed reading this. Despite barely understanding any of it! I don't know much about MCU's, so I guess that has to be my first detective task.
I don't have the skills to do the wordworking part of this, but I'd love to do one of these but use something like an ESP32 so I could keep the clock sync'd to NTP wia WiFi.
Sure. Ultimately, a good crystal will lose or gain at most a few minutes per year, so accuracy gains alone are probably not worth it, but free DST adjustment might be.
And power outages.
I actually addressed that in my design, just didn't talk about it because I figured it's a niche need. But there's a supercapacitor (1 F) on the supply side that keeps the clock going without power for a good while.
That's a really nice use of a voltmeter :-) Bookmarked for future reference, for when I have the time to do a project like this (probably never, but still).
Cool project! For anyone interested in the square meters just search for “62C voltmeter”
Very nice! I like how smoothly the second gauge moves.
Question: I've been toying with the idea of building my own MCU powered clock. The gimmick with mine is I want to use an OCXO, so it's a super accurate quartz clock (as accurate as possible without GPS or rubidium). Anyway, the designs I've looked at are similar to how you've done it. They connect the oscillator to the interrupt pin. But it occurred to me the oscillator could just be the MCU's external clock signal. Then the MCU doesn't need an interrupt handler. It can just examine its own tick counter. Can you see any issues with that? Is there a reason you went the interrupt route instead? Maybe the reason is "that's what worked for the parts I had laying around" but wondering if there's a technical reason.
Oh wait! Looking at the code, this is what you did, I think. Ok well glad to see I wasn't totally off base with my planned design.
Really nice.
Sooo do you sell them?
I wouldnt personally sell them; but there are people who love this kind of special item. Engineers, mechanics, etc is all
I mean, if you're being serious, it's a losing game. It's labor-intensive to make, people are accustomed to electronic gadgets of this sort costing less than takeout, and then if you're even modestly successful, someone in China will undercut you.
I could do a $100k Kickstarter and then disappear, though...
Still more circuitry than my feeble skills could manage, but very nice work
Lovely work.