Friday, February 6, 2026

Troubleshooting a Quartz Clock

 A twenty-five year old quartz clock stopped working.  I'm curious to see what has failed.   Opening up the clock, we see a simple one-layer PCB with a COB (chip-on-board), a crystal, a transistor and a magnetic buzzer.  The clock movement comes from the stepper motor with a coil resistance of 545Ω; the coil is driven in the alternative directions every second.  A number gears form the hour, minute and second hand.  The alarm is set with another gear that causes a spring loaded contact to short out two pads when the hour hand coincides with the alarm hand and as the hour hand moves it pushes the contact away from the pads to stop the buzzer.

The clock was not completely dead.  Occasionally, it started, but it would soon stop moving.  All the electrical connections seemed OK.  To be sure of no cold soldering joints, I reflowed all the joints.  I probed all the connections that were possible to get to and it appeared that the voltages were getting to the circuit; both the stepper coil terminals sat at the rail and there were bias voltages on the quartz crystal terminals.  I could not see any obvious wrong.  During the course of troubleshooting, despair set in the first time.  Where should I go from here?

We stepped back and asked, what could possibly go wrong for 25-year old device?  Nothing on the electronics side: the COB was unlikely, the crystal might age and be out of frequency spec but not dead, and the buzzer was irrelevant.  It was more likely the wear-and-tear of the mechanical parts. 

Now I started to take apart of more the mechanical parts.  The gears seemed free to move, so I should see some movement if the electronics were driving it.  I could eventually rule out mechanical issues by noting that some voltages for the alarm were not at the correct values.  The voltages at the crystal leads would be stuck at a higher values and the voltages to the motor coil was static when compared with when it was running (the pulse to the motor was brief but still visibly to the multimeter). It implied the clock was not oscillating and the circuit did not start.  I even replaced the crystal with another one that came from a digital watch, but it did not work.  It was progress but still frustrating.

After somewhat aimlessly and repeatedly probing, I noticed that it could consistently start when the multimeter leads were placed between one of the crystal lead and the negative terminal of the battery.  I could observe the voltage decreasing from around 1V to 0.7V.  Curiously, on the PCB, there is an unpopulated footprint between the crystal lead and the negative terminal of the battery.  So perhaps placing a 10MΩ resistor and/or some capacitor there might work.  And putting the leads on the other crystal terminal stopped the clock.  However, after started, the clock would stop after a short time and leaving the probes on the circuit would not keep it running.

But why would it need an extra capacitor now?  Is aging a factor?  Has the oscillator circuit deteriorated?  Accumulation of dust or FOD causes leakage or stray capacitance?   Here we went back to the fundamentals: how does a crystal clock work?  Quartz is a pure SiO2 crystal with the piezoelectric property, i.e. an electric field physically deforms the crystal structure and vice versa.  There is a restoring force that would result in vibration.  

So dust and FOD are a strong hypothesis.  A thorough cleaning of the PCB with 99% isopropyl alcohol miraculously worked; now it could consistently start.

Analog Ground and Digital Ground

 I think this concept of analog ground and digital ground trips every young engineer.  The school did not teach me about this when going through the standard EE curriculum. You may first encounter this when using analog-to-digital converters or some microcontrollers or other mixed-signal devices.

There are plenty of application notes talking about it.  You might hear about separating analog ground from digital ground because the digital ground is noisy.  It sounds appealing.  So you draw too different ground symbols to keep them separate.  Then the question becomes where and how do you tie them together.  Some suggest tying together with an inductor which would be high impedance to AC to keep noise out.  Some say tying at the power input and others say under the ADC.  There are also ground planes, split planes.

 Why do some ICs have two or more grounds (some power devices have power grounds)?  You have to look at this from an IC designer's point of view; say you are designing a successive approximation analog to digital converter, which has a sample-and-hold, comparators, and voltage reference, and digital decoder and interface circuitry.  Every time, the digital gates switch, small pulse of current flows out of the ground node through the GND pin; if this pin is shared by all these circuit blocks, it generates a common-mode voltages (mostly from the parasitic inductance of the bond wire), which is small enough not to affect the digital circuitry but can be significant to the analog circuitry.  So here you kick the can down to road by using a separate pin and let the board design deal with it.  Now the IC designer does not mean to have the two grounds at different potentials.  So it seems that these ground pins should be tied right under the IC, which is the recommendation of many datasheets and application notes.   

Some mixed-signal devices, like analog to digital converters, should be treated more like analog devices (like opamps).  But for some devices like microcontrollers, the analog circuitry is only a small fraction of the overall device; it does not seem to make sense to be a part of the analog circuitry.

The key to the solution is to consider current flow.  When a digital gate launches an edge transition, which is incredibly fast dvdt driving mostly trace  or pin capacitance.  The return current flows with it; it tries to follow a path of least impedance, which if not properly designed may sweep through board areas with sensitive analog circuitry.

 

Wednesday, November 19, 2025

LED Flashlight Again

I wrote about some LED flashlight that I built or purchased many years ago.   Recently the incandescent bulb on my Garrity flashlight burnt out.  I tried to find an LED replacement bulb.  At the price $3.5 a piece, it was disappointing: 0.3W@3V, 30 Lumens.  The LED bulb went from drawing 100mA at 3V to 7mA at 2.6V and is completely off at 2.4V.  That means it cannot be used with rechargeable NiMH batteries and the Li-Ion battery voltage is too high.  I decided to build my own LED replacement bulb (P13.5S type) again.  I want to run on both two NiMH cells or one Li-Ion cell (1.8-4.2V).  LTC3429 used previously can run on a Lithium-Ion battery but as a linear regulator with the efficiency in the 60s%.  

Here is a simpler solution.  We configure the circuit to be always boost.  We can take advantage of the built-in current limit of converters.  In LT1615, the switch current limit is 350mA.  We eliminate the Schottky diode; only an inductor and a capacitor are needed.  It works down to 1V (single alkaline cell).  Because LT1615 operates with a fixed off-time control, the switching frequency changes with the input voltage, from 200-300KHz. The average current through the LED varies from 85-140mA. The efficiency is around 80%.  It has as few components as it can possibly get.  The deficiency is that LT1615 is relatively expensive ($3 a piece at volume quantity) and its current limit is a little too low.

                                Ink Drawings

Here is the actual implementation. 

 

Thursday, November 13, 2025

Testing Antonki Thermometer/Hygrometer

 Antonki Thermometer/Hygrometer is sold at $8 for two.  It claims a temperature range of -50 to 70°C (-58 to 158°F) with accuracy +/-1°C and relative humidity range 10% to 99% with accuracy of +/-5%.  It is good value if it is indeed accurate.

We use SHT31 and HTU21 breakout boards with Arduino Nano and an OLED display module (0.96" OLED 128x64).  Arduino 3.3V output is used to power the sensors and the display.  Very quickly, we pull together the code needed to read from the sensors and display the data on the OLED module.  It shows the power of Arduino.   We update the reading every 3s.

 For temperature, we also have the analog thermometer, thermocouple, and PRT measured by multimeter, and Fluke non-contact IR thermometer.   The temperatures are measured at four settings, ambient (22°C), refrigerator (3°C), freezer (-18°C), and heater (50°C).

Here are the results.  It is pretty good at the room temperature, likely at which it is calibrated, but the readings deviate greater at the colder temperatures.

Sensor Freezer Refrigerator Ambient Heater
Antonki -15.9 5.5 22.2 46.5
HTU21 -17.3 5.8 22.6 46.5
SHT31 -17.1 5.5 22.4 46.6
TC -21.0 3.0 18.0 46.0
PRT -17.4 6.0 22.8 48.5
Thermometer -19.0 3.0 22.0 51.0
Fluke -16.4 4.2 22.546.5

We compare a few humidity readings.  Since HTU21 and SHT 31 disagree by 10%, it is hard to assess the accuracy.

Sensor Reading 1 (% RH) Reading 2 (% RH) Reading 3 (% RH)
Antonki 55.0 31.0 71.0
HTU21 46.5 26.2 59.0
SHT31 56.4 34.6 69.4

 It should also be noted that the response time of Antonki is slow; it takes time to stabilize the readings, especially the humidity.  

 In conclusion, Antonki Thermometer/Hygrometer is usable at normal room temperature range.

Tuesday, October 14, 2025

A Toaster Oven

 A very simple toaster oven costs about $20.  While the most consumer electrical appliances have microcontrollers inside and some are internet connected; this oven is pretty much mechanically controlled.  It has two quartz heating elements, 500W each  (measured around 4.5A each), at the top and the bottom.  The cold resistance is about 14 Ohms; Over 17A is drawn initially.  A spring winded mechanical timer sets time up to 30min or staying on.  The timer is more or less accurate (off by less than 3 mins for 30 mins).  The mechanical timer switches the live AC wire. 

The neural wire goes to the temperature control knob, which turns to set the temperature up to 450F in the toast mode, which both heat elements are on; the turning just pushes a spring loaded switch.  Turning further to the bake and the broil mode to turn on only the bottom and the top respectively; no temperature control in these two modes.  The temperature is controlled by a heat activated switch.  It does not actually sense the oven temperature, instead a current passes through a metal strip, which can be seen glow red; the heat bends a nearby bimetal strip to actuate the switch.  There is no earth ground connection; that seems risky if the AC wire is shorted to the chassis.


 How would this design compare with a more electronically controlled design in cost and reliability?

Monday, September 22, 2025

LED Fluorescent Tube Replacement

 The once ubiquitous fluorescent light tubes are gradually being replaced by the LED light.  The once popular compact fluorescent bulbs are already near extinct.  Two of my 3' fluorescent tubes are not working right: they do not light up fully.  They are the F30T12 rapid start type (30W, 1.5" diameter).   The ballast is rated at 120V 0.65A and has eight wires: white and black for neural and live AC input, two tubes share one pair of yellow wires and one pair of red and blue go to the other end of the tubes with the so-call "tombstone" holders.  While I'm not sure if the tubes are or the electronic ballast are bad (I do suspect the ballast since the tubes work sometimes), replacing with LED tubes is less expensive than getting new ballast or fluorescent tubes.  

An 18W T8 (1" diameter) LED tube costs about $7 (at quantities of a pack of 4); it can be installed plug-and-play (Type A) or with the ballast removed (Type B).  It is rated at 100-277V 0.18A.  It claims 45W equivalent and 2520lm 6000K, which would imply 140lm/W, a little high (as a comparison, a Philips 18W puts out 2000lm 6500K). The tube is made of two rows of LEDs, total 120 individual LEDs (laid out on a PCB with groups of 5 in parallel).  The back side is aluminum, where the LED PCB is mounted on, and the front is transparent plastic cover (not frosted).  The two pins at each end are shorted.  The tubes work when plugged into the existing fixture without modification, but I could notice some flickering and humming of the ballast.  There was a slight delay for the LEDs to turn on when starting cold; once warmed up, it started instantly.  When I measured the input current, I was surprised that it read 0.9A (that is over 100W), not only it exceeded the LEDs current by a lot (should be less than 0.4A) and but also more than the ballast rating.  Also the ballast seemed to fail completely after a few times.  I definitely need to try bypassing the ballast, which is straightforward.  Each LED tube draws only 0.135A, 16W (measured by the multimeter and the power meter); it is much better without the ballast: instant start, no humming and lower power (reduction of more than 50% with at least similar brightness if not brighter).

The common electronic ballast circuit is a resonant half bridge with a capacitor bypass.  Initially the current flows through this capacitor and heats up the filament; a higher strike voltage is generated to start arc discharge through the tube.  Afterwards the current through the bypass capacitor and the filament is reduced and the voltage across the tube is also lowered. A transformer feedback sustains the oscillation, which is over 10KHz. Some include power factor correction. The question is how the LED tube is able to tolerate the high voltage from the ballast.  One possibility is that it has a low-pass filter to attenuate the high-frequency voltage.

When I took down the ballast, it felt rather heavy, 3.5 lbs.  I realized that it is not an electronic ballast; it is the magnetic type.  The ballast is over 30 years old (possibly manufacture in 1991 based on a marking on the ballast). The inductance measurements are: black-white 390mH (10Ohms), yellow 47uH (0.4Ohm), blue 48uH (0.4Ohm), red 109uH (0.4Ohm).  The coils provide heating to the cathode.  The coils appear DC isolated.  When 120V AC is applied to black-white, about 4V AC on each coils, across yellow and blue is 226V and yellow and red is 5V (something seems faulty here).  Between blue and red is 1.4H, yellow and blue is 1H, yellow and red no inductance.  So there is an additional coil that is connected through capacitors; it functions like autotransformer to generate the high voltage.  So I suspect a broken capacitor.  Unfortunately, the ballast is completely potted.


Another question is, does a Type A only LED tube work without a ballast?  Testing confirms it does not work.  This is because this type of LED tube requires higher voltage provided by the ballast.  Other explanations out there make no sense. 

Friday, September 19, 2025

NVMe Speed Test

 The computer peripheral bus is eventually settled on PCIe and one small form factor expansion card is M.2 which provides up to 4 PCI express lane.   NVMe SSDs are now widely used and getting inexpensive.  Coming in size 2280/60/42/30.  M Key.


- Patriot Memory P310 NVMe PCIe M.2 Gen 3 x4 480GB $29.49 (6 cents/GB) 11/24

- Patriot Memory P310 NVMe PCIe M.2 Gen 3 x4 240GB $18.99 (8 cents/GB) 10/24

- Western Digital WD Blue Gen 3 x4 M.2 2280 500GB $49.99 (10 cents/GB) 6/22

- Lexar E-series 64GB Micro SD 100MB/s U3, A1,  $6.13 (10 cents/GB) each (for a pack of 3) in 10/24, 

- UGREEN 10Gbps M.2 NVME to USB3.3 Gen 2 $15.99 in 11/24

- ORICO M.2 NVMe USB3.1 Gen 2 (10Gbps) $18.99 in 6/22


ORICO + Patriot 480GB + Macbook Pro Linux

gnome-disks benchmark, 100MB 100 Samples
Average Read 458.4 MB/s
Average Write 417.6 MB/s
Average Access time 0.22 msec

dd if=/dev/zero of=/media/davex/Pat480G/dump.bin bs=1G count=100 status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 1696.78 s, 63.3 MB/s

dd of=/dev/null if=/media/davex/Pat480G/dump.bin bs=1G count=100 status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 242.579 s, 443 MB/s


UGREEN + Patriot 480GB + Macbook Pro Linux

exFAT

dd if=/dev/zero of=/media/davex/PAT480GXFAT/dump.bin bs=100M count=4K status=progress
429496729600 bytes (429 GB, 400 GiB) copied, 956.569 s, 449 MB/s

sudo dd if=/dev/sdd of=/dev/null bs=100M count=4K status=progress
429496729600 bytes (429 GB, 400 GiB) copied, 974.971 s, 441 MB/s

UGREEN + Patriot 480GB + PC Windows 10

exFAT

winsat disk -drive d
> Disk  Random 16.0 Read                       215.03 MB/s          7.8
> Disk  Sequential 64.0 Read                   642.06 MB/s          8.2
> Disk  Sequential 64.0 Write                  661.92 MB/s          8.2
> Average Read Time with Sequential Writes     0.190 ms          8.6
> Latency: 95th Percentile                     0.321 ms          8.8
> Latency: Maximum                             0.610 ms          8.9
> Average Read Time with Random Writes         0.192 ms          8.9

UGREEN + Patriot 240GB + Macbook Pro 

gnome-disks benchmark, 100MB 100 Samples
Average Read 458.5 MB/s
Average Write 420.8 MB/s
Average Access time 0.08 msec

dd if=/dev/zero of=/media/davex/Pat240G/dump.bin bs=1G count=100 status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 718.181 s, 150 MB/s

dd of=/dev/null if=/media/davex/Pat240G/dump.bin bs=1G count=100 status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 242.159 s, 443 MB/s


ORICO + Patriot 240GB + Macbook Pro Linux

NTFS

dd if=/dev/zero of=/media/davex/Pat240G/dump2.bin bs=100M count=1K status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 811.527 s, 132 MB/s

ext4

sudo dd if=/dev/zero of=/media/davex/Pat240G/dump.bin bs=100M count=1K status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 240.032 s, 447 MB/s

tr '\0' '\377' < /dev/zero | sudo dd of=/media/davex/Pat240G/dump2.bin bs=100M count=1K status=progress iflag=fullblock
107374182400 bytes (107 GB, 100 GiB) copied, 261.163 s, 411 MB/s

sudo dd if=/dev/random of=/media/davex/Pat240G/dump2.bin bs=100M count=1K status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 429.978 s, 250 MB/s

exFAT

dd if=/dev/zero of=/media/davex/PAT240GXFAT/dump2.bin bs=100M count=1K status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 250.026 s, 429 MB/s

dd if=/media/davex/Pat480G/Lux2e/Lux2e.vdi of=/media/davex/PAT240GXFAT/Lux2e/Lux2e.vdi bs=100M status=progress
124962996224 bytes (125 GB, 116 GiB) copied, 422.505 s, 296 MB/s

UGREEN + Patriot 240GB + Raspberry Pi 5

exFAT

dd if=/dev/zero of=/media/davex/PAT240GXFAT/dump2.bin bs=100M count=1K status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 415.082 s, 259 MB/s

dd of=/dev/null of=/media/davex/PAT240GXFAT/Lux2e/Lux2e.vdi bs=100M count=1K status=progress
124962996224 bytes (125 GB, 116 GiB) copied, 327.183 s, 382 MB/s

Patriot 240GB + Raspberry Pi 5 (nvme)

exFAT

dd if=/dev/zero of=/media/davex/PAT240GXFAT/dump2.bin bs=100M count=1K status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 297.226 s,  361 MB/s

dd of=/dev/null of=/media/davex/PAT240GXFAT/Lux2e/Lux2e.vdi bs=100M count=1K status=progress
124962996224 bytes (125 GB, 116 GiB) copied, 278.538 s, 449 MB/s


UGREEN + Patriot 240GB + Jetson Nano

exFAT

dd if=/media/davez/PAT240GXFAT/Lux2e/Lux2e.vdi of=/dev/null bs=100M status=progress
124970336256 bytes (125 GB, 116 GiB) copied, 561.616 s, 223 MB/s

dd of=/media/davez/PAT240GXFAT/dump.bin if=/dev/zero bs=100M count=1K status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 1405.02 s, 76.4 MB/s


UGREEN + WD 500GB + Macbook Pro 

ext4

gnome-disks benchmark, 100MB 100 Samples
Average Read 456.6 MB/s
Average Write 329.8 MB/s   (start off at 420 MB/s , drop to 260 MB/s after half way)
Average Access time 0.21 msec

sudo dd if=/dev/zero of=/media/davex/SYSTEM/dump.bin bs=100M count=1K status=progress
107374182400 bytes (107 GB, 100 GiB) copied, 401.139 s, 268 MB/s


WD 500GB + Raspberry Pi 5 (nvme)

ext4

sudo dd if=/dev/zero of=/media/davez/SYSTEM/dump.bin bs=100M count=1000 status=progress
104857600000 bytes (105 GB, 98 GiB) copied, 321.092 s, 327 MB/s

sudo dd of=/dev/null if=/media/davez/SYSTEM/dump.bin bs=100M status=progress
104857600000 bytes (105 GB, 98 GiB) copied, 116.73 s, 898 MB/s


The file format block size has a significant effect on the speed; it is a tradeoff between the speed and disk space utilization.