Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Category: Software
General-purpose computers doing something specific
This appeared on The Mighty Thor’s phone during a Squidwrench meeting:
BofA Phishing
“To maintain a secure banking environment” seems diagnostic of a scam.
Discouragingly, some of our banks still send emails with clicky links using third-party mail servers, so checkonlineinfo.com doesn’t seem any more suspicious than, say, Schwab’s customercenter.net.
My Raspberry Pi-based streaming radio player generally worked fine, except sometimes the keypad / volume control knob would stop responding after switching streams. This being an erratic thing, the error had to be a timing problem in otherwise correct code and, after spending Quality Time with the Python subprocess and select doc, I decided I was abusing mplayer’s stdin and stdout pipes.
This iteration registers mplayer’s stdout pipe as Yet Another select.poll() Polling Object, so that the main loop can respond whenever a complete line arrives. Starting mplayer in quiet mode reduces the tonnage of stdout text, at the cost of losing the streaming status that I really couldn’t do anything with, and eliminates the occasional stalls when mplayer (apparently) dies in the middle of a line.
The code kills and restarts mplayer whenever it detects an EOF or stream cutoff. That works most of the time, but a persistent server or network failure can still send the code into a sulk. Manually selecting a different stream (after we eventually notice the silence) generally sets things right, mainly by whacking mplayer upside the head; it’s good enough.
It seems I inadvertently invented streaming ad suppression by muting (most of) the tracks that produced weird audio effects. Given that the “radio stations” still get paid for sending ads to me, I’m not actually cheating anybody out of their revenue: I’ve just automated our trips to the volume control knob. The audio goes silent for a few seconds (or, sheesh, a few minutes) , blatting a second or two of ad noise around the gap to remind us of what we’re missing; given the prevalence of National Forest Service PSAs, the audio ad market must be a horrific wasteland.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The original SuperFormula equation produces points in polar coordinates, which the Chiplotle library converts to the rectilinear format more useful with Cartesian plotters. I’ve been feeding the equation with 10001 angular values (10 passes around the paper, with 1000 points per pass, plus one more point to close the pattern), which means the angle changes by 3600°/10000 = 0.36° per point. Depending on the formula’s randomly chosen parameters, each successive point can move the plotter pen by almost nothing to several inches.
On the “almost nothing” end of the scale, the plotter slows to a crawl while the serial interface struggles to feed the commands. Given that you can’t see the result, why send the commands?
Computing point-to-point distances goes more easily in rectilinear coordinates, so I un-tweaked my polar-modified superformula function to return the points in rectangular coordinates. I’d originally thought a progressive scaling factor would be interesting, but it never happened.
The coordinate pruning occurs in the supershape function, which now contains a loop to scan through the incoming list of points from the superformula function and add a point to the output path only when it differs by enough from the most recently output point:
The first and last points always go into the output list; the latter might be duplicated, but that doesn’t matter.
Note that you can’t prune the list by comparing successive points, because then you’d jump directly from the start of a series of small motions to their end. The idea is to step through the small motions in larger units that, with a bit of luck, won’t be too ugly.
The width and height values scale the XY coordinates to fill either A or B paper sheets, with units of “Plotter Units” = 40.2 PU/mm = 1021 PU/inch. You can scale those in various ways to fit various output sizes within the sheets, but I use the defaults that fill the entire sheets with a reasonable margin. As a result, the magic number 60 specifies 60 Plotter Units; obviously, it should have a suitable name.
Pruning to 40 PU = 1.0 mm (clicky for more dots, festooned with over-compressed JPEG artifacts):
Plot pruned to 40 PU
Pruning to 60 PU = 1.5 mm:
Plot pruned to 60 PU
Pruning to 80 PU = 2.0 mm:
Plot pruned to 80 PU
Pruning to 120 PU = 3.0 mm:
Plot pruned to 120 PU
All four of those plots have the same pens in the same order, although I refilled a few of them in flight.
By and large, up through 80 PU there’s not much visual difference, although you can definitely see the 3 mm increments at 120 PU. However, the plotting time drops from just under an hour for each un-pruned plot to maybe 15 minutes with 120 PU pruning, with 60 PU producing very good results at half an hour.
Comparing the length of the input point lists to the pruned output path lists, including some pruning values not shown above:
Eyeballometrically, 60 PU pruning halves the number of plotted points, so the average data rate jumps from 9600 b/s to 19.2 kb/s. Zowie!
Most of the pruning occurs near the middle of the patterns, where the pen slows to a crawl. Out near the spiky rim, where the points are few & far between, there’s no pruning at all. Obviously, quantizing a generic plot to 1.5 mm would produce terrible results; in this situation, the SuperFormula produces smooth curves (apart from those spikes) that look just fine.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I made the pencil guides to help Mary design ruler quilting patterns, but sometimes she must line up the ruler with a feature on an existing pattern. To that end, we now have a reticle guide:
Ruler Adapters – pencil guide and reticle
The general idea is that it’s easier to see the pattern on paper through the crosshair than through a small hole. You put the button over a feature, align the reticle, put the ruler against the button, replace it with pencil guide, and away you go.
The solid model looks much more lively than you’d expect:
Ruler Adapter – reticle – Slic3r preview
Printing up a pair of each button produces the same surface finish as before; life is good!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Mary has been doing Ruler Quilting and wanted a pencil guide (similar to the machine’s ruler foot) to let her sketch layouts before committing stitches to fabric. The general idea is to offset the pencil by 1/4 inch from the edge of the ruler:
Ruler Adapter – solid model
That was easy.
Print three to provide a bit of cooling time and let her pass ’em around at her next quilting bee:
Ruler Adapter – Slic3r preview
Her favorite doodling pencil shoves a 0.9 mm lead through a 2 mm ferrule, so ream the center hole with a #44 drill (86 mil = 2.1 mm) to suit:
Ruler quilting pencil guides
The outer perimeters have 64 facets, an unusually high number for my models, so they’re nice & smooth on the ruler. Even though I didn’t build them sequentially, they had zero perimeter zits and the OD came out 0.500 inch on the dot.
The chamfers guide the pencil point into the hole and provide a bit of relief for the pencil’s snout.
If I had a laser cutter, I could make special rulers for her, too …
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The plate cap LED blinks the message in orange, while both LEDs continue to slowly change color as before.
You define a Morse sender object (C++, yo!) by specifying its output pin and code speed in words per minute, dump a string into it, then call a continuation function fast enough to let it twiddle the output bit for each pulse. Obviously, the rate at which the callback happens determines the timing granularity.
However, setting a knockoff Neopixel to a given color requires more than just a binary signal on an output pin. The continuation function returns false when it’s done with the message, after which you can initialize and send another message. There’s no obvious (to me, anyhow) way to get timing information out of the code.
The easiest solution: called the Morse continuation function at the top of the main loop, read its output pin to determine when a dit or dah is active, then set the plate cap color accordingly:
LEDMorseSender Morse(PIN_MORSE, (float)MORSE_WPM);
...
Morse.setup();
Morse.setMessage(String(" cq cq cq de ke4znu "));
PrevMorse = ThisMorse = digitalRead(PIN_MORSE);
...
if (!Morse.continueSending()) {
Morse.startSending();
}
ThisMorse = digitalRead(PIN_MORSE);
...
if (ThisMorse) { // if Morse output high, overlay
strip.setPixelColor(PIXEL_MORSE,MorseColor);
}
PrevMorse = ThisMorse;
strip.show(); // send out precomputed colors
...
<<compute colors for next iteration as usual>>
I use the Entropy library to seed the PRNG, then pick three prime numbers for the sine wave periods (with an ugly hack to avoid matching periods):
uint32_t rn = Entropy.random();
...
randomSeed(rn);
...
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);
printf("Primes: (%d,%d,%d)\r\n",Pixels[RED].Prime,Pixels[GREEN].Prime,Pixels[BLUE].Prime);
In the spirit of “Video or it didn’t happen”: YouTube!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters