Ed

By turns: tinker, engineer, husband, author, amateur raconteur, recumbent cyclist, father, ham radio geek. So many projects, so little time!

Homepage: http://softsolder.com

Quartz Tuning Fork Resonator Teardown

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

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

Quartz resonator – A side

The other side:

Quartz resonator - B side

Quartz resonator – B side

A look through the microscope show they’re transparent, with laser trim scars on the ends:

Quartz resonator - detail

Quartz resonator – detail

The “holes” are unplated quartz areas, clear as the finest glass.

Not what I was expecting to see, at all!

Advertisements

4 Comments

Raspberry Pi Slowdown

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.

This seemed familiar:

Samsung 16 GB Evo MicroSD card

Samsung 16 GB Evo MicroSD card

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

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.

,

6 Comments

Vacuum Tube Lights: Duodecar Rebuild

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:

Duodecar disk drilling

Duodecar disk drilling

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:

21HB5A base - interior

21HB5A base – interior

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:

21HB5A with RBGBW LEDs - cyan violet phase

21HB5A with RBGBW LEDs – cyan violet phase

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:

, , ,

Leave a comment

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!

 

8 Comments

Raspberry Pi Yard Camera

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

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:

/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:

Fun in Snow - 2017-03-15

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.

3 Comments

Kitchen Sink Faucet Deck Sealing

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:

Kitchen Sink Faucet - gasket mask

Kitchen Sink Faucet – gasket mask

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:

Kitchen Sink Faucet - gasket in place

Kitchen Sink Faucet – gasket in place

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.

2 Comments

Check Your Zero

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:

Caliper - digital vs. analog scale

Caliper – digital vs. analog scale

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]

, ,

21 Comments