By turns: tinker, engineer, husband, author, amateur raconteur, recumbent cyclist, father, ham radio geek. So many projects, so little time!
Thinking of a 60 kHz crystal filter front end for the WWVB receiver brought a little bag of 32.768 kHz crystals to the surface; I figured I could use them as crash test dummies while a bag of 60 kHz crystals travels around the planet. Come to find out they don’t behave quite like crystals and a bit of investigation shows the little cans contain tuning fork resonators, not crystal slabs.
I had to see that, so I grabbed the base of one in a pin vise:
I don’t know the part number for those resonators, but it’s something like AT26, where the “26” means a cylindrical can 2 mm OD and 6 mm long, more or less.
Notching the can at the chuck with a triangular file, then wiggling the can with needle-nose pliers, eventually broke it off:
The other side:
A look through the microscope show they’re transparent, with laser trim scars on the ends:
The “holes” are unplated quartz areas, clear as the finest glass.
Not what I was expecting to see, at all!
At first, the yard camera worked fine, but a few days later the stream of JPEG images would unpredictably stall. I connect to it through a public-key SSH session and, sometimes, the login would stall for tens of seconds and, with a session set up, various exciting operation like, say,
htop would unpredictably stall; if I waited long enough, they’d complete normally.
It’s a known-good card from a reputable supplier, not that that means much these days. The camera flash highlights the gritty silkscreen (?) texture of the orange overlay, but the production value seems high enough to pass muster.
Popping the card in my desktop PC showed:
- It remains functional, at least to the extent of being mount-able and write-able
3probe --time-ops /dev/sdbshowed it still held 16 GB
fsck -fv /dev/sdbshows no problems
- Both partitions looked good
So I shrank the main partition to 7.5 GB, copied the image to the desktop PC’s SSD, fired up the Token Windows Laptop, ran the Official SD Card Formatter, and discovered that it thought the card had only 63 MB (yes, MB) available. That’s the size of the FAT
boot partition, so I returned the card to the desktop PC, unleashed
gparted on it, blew away the partitions, reformatted the whole thing to one 16 GB FAT32 partition, and stuck it back in the laptop, whereupon the Official Formatter agreed it had every byte it should.
A format-with-overwrite then proceeded apace; the card doesn’t support format-with-erase.
Back in the desktop, I copied the saved image back onto the card which, en passant, blew away the just-created FAT format and restored the Raspbian partition structure. The 8 GB of that copy proceeded at an average 12.1 MB/s. I did not watch the transfer closely enough to notice any protracted delays.
Back in the Pi, the card booted and ran perfectly, sending an image every second to the laptop (now running its usual Mint Linux) on the guest network:
SSH sessions now work perfectly, too, and commands no longer jam.
So it seems a good-quality MicroSD card can experience protracted delays while writing data, to the extent of tens of seconds, stalling the Pi in mid-operation without producing data errors or any other symptoms.
It’s not clear the Official Formatter does anything that simply copying the image back to the card wouldn’t also accomplish, although overwriting the entire 16 GB extent of the card exercises all the cells and forces the card controller to re/de/un/allocate bad blocks. If, indeed, the blocks are bad, rather than just achingly slow.
Moral of the story: Don’t use MicroSD cards as mass storage devices, at least not for industrial applications that require consistent performance.
You’ll recall the LED atop the 21HB5A tube failed, shortly after replacing the bottom LED and rewiring the ersatz plate lead, which led me to rebuild the whole thing with SK6812 RGBW LEDs. So I printed all the plastic parts again, because the duodecar tube socket’s pin circle can fit into a hard drive platter’s unmodified 25 mm hole, then drilled another platter to suit:
The hole under the drill fits the 3.5 mm stereo socket for the ersatz plate lead, so it’s bigger than before.
I’ve switched from Arduino Pro Minis with a separate USB converter to Arduino Nanos with an on-board CH340 USB chip, because the fake FTDI chips on the converters are a continuing aggravation:
Adding those wire slots to the sockets definitely helps tidy things up; the wires no longer need a crude cable tie anchoring them to the socket mounting screws.
I wanted to drive the LEDs from the A7 pin, rather than the A3 pin I’d been using on the Pro Minis, to keep the wires closer together, but it turns out that A6 and A7 can’t become digital output pins. So I used A5, although I may come to regret the backward incompatibility.
In any event, the 21HB5A tube looks spiffy with its new LEDs in full effect:
I dialed the white LED PWM down to 32, making the colors somewhat pastel, rather than washed-out.
The Arduino source code as a GitHub Gist:
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!
The yard camera I mentioned a few days ago consists of a Raspberry Pi 3 with an Official V2 Pi Camera peering through two layers of 1955-era window glass into our back yard:
Yes, that’s black duct tape holding it to the window pane. The extension cord draped across the floor gotta go, too.
This being a made-in-haste lashup, I used the streamEye MJPEG HTTP streamer, started from
/etc/rc.local in the usual way:
logger -s Starting camera streamer sudo -u pi sh -c '/home/pi/yardcam.sh' & logger -s Camera running
yardcam.sh script feeds one moderate-quality frame to the streamer every second:
/home/pi/streameye/extras/raspimjpeg.py -w 1280 -h 720 -r 1 -q 80 | streameye
MJPEG has a lot to dislike as a streaming video format. In particular, without any hint of inter-frame compression, the network usage gets way too high for any reasonable frame rate.
But it got the camera up & running in time for the March snowfall:
In a nod to IoT security, the Raspberry Pi’s wireless interface sits behind the router’s firewall on our guest network, with no access to the devices on our main network. The router passes a one-port peephole from the Internet to the Pi, which protects all the other services from unwarranted attention.
The router maintains a dynamic DNS record with a (not particularly) mnemonic URL, which seems better than an ever-changing dotted-quad IP address.
Because the router doesn’t support hairpin connections from the main network to the guest network, I can’t monitor the video from my desktop through the outwardly visible URL. Instead, I must fire up a laptop, connect to the guest network, then connect directly to the camera at
You do not have a Need To Know for the URL; I’m sure it’ll appear on Shodan. I plan to take it down when the snow melts.
I had to replace the faucet on a kitchen sink (not our own, for reasons not relevant here) after the steel nuts & washers holding the base to the sink deck rotted completely away. Why faucet manufacturers used plain steel in that location remains a mystery; I’m sure it has something to do with cost reduction and damn the consequences after a few years.
Of course, the new faucet didn’t sit quite flat on the sink deck, due to the raised rim around the perimeter. Installing it like that would prevent the (hard plastic) gasket from sealing against the deck, with the inevitable water leak below the sink; we started this project by scrapping a water-soaked shelf under the sink due to the previous faucet’s wrecked seal. Sliding the oval base forward enough to clear the rim would expose the two holes on each side, with similar results.
You can see the problem if you squint hard enough:
I decided raising the back of the base by maybe two millimeters wouldn’t be particularly visible, particularly if I filled the space with silicone snot (almost) matching the gasket to provide a solid foundation.
The blue tape masks the sink surface around the gasket to prevent silicone mishaps and simplify cleanup. I held the gasket in place, traced around it with new Xacto knife blade, and peeled the inside out just like I knew what I was doing.
Generous beads of snot around all the holes and across the back will provide a firm base and a good seal:
With that in place, I aligned the faucet over the gasket, gently tightened the nuts holding the base to the deck, and waited a day for the silicone to start curing before completing the plumbing. It’ll take a while to finish, due to the limited area exposed around the edges.
The water lines now have shutoff ball valves, which the next person to work on it will surely appreciate.
A recent OpenSCAD mailing list discussion started with an observation that the dimensions of printed parts were wildly different from the numeric values used in the OpenSCAD program that created the STL. Various folks suggested possible errors, examined the source and STL files to no avail, and were generally baffled.
Finally, a photo conclusively demonstrating the problem arrived:
Note the difference between the digital readout and the analog scale printed on the body.
Turns out it’s his first digital caliper: he simply didn’t realize you must close the jaws and press the ZERO button before making any measurements.
We’ve all been that guy. Right?
FWIW, our Larval Engineer can probably still hear me intoning “Check your zero” every time she picks up a caliper or turns on a multimeter. Perhaps she’ll think fondly of me, some day. [grin]