Archive for category Science
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:
Getting into the right position seems remarkably awkward and requires some cooperation:
When her head and tail pop up, you know the thing is going right:
And a back massage always feels so fine:
Then he’s back to strutting & posturing:
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.
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.
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:
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.
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.
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:
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 :
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!
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:
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:
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:
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!
The failed WS2812 pixel remains defunct:
Attach scope probes to its data input and output pins (with the fixture face-down on the bench):
The output no longer comes from the Land of Digital Signals:
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:
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:
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!
Well, that didn’t take long:
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.