The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Month: March 2017

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

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.

Not what I was expecting to see, at all!

2017-03-24
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

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.
2017-03-23

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:

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:

	// Neopixel mood lighting for vacuum tubes
	// Ed Nisley – KE4ANU – June 2016
	// September 2016 – Add Morse library and blinkiness
	// October 2016 – Set random colors at cycle end
	// March 2017 – RGBW SK6812 LEDs

	#include <Adafruit_NeoPixel.h>
	#include <morse.h>
	#include <Entropy.h>

	//———-
	// Pin assignments

	const byte PIN_NEO = A5; // DO – data out to first Neopixel

	const byte PIN_HEARTBEAT = 13; // DO – Arduino LED

	#define PIN_MORSE 12

	//———-
	// Constants

	// number of pixels
	#define PIXELS 2

	// index of the Morse output pixel and how fast it sends
	boolean Send_Morse = false;
	#define PIXEL_MORSE (PIXELS – 1)
	#define MORSE_WPM 10

	// lag between adjacent pixel, degrees of slowest period
	#define PIXELPHASE 45

	// update LEDs only this many ms apart (minus loop() overhead)
	#define UPDATEINTERVAL 50ul
	#define UPDATEMS (UPDATEINTERVAL – 1ul)

	// number of steps per cycle, before applying prime factors
	#define RESOLUTION 500

	//———-
	// Globals

	// instantiate the Neopixel buffer array

	Adafruit_NeoPixel strip = Adafruit_NeoPixel(PIXELS, PIN_NEO, NEO_GRBW + NEO_KHZ800);

	uint32_t FullWhite = strip.Color(255,255,255,255);
	uint32_t FullOff = strip.Color(0,0,0,0);
	uint32_t MorseColor;

	struct pixcolor_t {
	unsigned int Prime;
	unsigned int NumSteps;
	unsigned int Step;
	float StepSize;
	float Phase;
	byte MaxPWM;
	};

	unsigned int PlatterSteps;

	byte PrimeList[] = {3,5,7,13,19,29};

	// colors in each LED
	enum pixcolors {RED, GREEN, BLUE, WHITE, PIXELSIZE};

	struct pixcolor_t Pixels[PIXELSIZE]; // all the data for each pixel color intensity

	uint32_t UniColor;

	unsigned long MillisNow;
	unsigned long MillisThen;

	// Morse code

	char * MorseText = " cq cq cq de ke4znu";

	LEDMorseSender Morse(PIN_MORSE, (float)MORSE_WPM);

	uint8_t PrevMorse, ThisMorse;

	//– Figure PWM based on current state

	byte StepColor(byte Color, float Phi) {

	byte Value;

	Value = (Pixels[Color].MaxPWM / 2.0) * (1.0 + sin(Pixels[Color].Step * Pixels[Color].StepSize + Phi));

	// Value = (Value) ? Value : Pixels[Color].MaxPWM; // flash at dimmest points for debug

	return Value;
	}

	//– Select three unique primes for the color generator function
	// Then compute all the step parameters based on those values

	void SetColorGenerators(void) {

	Pixels[RED].Prime = PrimeList[random(sizeof(PrimeList))];

	do {
	Pixels[GREEN].Prime = PrimeList[random(sizeof(PrimeList))];
	} while (Pixels[RED].Prime == Pixels[GREEN].Prime);

	do {
	Pixels[BLUE].Prime = PrimeList[random(sizeof(PrimeList))];
	} while (Pixels[BLUE].Prime == Pixels[RED].Prime \|\|
	Pixels[BLUE].Prime == Pixels[GREEN].Prime);
	do {
	Pixels[WHITE].Prime = PrimeList[random(sizeof(PrimeList))];
	} while (Pixels[WHITE].Prime == Pixels[RED].Prime \|\|
	Pixels[WHITE].Prime == Pixels[GREEN].Prime \|\|
	Pixels[WHITE].Prime == Pixels[BLUE].Prime);


	printf("Primes: %d %d %d %d\r\n",Pixels[RED].Prime,Pixels[GREEN].Prime,Pixels[BLUE].Prime,Pixels[WHITE].Prime);

	Pixels[RED].MaxPWM = 255;
	Pixels[GREEN].MaxPWM = 255;
	Pixels[BLUE].MaxPWM = 255;
	Pixels[WHITE].MaxPWM = 32;

	unsigned int PhaseSteps = (unsigned int) ((PIXELPHASE / 360.0) *
	RESOLUTION * (unsigned int) max(max(max(Pixels[RED].Prime,Pixels[GREEN].Prime),Pixels[BLUE].Prime),Pixels[WHITE].Prime));
	printf("Pixel phase offset: %d deg = %d steps\r\n",(int)PIXELPHASE,PhaseSteps);


	for (byte c=0; c < PIXELSIZE; c++) {
	Pixels[c].NumSteps = RESOLUTION * Pixels[c].Prime; // steps per cycle
	Pixels[c].StepSize = TWO_PI / Pixels[c].NumSteps; // radians per step
	Pixels[c].Step = random(Pixels[c].NumSteps); // current step
	Pixels[c].Phase = PhaseSteps * Pixels[c].StepSize;; // phase in radians for this color

	printf(" c: %d Steps: %d Init: %d Phase: %d deg",c,Pixels[c].NumSteps,Pixels[c].Step,(int)(Pixels[c].Phase * 360.0 / TWO_PI));
	printf(" PWM: %d\r\n",Pixels[c].MaxPWM);
	}
	}

	//– Helper routine for printf()

	int s_putc(char c, FILE *t) {
	Serial.write(c);
	}

	//——————
	// Set the mood

	void setup() {

	pinMode(PIN_HEARTBEAT,OUTPUT);
	digitalWrite(PIN_HEARTBEAT,LOW); // show we arrived

	Serial.begin(57600);
	fdevopen(&s_putc,0); // set up serial output for printf()

	printf("Vacuum Tube Mood Light – RGBW\r\nEd Nisley – KE4ZNU – March 2017\r\n");

	Entropy.initialize(); // start up entropy collector

	// set up pixels

	strip.begin();
	strip.show();

	// lamp test: a brilliant white flash

	printf("Lamp test: flash white\r\n");

	for (byte i=0; i<5 ; i++) {
	for (int j=0; j < strip.numPixels(); j++) { // fill LEDs with white
	strip.setPixelColor(j,FullWhite);
	}
	strip.show();
	delay(500);

	for (int j=0; j < strip.numPixels(); j++) { // fill LEDs with black
	strip.setPixelColor(j,FullOff);
	}
	strip.show();
	delay(500);
	}

	// get an actual random number

	uint32_t rn = Entropy.random();

	printf("Random seed: %08lx\r\n",rn);
	randomSeed(rn);

	// set up the color generators

	SetColorGenerators();

	// set up Morse generator

	Morse.setup();
	Morse.setMessage(String(MorseText));
	MorseColor = strip.Color(255,random(32,64),random(16),0);

	PrevMorse = ThisMorse = digitalRead(PIN_MORSE);

	printf("Morse enabled: %d at %d wpm color: %08lx\n [%s]\r\n",Send_Morse,MORSE_WPM,MorseColor,MorseText);

	MillisNow = MillisThen = millis();

	}

	//——————
	// Run the mood

	void loop() {

	if (!Morse.continueSending()) {
	printf("Restarting Morse message\r\n");
	Morse.startSending();
	}
	ThisMorse = digitalRead(PIN_MORSE);

	MillisNow = millis();
	if (((MillisNow – MillisThen) >= UPDATEMS) \|\| // time for color change?
	(PrevMorse != ThisMorse)) { // Morse output bit changed?

	digitalWrite(PIN_HEARTBEAT,HIGH);

	if (Send_Morse && ThisMorse) { // if Morse output high, overlay flash
	strip.setPixelColor(PIXEL_MORSE,MorseColor);
	}
	PrevMorse = ThisMorse;
	strip.show(); // send out precomputed colors

	boolean CycleRun = false; // check to see if all cycles have ended
	for (byte c=0; c < PIXELSIZE; c++) { // compute next increment for each color
	if (++Pixels[c].Step >= Pixels[c].NumSteps) {
	Pixels[c].Step = 0;
	printf("Cycle %d steps %d at %8ld delta %ld ms\r\n",c,Pixels[c].NumSteps,MillisNow,(MillisNow – MillisThen));
	}
	else {
	CycleRun = true; // this color is still cycling
	}
	}

	// If all cycles have completed, reset the color generators

	if (!CycleRun) {
	printf("All cycles ended: setting new color generator values\r\n");
	SetColorGenerators();
	}

	for (int i=0; i < strip.numPixels(); i++) { // for each pixel
	byte Value[PIXELSIZE];
	for (byte c=0; c < PIXELSIZE; c++) { // … for each color
	Value[c] = (Pixels[c].MaxPWM / 2.0) * (1.0 + sin(Pixels[c].Step * Pixels[c].StepSize – i*Pixels[c].Phase));
	}
	UniColor = strip.Color(Value[RED],Value[GREEN],Value[BLUE],Value[WHITE]);
	strip.setPixelColor(i,UniColor);
	}

	MillisThen = MillisNow;
	digitalWrite(PIN_HEARTBEAT,LOW);
	}

	}

view raw TubeMorse.ino hosted with ❤ by GitHub

2017-03-22

Cheap WS2812 LEDs: Failure Waveforms

The failed WS2812 pixel remains defunct:

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

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

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

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

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!

2017-03-21
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

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

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.
2017-03-20
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

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

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.

2017-03-19
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

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]

2017-03-18