Archive for category Science

Monthly Image: Turkey Mating

Early spring brings out large turkey flocks and provides a window into their otherwise rather private lives.

Despite all the strutting and posturing by the males, the ladies call the shots. When we see a hen go hull-down like this, we know what’s about to happen:

 Turkey mating - invitation

Turkey mating – invitation

Getting into the right position seems remarkably awkward and requires some cooperation:

Turkey mating - mounting

Turkey mating – mounting

When her head and tail pop up, you know the thing is going right:

Turkey mating - the moment

Turkey mating – the moment

And a back massage always feels so fine:

Turkey mating - massage

Turkey mating – massage

Then he’s back to strutting & posturing:

Turkey mating - aftermath

Turkey mating – aftermath

We hope they’ll show us their chicks

Taken with the DSC-H5, hand-held through two panes of 1955-era window glass: ya get what ya get.



Cheap WS2812 LEDs: Test Fixture Failure 2

A second WS2812 RGB LED in the test fixture failed:

WS2812 LED - test fixture failure 2

WS2812 LED – test fixture failure 2

The red pixel in the second row from the top sends pinball panic to the six downstream LEDs (left and upward). Of course, it’s not consistently bad and sometimes behaves perfectly. The dark row below it contains perfectly good LEDs: they’re in a dark-blue part of the cycle.

The first WS2812 failed after about a week. This one lasted 7 weeks = 50-ish days.

The encapsulation seal went bad on this one and, for whatever it’s worth, the remainder still pass the Sharpie test. Perhaps the LEDs fail only after heat (or time-at-temperature) breaks the seal. Assuming, equally of course, the seal left the factory in good order, which seems a completely unwarranted assumption.


Monthly Science: Sonicare Recharge Intervals

After replacing the NiMH cells in my Sonicare toothbrush in July 2012, they delivered about 21 days = 21 brushings between charges. After a year, I laid a sheet of Geek Scratch Paper on the windowsill (*) and noted pretty nearly every recharge:

Sonicare recharge - 2013-10 - 2017-01

Sonicare recharge – 2013-10 – 2017-01

Anyhow, the original cells crapped out after 2-½ years, when these still delivered 13 days. After 4-½ years, they’re lasting 12 days between charges.

Color me surprised, because they’re 600 mA·h NiMH cells. The originals were 2000 mA·h cells, which you’d expect would last longer, but noooo.

No reason to change them yet, which is good news.

FWIW, I recently bought some cheap brush heads from the usual low-end eBay seller. The OEM brushes have colored bristles which fade to tell you when to change brushes, although I run ’em quite a bit longer than that. The cheap replacements have never-fading colored bristles and, I suspect, all the bristles are much too stiff. The dental hygienist says I’m doing great, so it’s all good.

Sonicare brush heads - cheap vs OEM

Sonicare brush heads – cheap vs OEM

High truth: at best, you get what you pay for.

(*) Being that type of guy has some advantages, if you’re that guy. Otherwise, it’s a nasty character flaw.




Quartz Resonator Test Fixture: 32 kHz Quartz Tuning Fork

Soldering a 32.768 kHz quartz tuning fork resonator into the test fixture:

Quartz crystal resonance test fixture

Quartz crystal resonance test fixture

The HP 8591 tracking generator doesn’t go below 100 kHz, so I used the FG085 DDS function generator as a source. I trust the 8591’s calibration more than the FG805’s, but right now I’m more interested in the differences between successive frequencies and the DDS can step in 1 Hz increments.

The output appears on the 8591, with a big hump comes from the analyzer’s 30 Hz IF filter response sweeping across what’s essentially a single-frequency input. The hump is not the crystal’s response spectrum!

With the jumper installed to short the 33 pF cap, the output peaks at 32.764:

Removing the jumper to put the cap in the circuit, the response peaks at 32.765 kHz:

The marker delta shows the difference between the two peaks, ignoring their 1 Hz difference:

Quartz Resonator 32.764-5 no-34.6 pF delta

Quartz Resonator 32.764-5 no-34.6 pF delta

So I’d say the cap really does change the resonator series resonance by just about exactly 1 Hz.

With the jumper installed to remove the cap from the circuit, setting the reference marker at the 32.764 kHz peak, and measuring the relative response at 32.765 kHz :

Quartz Resonator 32.764-5 no cap delta

Quartz Resonator 32.764-5 no cap delta

So the response peak is much much narrower than 1 Hz: being off-peak by 1 Hz knocks 13-ish dB from the response.

What’s painfully obvious: my instrumentation is totally inadequate for crystal measurements at these frequencies!


Quartz Resonator Test Fixture: 3.58 MHz Crystal Test

Just to see if the resonator test fixture produced meaningful results, I plugged a 3.57954 MHz color burst crystal into the socket:

Quartz test fixture - 3.57954 MHz crystal

Quartz test fixture – 3.57954 MHz crystal

This is a staged recreation based on actual events; pay no attention to the Colpitts oscillators growing in the background.

Attaching goesinta and goesouta cables to the HP 8591 spectrum analyzer & tracking generator showed it worked just fine:

Quartz 3.57954 MHz - no cap

Quartz 3.57954 MHz – no cap

The reference level is -40 dBm, not the usual 0 dBm, due to the loss in those resistive pads. Unsurprisingly, the parallel resonance valley looks pretty ragged at -120 dBm = 1 nW = 7 µV.

Remove the jumper to put the capacitor in series:

Quartz 3.57954 MHz - 36.4pF

Quartz 3.57954 MHz – 36.4pF

The marker delta resolution surely isn’t 1 Hz, but 750 Hz should get us in the right ballpark.

Substituting a 72 Ω resistor, found by binary search rather than twiddling a pot:

Quartz 3.57954 MHz - 72ohm

Quartz 3.57954 MHz – 72ohm

Which gives us all the measurements:

  • Fs = 3.57824 MHz
  • Fc = Fs + 750 Hz = 3.57899 MHz
  • Rm = 72 Ω
  • C0 = 3.83 pF
  • Cpar = 3.70 pF

Turn the crank and the crystal motional parameters pop out:

  • Lm = 117 mH
  • Cm = 17 fF
  • Rm = 72 Ω
  • Q = 36 k

Looks like a pretty good crystal to me!


Cheap WS2812 LEDs: Failure Waveforms

The failed WS2812 pixel remains defunct:

WS2812 array - failure 1

WS2812 array – failure 1

Attach scope probes to its data input and output pins (with the fixture face-down on the bench):

WS2812 LED - fixture probing

WS2812 LED – fixture probing

The output no longer comes from the Land of Digital Signals:

WS2812 Array Fail 1 - in vs out

WS2812 Array Fail 1 – in vs out

I immediately thought the broken bits occupied the first 24 bit times, when the WS2812 controller should be absorbing those bits from the incoming stream. The vertical cursors show the failed bits occupy 54 µs = 40-ish bit times at 800 kHz (or you can count them), so it’s worse than a simple logic failure.

A closer look:

WS2812 Array Fail 1 - in vs out - detail

WS2812 Array Fail 1 – in vs out – detail

At least for those bits, neither output transistor works well at all. On the other paw, the output shouldn’t even be enabled for the first 24 bits, so there’s that to consider.

Lo and behold, it also fails the Josh Sharpie Test:

WS2812 LED - test array failure 1 - ink test

WS2812 LED – test array failure 1 – ink test

You may recall it passed the leak test shortly before I assembled the test array a month ago. Evidently, just few days of operation suffices to wreck the seal, let air / moisture into the package, and kill the controller. Not a problem you’d find during a production-line test (assuming there is such a thing), but it should certain appear during the initial design & production qualification test phase (another assumption).

Weirdly, a day after taking that photo, the controller began working perfectly again and the LEDs look just like they should: there is no explaining that!



Cheap WS2812 LEDs: Test Fixture Failure 1

Well, that didn’t take long:

WS2812 array - failure 1

WS2812 array – failure 1

The red spot in the next-to-bottom row of the test fixture (*) marks a failed WS2812 LED. All of the LEDs above it, plus the LED just to its left, are in pinball panic mode: random colors flicker across the panel as the LED’s controller transmits garbled data and the downstream LEDs pass it on.

This failure provides several bits of information:

  • The LED sees the same power supply as all the rest, so it’s not a power thing
  • The LED gets data from the adjacent WS2812, so it’s not an Arduino output thing
  • It failed after about four days = 100 hours of continuous operation

I connected the previous LED’s output (#6) to the next one’s input (#8), so the failed LED (#7, now with output disconnected) continues to flicker, but doesn’t influence any of the downstream LEDs.

(*) The LEDs are daisy-chained from lower right to upper left, row by row, so that’s LED #7 of 28.