Modifying an Inexpensive Clock I like to be more accurate

[RubyRhod]

Hi.  First time poster and hope to gain some knowledge and share some as time progresses.

I have a clock I like that doesn't keep very good time gaining about a second a day.  The clock uses a HT48R30A-1 microcontroller and a 32.768 kHz crystal is used as the timing source across pins 17 and 18 of the MCU.  I am considering simply swapping out the 32.768kHz crystal for a SiTime SiT1556 TCXO with a +/- 3ppm accuracy.  Do you think I can simply inject the signal from the TCXO at the point where the crystal is soldered to as long as I can supply the appropriate VDD to the TCXO?

Also, there is noticeable differences in LED light levels across the alpha numeric characters per attached picture) that may be caused by differences in the as-measured values of the 47ohm and 330 resistors attached to the display devices.  I intend to replace those resistors with 1% tolerance jobs just to be sure.

Any thoughts would be greatly appreciated!

Thanks!

[Benta]

The oscillator should be accurate enough by itself, which leads to the question: why is C2 missing?

[ataradov]

This device has some strange and unconventional clocking options with datasheet being very brief on this. I think TCXO should work if you feed its output into the OSC1 pin.

But often simply replacing a crystal with something better is enough.

I doubt even 10% difference would be enough for appreciable difference in brightness. It is likely due to the way matrix is scanned. But replacing the resistors won't hurt.

[ataradov]

why is C2 missing?

This holtek has some weird clocking options. You can see that one capacitor is a valid configuration for "Internal RC oscillator with RTC". This is the only valid configuration for a 32 kHz clock. Full crystal oscillator needs two capacitors and a feedback resistor, but only works for higher frequencies. 

There seems to be no documented option for an external clock source.

[Gyro]

It might be worth trying replacing the missing C2 with a 2 - 22pF trimmer cap. It might give you a cheap and reasonably accurate frequency adjustment - as opposed to the manufacturer's ham fisted one!


P.S. Welcome to the forum!

[iMo]

Go with the external TCXO and feed it into the OSC1. Remove any capacitors on OSC1/2.
+/-3ppm TCXO gives you +/-8secs per month, provided my math is ok..

[RubyRhod]

Oddly the missing cap, the 10 pf, was on the other side of the board.

[RubyRhod]

Yep. The other 10 pf is on the other side of the board for some weird reason.

[RubyRhod]

Ordered from Mouser!

[MikeK]

I agree with Gyro, I'd go after the caps first.  2 x 10pF is likely too low for a typical watch crystal.

[strawberry]

43mA per LED? could be worn LEDs or something with MUX

[RubyRhod]

Thanks Strawberry.  The clock display was actually like this when brand new so I think it could probably be the muxing arrangement.  I should have sent it back but didn't and now it's too late and is a project.

[MikeK]

By the way, I made a clock not too long ago, with a microcontroller running from a cheap Chinese watch crystal.  I got it to under one second after two weeks.  I did the trimming in software, but it could have been done with the caps.  Plenty of reasonably accurate watches using those crystal.  So, it *can* be done, if you were so inclined.

[RubyRhod]

Excellent and good to know even cheap xtals can be tweaked. If I can't get the TCXO to work, I'll probably replace one of the 10 pf caps with a trimmer and start playing.

[MikeK]

Is the TXCO trimmable?  3ppm is 1.8 seconds per week.

[RubyRhod]

No but I can live with that and I'm feeling really lucky that Mouser will pick me one that is spot on    Just kidding.  I can live with that amount and, if I can't, I'll get the trimmer as mentioned above and start playing.

[golden_labels]

Also, there is noticeable differences in LED light levels across the alpha numeric characters per attached picture) that may be caused by differences in the as-measured values of the 47ohm and 330 resistors attached to the display devices.  I intend to replace those resistors with 1% tolerance jobs just to be sure.

I can see the same situation on product photos, e.g. on Amazon. So it seems it’s not that you received a unit with a particularly bad subset of resistors.

I would say it’s a design issue. Note how brightness corelates with the number of LEDs being on in a column. As if there was not enough current to supply to all rows at the same time.

Is the TXCO trimmable?

If you open the case and replace/add components

3ppm is 1.8 seconds per week.

Rubidium standard should provide better!

No but I can live with that and I'm feeling really lucky that Mouser will pick me one that is spot on    Just kidding.

Actually you have very good chances of obtaining something much better than the worst case specs. Thanks to the normal distribution.

[RubyRhod]

Also, there is noticeable differences in LED light levels across the alpha numeric characters per attached picture) that may be caused by differences in the as-measured values of the 47ohm and 330 resistors attached to the display devices.  I intend to replace those resistors with 1% tolerance jobs just to be sure.

I can see the same situation on product photos, e.g. on Amazon. So it seems it’s not that you received a unit with a particularly bad subset of resistors.

I would say it’s a design issue. Note how brightness corelates with the number of LEDs being on in a column. As if there was not enough current to supply to all rows at the same time.

No but I can live with that and I'm feeling really lucky that Mouser will pick me one that is spot on    Just kidding.

Actually you have very good chances of obtaining something much better than the worst case specs. Thanks to the normal distribution.

I agree with your points and it's probably a design issue.  As a side note, the clock has a three-setting intensity adjustment and, regardless of the intensity setting be it low, medium or high, the perceived intensity differences persist.

Yep, it's a purchase I made from Amazon.

[ledtester]

An alternate idea... replace the Holtek with an Arduino or a Wifi capable MCU module (ESP32 / RPi Pico W) and set the time using the Internet using the NTP protocol or via a WWVB module that you can get for around $8 on aliexpress/ebay.

[RubyRhod]

An alternate idea... replace the Holtek with an Arduino or a Wifi capable MCU module (ESP32 / RPi Pico W) and set the time using the Internet using the NTP protocol or via a WWVB module that you can get for around $8 on aliexpress/ebay.

That would be the ideal solution without a doubt but one that is way out of my league skill-wise.  I admire those of you who have the skill to pull off a modification like that!

I also found another solution and that is is a miniature OCXO by SiTime with a +/-3 parts-per-billion accuracy/stability that should get me to an accuracy of 1 second in 3,858.02 days (if my math is correct).

[tooki]

The matrix brightness is because of the matrix design, such that the current limiting resistor is shared across the whole column, so the lit LEDs within a column are essentially in parallel. The more LEDs lit, the less current per LED. I’ve seen the exact same thing on eBay/Aliexpress clock kits I’ve built.

[RubyRhod]

Thanks tooki.  I suspect that, in the end, I will not be able to resolve the issues with differences in dot brightness and will end up calling it a "feature" of the clock and living with it.  Or I'll toss it into the garbage bin 

[RoGeorge]

Is the clock ticking too fast, or to slow?

When we were teenagers we used to tune electronic wrist watches by adding a very small capacitor in parallel with the 32768Hz resonator. 

Since SMD parts were not yet a thing, and there was virtually no room inside a wrist-watch, the tuning capacitor was a DIY hand made:
- on a piece of 0.5-1mm thick CuEm wire of about 1-2cm long, wind 0.1-0.2mm diameter CuEm wire on the entire length of the thick piece of wire, one layer of thin wire, no interleave space
- cover all with nail lacquer and keep all tight until the lacquer solidifies
- at one side of the thick wire, remove the Em isolation for both the thick and the thin wires
- solder that in parallel with the 32768Hz resonator

Frequency adjustment is made by un-winding and cutting away a few turns from the thin wire each time, then let it run for 1-2 days to compare the time, then uncoil from the loose end a couple more turns and let it run a few more days again, and so on until you get a reasonable small time skew.  Leave uncut the empty end of the thick wire that remains after consecutive un-winding of the thin wire, always cut only the un-winded remaining of the thin wire. 

[RubyRhod]

Thanks much.  It's "ticking" too fast (about a second a day) and your suggestion makes sense.  I like the idea of building your own capacitor!  The resonator has a couple of 10pf caps in the circuit and I could replace one of them with a small variable and tweak to my heart's content.  I may do that if I can't get the TCXO already purchased ($4) to work out.

[RubyRhod]

I got the 1% resistors and the TCXOs.  The TCXOs are so darn small that I can't even "see" them let alone figure out how to solder to the pads 

I think I'll get a 2-22 pf trimmer and install it in place of one of the 10 pfs in the circuit and start tweaking.

[MikeK]

You may wind up replacing one 10pF with a 15 or 22pF and a variable in place of the other.  A pair of 10pF seems much too low for a watch crystal.  Note that the frequency and capacitance are inversely related...In order to lower the frequency you increase the capacitance.  I usually wind up with a pair of 22pF for a watch crystal.

C_L = (C₁ x C₂) / (C₁ + C₂)   +  C_STRAY

[RubyRhod]

Thanks Mike!  I will replace one with a variables as you suggest and roger that on the inverse relationship.  I wonder if trimmers are "NPO" or not?

Something odd about the current limiting resistors on the alphanumeric displays.  Some of my undiagnosed dyslexia on display when I read the color code and also with respect to the resistors I ordered.  The resistors were actually 75 ohms, for some strange reason I ordered 47 ohms, and the nomenclature on the PCB for the 40 resistors read 33 ohms.  As predicted by some of the folks trying to help me out, there was no change in the relative brightness of the columns and rows of LEDs.

[ataradov]

How can you say that it is low when there is literally zero information on the design of that oscillator? It may have some intrinsic capacitors. It is not even documented to work with 32 kHz crystal with two capacitors. The only documented configuration for 32 kHz is one 10 pF capacitor.

[MikeK]

How can you say that it is low when there is literally zero information on the design of that oscillator? It may have some intrinsic capacitors. It is not even documented to work with 32 kHz crystal with two capacitors. The only documented configuration for 32 kHz is one 10 pF capacitor.

All of the watch crystals I have ever used were spec'd for a load capacitance of about 10 to 12pF (if I remember right).  A quick check of 32.768kHz crystals online show a spec'd load capacitance of 12.5pF.  This results in C1 and C2 being about 22pF.  So that's how it seems low to me.  I wasn't declaring from the mountaintop that "I sayeth it be too low."

[MikeK]

By the way, keeping one 10pF and using a 22pF variable only gets you to a C_L of about 7pF.  A 15pF and a 22pF gets you to about 9pF.  So stick the variable in there and don't be surprised if you max it out and have to replace the 10pF with a fixed 15pF or 22pF.

[RubyRhod]

I replaced C2 with a 4-27pf variable.  I set the variable to mid-range and let the clock run for a couple of days and noticed little to no change in the frequency of the oscillator.  Maybe I got lucky in setting the variable to the value of the fixed or maybe it's really going to be a challenge pulling the crystal's frequency.  Your thoughts?

[RoGeorge]

Put the variable C in parallel with the Quartz, and the clock will run slightly slower.

The two small C to ground are there mostly to have a reliable and fast starting of the oscillator, they don't affect the frequency that much.

[RubyRhod]

Put the variable C in parallel with the Quartz, and the clock will run slightly slower.

The two small C to ground are there mostly to have a reliable and fast starting of the oscillator, they don't affect the frequency that much.

Many thanks for the point out!  I'll give it a shot!

[RubyRhod]

I got a low value (2pf to 18pf) trimmer capacitor and replace c2 with the variable.  Little to no change in the timing of the clock regardless of the setting of the cap.  I then put the cap in parallel with the crystal and was able to get the clock to slow down but way to slow even at the 2pf minimum setting.   I decided to order several 1 pf NPO multi-layer ceramic caps from Mouser and start playing with paralleling the crystal with a capacitance value of my own making.  One (1) pf was still too much capacitance as the clock still ran slow.  I than configured a 0.5 pf cap and that got me close although the clock ran a second or so fast in three days.

I finally found a vendor that manufactures multi-turn trimmer capacitors with sapphire dielectric material in the proper range I was looking for, in this case I ordered a nine turn  0.3 to 1.3 pf SMD trimmer from Digikey to put across the crystal.  I should be able to tweak to my hearts content but need to make sure the clock is in a temperature-controlled environment from here on out 

[RoGeorge]

You can get a smaller capacitance by connecting them in series.  Cfinal = (C1*C2)/(C1+C2).

For example:  2.2pF series with 2.2pf series with 2...18pF = 0.709...1.365pF

Another advantage of putting more capacitors in series, aside from being cheaper to procure a bigger trimmer and getting a finer adjustment, would be that you may find different types of capacitors, some with positive and some with negative temperature coefficients, so to lower the overall thermal coefficient when connecting them in series.

However, even a Rubidium disciplined clock will have drift, so you may want to look for some other clock that can self adjust their error, either by the help of time broadcasting radio towers, or GPS, or maybe over NTP if Internet is available.  Running a solution that synchronizes from outside would be cheaper and guaranteed more accurate than running an ovenized 32768 tuning fork.

Meanwhile, while you are waiting for the newly ordered parts to arrive, why don't you try to wound two wires together as I described earlier, I remember it was working pretty well once trimmed.  It takes nothing to coil two wires together.

Either way, good luck getting the perfect clock, but remember there is a reason for why the guys into precision clock are called "time nuts", or why there are sayings like "A man with a watch knows what time it is. A man with two watches is never sure." 

By the way, there's a great documentary about the need of accurate timing and the struggle of how to get this right for the very first time, and how it all started when a big prize was set for it:

Nova Lost At Sea The Search For Longitude PBS Documentary

[RubyRhod]

Hi RoGeorge.  I will try your idea of the two wires for fun and yes, you are right, even the best clocks drift.  Thanks again for the reply!

[artag]

An alternate idea... replace the Holtek with an Arduino or a Wifi capable MCU module ..

That would be the ideal solution without a doubt but one that is way out of my league skill-wise.  I admire those of you who have the skill to pull off a modification like that!

Another option would be to leave the original microcontroller in place and add an ESP32 or similar. You should be able to find existing example code which will obtain accurate time from the internet and provide an event in the code that occurs once per second.

You can then set up a timer to generate a signal close to 32768Hz  but slightly variable above or below. You can then switch between speeds to generate 32768 pulses every second. If there is a small error, you can accumulate it until large enough to correct with a swing the other way. The only requirement is that the long-term average is exactly 32768.

This signal is then fed to the xtal input in the same way as  your tcxo. The result is better than a tcxo for long-term drift but using existing or borrowed code (in the old micro and the new esp32) rathervthan having to write the whole thing from scratch.

It may also be possible to source a 32768Hz output from a GPS-disciplined oscillator - I can't see an appropriate divider in the picdiv range (http://www.leapsecond.com/pic/picdiv.htm) but I know some exist that aren't listed on that page - you'd want 'pd30'.

 

[artag]

The matrix brightness is because of the matrix design, such that the current limiting resistor is shared across the whole column, so the lit LEDs within a column are essentially in parallel. The more LEDs lit, the less current per LED. I’ve seen the exact same thing on eBay/Aliexpress clock kits I’ve built.

Ideally, you would put all the necessary resistance in the row circuit and none in the column circuit. Then the column drive is made strong enough to supply all possible leds in the column. They may in fact have done this, but have used poor drivers (perhaps just microcontroller pins) that can't provide enough current. You can add an extra transistor per  column to improve the situation.

You might think that because the brightness varies even at lower settings, where the column driver is less stressed, that this isn't the problem. But the brightness setting is probably not done by changing the current, but by changing the width of the multiplex signal. This means that even at low brightness settings the current peak is as large - it's just narrower, so it still results in column drive voltage drop.

[ledtester]

I have one of these clocks. I picked it up from a thrift store a while ago and it's been sitting around waiting for me to play with.

Here's what I've found out so far...

- The "vertical" wire jumper closest to the coin cell holder is ground (see pic below)
- The wire jumpers next to the "8550" transistors are directly connected to GPIO pins of the HT48R mcu
- The left ends of the 1K resistors next to the "1300" transistors also are directly connected to GPIO pins

Here is a pic of how I probed some of the GPIO lines:



And here is a scope trace of those probes:



I also probed the wire jumpers next to the "8550" transistors, but their waveforms were a little funnier looking.

The point is this... one way to measure the effect of your crystal tweaking is to probe the signal at the base of the 1300 transistors. If you have a scope or frequency counter with high enough resolution you can get more immediate feedback on the effect you're having on the crystal.

From the scope trace I took it is quite likely that the frequency at the base of the 1300 transistors is designed to be exactly 64 Hz when the crystal frequency is 32.768 KHz.

The scope trace shows the enable signals for two different rows (or maybe columns) and you can tell that they have the same period but are staggered in time.

Update: If you don't have a frequency counter or scope you can use an Arduino to time the period of the 1300 signals.

[ledtester]

And, fwiw, here is a close-up of the oscillator section on my board:

[RubyRhod]

And, fwiw, here is a close-up of the oscillator section on my board:

(Attachment Link)

Thanks for that.  Is your clock set up as a 12hr or 24hr clock?  Mine is 12hr with a resistor installed in the "10mm" jumper section that is not populated on your board.

Regarding the timing, I connected two 1pf NPOs in series (0.5pf total) across the crystal and the clock is hovering around +/- 0.25 seconds in a week's time.

I have a .3pf to 1.3pf Johanson Giga-Trim multi-turn trimmer that I will probably install over the next couple of days.

I appreciate all the other suggestions about how to replace the crystal with other timing sources but writing and implementing code is a little beyond my current skill set.