Archive for category Software

Monthly Science: Chrysalid Engineer

So then this happened:

Karen - canonical tiger paw graduation picture

Karen – canonical tiger paw graduation picture

Yeah, tanker boots and all; not the weirdest thing we saw during RIT’s graduation ceremonies.

This summer marks her fourth of four co-op semesters with Real Companies Doing Tech Stuff and her final classes end in December; RIT holds one ceremony in the spring and being offset by a semester apparently isn’t all that unusual. She (thinks she) has a job lined up after graduation and doesn’t need her doting father’s help.

But, hey, should you know someone with a way-cool opportunity (*) for a bright, fresh techie who’s increasingly able to build electronic & mechanical gadgets and make them work, drop me a note and I’ll put the two of you in touch. [grin]

(*) If that opportunity should involve 3D printed prosthetics with sensors and motors, she will crawl right out of your monitor…



Tempting TV Channel

One of the motel’s TV channels offered this diversion:

Fedora console on motel TV

Fedora console on motel TV

Alas, no combination of keys on the overly complex remote fed themselves to tty1. That didn’t surprise me, but ya gotta try, y’know.

Contrary to what you might think, that’s a well-focused image. Apparently, someone, somewhere, aimed a crappy camera at a monitor and devoted one video input to the result.

I wonder what critical infrastructure runs a Linux distro that end-of-lifed in December 2009.

We’ll never know the rest of the story…


APRS/GPS + Voice Interface: Improved PTT Button Cap

Long ago, Mary picked out a PTT switch with a raised, square post that provided a distinct shape and positive tactile feedback:

PTT Button - bare post

PTT Button – bare post

Time passes, she dinged her thumb in the garden, and asked for a more rounded button. I have some switches with rounded caps, but replacing the existing switch looked a lot like work, sooooo:

PTT Button Cap - Slic3r preview

PTT Button Cap – Slic3r preview

As with all small objects, building them four at a time gives the plastic in each one time to cool before slapping the next layer on top:

PTT Button - on platform

PTT Button – on platform

The hole in the cap is 0.2 mm oversize, which results in a snug press fit on the small ridges barely visible around the post in the first image:

PTT Button - rounded cap

PTT Button – rounded cap

Rather than compute the chord covering the surface, I just resized a sphere to twice the desired dome height (picked as 6 threads, just for convenience) and plunked it atop a cylinder. Remember to expand the sphere diameter by 1/cos(180/sides) to make it match the cylinder and force both to have the same number of sides.

If it falls off, I have three backups.

The OpenSCAD source code as a GitHub Gist:



Raspberry Pi Streaming Radio Player: Mostly Viable Product

The latest version of my simpleminded streaming radio player includes:

  • More durable parsing for track titles with embedded quotes and semicolons
  • Muting during empty / non-music Radionomy tracks
  • The Dutchess County E911 service

Audionomy’s empty / non-music tracks include a remarkable number of mis-encoded MP3 sections triggering decoding problems; those problems don’t occur during music tracks. Some tracks come through as advertisements, which would be mostly OK apart from the garbled / high-volume gibberish, but on the whole they’re un-listenable:

ICY Info: StreamTitle='';
A:1271.0 (21:10.9) of 0.0 (00.0)  4.0% 44%
[mp3float @ 0x7623e080]overread, skip -7 enddists: -5 -5
[mp3float @ 0x7623e080]overread, skip -9 enddists: -6 -6
A:1271.2 (21:11.2) of 0.0 (00.0)  4.0% 45%
[mp3float @ 0x7623e080]overread, skip -7 enddists: -5 -5
A:1309.1 (21:49.1) of 0.0 (00.0)  4.0% 42%
ICY Info: StreamTitle='Targetspot - TargetSpot';
A:1316.4 (21:56.4) of 0.0 (00.0)  4.0% 40%
[mp3float @ 0x7623e080]overread, skip -5 enddists: -4 -4
[mp3float @ 0x7623e080]overread, skip -5 enddists: -2 -2

Muting happens in the mixer, because that seems easier than messing with mplayer in mid-flight. Rather than attempt to control the muted state with specific timeouts, I just un-mute after a new track title arrives; that has no effect if it’s already un-muted. The delays depend on the buffer fill level and avoid the worst of the gibberish.

The player still falls over dead / jams solid on occasion, generally because the incoming data has stopped streaming or delivered severe encoding problems. Other than that, it runs pretty much all day, every day, on at least one of the Raspberry Pi streamers.

Still no track display. Mostly, we still don’t miss it.

The Python source code as a GitHub Gist:



Audio Direction Finding

Given a point source of audio (or RF, for that matter) that’s far enough away to produce more-or-less plane wavefronts, the range difference between two microphones (or ears) is:

ΔR = (mic separation) x sin Θ

The angle lies between the perpendicular to the line from the midpoint between the mics counterclockwise to the source source: + for sounds to your left, – for sounds to your right. That’s the trig convention for angular measurement with 0° directly ahead, not the compass convention, but you can argue for either sign if you keep track of what’s going on.

The time delay between the mics, given c = speed of sound:

ΔT = ΔR / c

For microphones 300 mm apart and c = 344 m/s:

ΔT = 872 µs = 0.3 m / 344 m/s

If you delay the sound from the mic closest to the source by that amount, then add the mic signals, you get a monaural result that emphasizes, at least a little bit, sounds from that source in relation to all other sounds.

In principle, you could find the angle by listening for the loudest sound, but that’s a fool’s game.

There’s an obvious symmetry for a source on the same side, at the same angle, toward the rear.

A GNU Radio data flow diagram that lets you set the angle and listen to / watch the results:

Audio Direction Finding.grc

Audio Direction Finding.grc

The original doodles show it takes me a while to work around to the answer:

Audio direction finding doodles

Audio direction finding doodles


Leave a comment

Clover Seam Ripper Cap

Mary wanted a rigid cap for a Clover seam ripper that came with a small plastic sheath, so I called one from the vasty digital deep:

Clover Seam Ripper - new cap

Clover Seam Ripper – new cap

The solid model looks about like you’d expect, with a brim around the bottom to paste it on the platform:

Clover Seam Ripper Cap - Slic3r preview

Clover Seam Ripper Cap – Slic3r preview

I added a slightly tapered entry to work around the usual tolerance problems:

Clover Seam Ripper Cap - bottom view

Clover Seam Ripper Cap – bottom view

The taper comes from a hull wrapped around eight small spheres:

Clover Seam Ripper Cap - Entry Pyramid

Clover Seam Ripper Cap – Entry Pyramid

That’s surprisingly easy to accomplish, at least after you get used to this sort of thing:

hull() {																		// entry taper
	for (i=[-1,1] , j=[-1,1])
		translate([i*(HandleEntry[0]/2 - StemRadius),j*(HandleEntry[1]/2 - StemRadius),0])
	for (i=[-1,1] , j=[-1,1])
		translate([i*(HandleStem[0]/2 - StemRadius),j*(HandleStem[1]/2 - StemRadius),HandleEntry[2] - StemRadius])

The side walls are two threads thick and, at least in PETG, entirely too rigid to slide on easily. I think a single-thread wall with a narrow ridge would provide more spring; if this one gets too annoying, I’ll try that.

The OpenSCAD source code as a GitHub gist:



Makergear M2 Updates: New Filament Drive Gear with Marlin 1.1.0-RC5

Confronted with a puzzling failure, I decided to perform some long-delayed tweaking…

The folks at Makergear send me (and several others) a new filament drive gear for testing. It has smaller splines / teeth and produces a much finer mark on the filament:

Filament Drive Gear Indentations

Filament Drive Gear Indentations

The obvious stripped section on the right comes from finger-fumbling an absurdly large extrusion distance (something like, mmm, 1450 mm) with a high extrusion speed. Not the fault of the drive gear, that’s for sure!

I remeasured the actual filament length extruded to recompute Marlin’s STEPSPERMM configuration constant. After rediscovering the awkward fact that, when you change that value with an M92 command, Marlin doesn’t recompute the current extruder position, so the next manual extrusion will move a random amount of filament in a random direction, the value eventually converged to 476.9 steps/mm.

I intended to put the M92 in Slic3r’s startup G-Code, but the prospect of random extrusions suggested that now was a great time to update the firmware; again demonstrating that no good idea goes unpunished.

The most recent Marlin version, 1.1.0-RC5 (clearly labeled “Not for production use – use with caution!”), had been released a few hours earlier, so I fetched that and tweaked the configuration files as before.

The firmware now includes thermal runaway / thermistor failure protection for both the bed and hot end. Increasing the two THERMAL_PROTECTION hysteresis values to 6 °C seems to work well.

It also includes a CONTROLLERFAN output that can go active when any stepper is enabled, then off after predetermined time. Setting that to Pin 6 and 30 seconds means the whining fan (it’s a ball bearing replacement in an aerodynamically poor location) in the control box goes off when it’s not needed.

Bumping DEFAULT_STEPPER_DEACTIVE_TIME to 600 seconds means the motors don’t time out while waiting for the platform to reach operating temperature.

Increasing the HOMING_FEEDRATE for the Z-axis to 60*60 mm/min causes it to whack the lever a bit harder and overtravel slightly more. The Z Offset ended up at -2.15 mm, based on the calibration cubes below.

Running a PID calibration on the V4 hot end produced slightly different values: P=17.41, I=1.02, D=74.44. Hardcoding those into the config file does not override the values already stored in EEPROM: you must manually set them with M301, then use M500 to program the EEPROM.

A few Calibration Box iterations settled settled the Extrusion Multiplier at a convenient 1.00 with the new drive gear:

Thinwall hollow boxes - drive gear calibration

Thinwall hollow boxes – drive gear calibration

All in all, that whole process went much more smoothly than I expected.

The config files as GitHub gists:

, , ,