Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
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:
Quartz resonator – 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:
Quartz resonator – A side
The other side:
Quartz resonator – B side
A look through the microscope show they’re transparent, with laser trim scars on the ends:
Quartz resonator – detail
The “holes” are unplated quartz areas, clear as the finest glass.
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/sdb showed it still held 16 GB
fsck -fv /dev/sdb[12] shows 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:
Turkey flock in driveway – 2017-03-21
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.
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:
Back Yard Camera setup – 2017-03-13
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
The yardcam.sh script feeds one moderate-quality frame to the streamer every second:
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:
Fun in Snow – 2017-03-15
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 camera.local.
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.
A turkey flock forages through the bottomlands along the Wappinger Creek and, at night, roosts in the trees at the far end of our driveway:
Roosting Turkeys – visible
I’m a sucker for that moon:
Roosting Turkeys – visible
It’s rising into the eastward-bound cloud cover bringing a light snowfall, so we missed the penumbral eclipse.
If you’re counting turkeys, it’s easier with a contrasty IR image:
Roosting Turkeys – infra-red mode
Mary recently counted forty turkeys on the ground, so that’s just part of their flock. I think their air boss assigns one turkey per branch for safety; they weigh upwards of 10 pounds each!
Taken with the DSC-H5 and DSC-F717, both the the 1.7× teleadapter, hand-held in cold weather.