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.

Author: Ed

  • Monthly Science: Wearable LED vs. Dead CR2032 Lithium Cell

    Eight months later, the dead CR2032 cell driving the “ruby” wearable LED has dropped to 2.15 V:

    Wearable LED - on window
    Wearable LED – on window

    It’s not a true red LED with a 1.5-ish V forward drop, but a white / blue LED with red phosphor or a red filter, with a forward drop well over 3 V.

    Against the sunlit backdrop from our kitchen window, the LED looks dark:

    Wearable LED - daylight
    Wearable LED – daylight

    Seen in a dim room, it’s still glowing:

    Wearable LED - dim light
    Wearable LED – dim light

    The current is now far below the 1 mA/div of my Tek A6302 Hall effect probe, so I have no way to measure the few microamps lighting the junction.

    The coarse grid outside the window is a swatch of deer netting we put up during feeder season to keep the birds from killing themselves on the glass.

  • VFAT Time Zone Offset Correction

    An SJCAM M20 action camera includes the date and time in its file names, but the directory entries appear with the wrong timestamp:

    sudo mount -o uid=ed /dev/sdc1 /mnt/part
    ll -tr /mnt/part/DCIM/Photo/ | head
    total 4.8G
    drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
    drwxr-xr-x 2 ed root 144K Jan 25 18:52 ./
    -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100825_001.JPG*
    -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100830_002.JPG*
    

    I’m in the Eastern US time zone, -5 hr from UTC.

    By definition, FAT directory entries contain the “local time” when the file was created / changed. Because it cannot know which “local time” applies, the Linux VFAT filesystem treats the timestamp as UTC and adjusts it by -5 hr.

    So the camera writes the directory timestamps properly. When mounted, Linux correctly (for a reasonable definition of correctly) regards them as UTC, knocks off five hours to match this time zone, and displays the result.

    Alas, disabling the VFAT timestamp conversion has no effect:

    sudo mount -o uid=ed,tz=UTC /dev/sdc1 /mnt/part
    ll -tr /mnt/part/DCIM/Photo/ | head
    total 4.8G
    drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
    drwxr-xr-x 2 ed root 144K Jan 25 18:52 ./
    -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100825_001.JPG*
    -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100830_002.JPG*
    

    I’m not sure why that doesn’t do anything; it doesn’t generate any error messages.

    Although it seems like a reasonable thing, one cannot force a specific time zone with, say, tz=EST or tz=EDT or tz=UTC8 or whatever.

    You can specify an offset in minutes:

    sudo mount -o uid=ed,time_offset=$((-5*60)) /dev/sdc1 /mnt/part
    ll -tr /mnt/part/DCIM/Photo/ | head
    total 4.8G
    drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
    drwxr-xr-x 2 ed root 144K Jan 25 23:52 ./
    -rwxr-xr-x 1 ed root 3.8M Jan 26 10:08 2018_0126_100825_001.JPG*
    -rwxr-xr-x 1 ed root 3.8M Jan 26 10:08 2018_0126_100830_002.JPG*
    

    The time_offset value is subtracted from the directory timestamp, which means you’re feeding in the actual time offset from UTC, including whatever Daylight Saving Time offset may be in order.

    So Linux takes the FAT timestamp, adds (subtracts a negative) 5 hr, and displays the result as my (now correct) local time.

    I suppose I could set the camera to UTC, but then the camera’s on-screen and in-video timestamps would be off by four or five hours, depending on the season. So it goes.

  • MPCNC: Reinforced Z-axis Motor Mount

    PLA isn’t particularly strong, especially in small sections under high stress:

    MPCNC - Cracked Z Motor Mount
    MPCNC – Cracked Z Motor Mount

    I tried solvent-bonding + clamping the break, didn’t expect much, and wasn’t disappointed.

    Stronger versions exist:

    Z Upper Motor Mount
    Z Upper Motor Mount

    It adds a festive touch when done up in orange PETG:

    MPCNC - Reinforced Z Motor Mount
    MPCNC – Reinforced Z Motor Mount

    The attentive reader will note the missing head of the screw anchoring the mount to the left Z rail. Apparently a #32 drill was a bit too small to let the randomly chosen self-tapping screws thread themselves into EMT; they probably anchored a PCB to the plastic case of a long-forgotten lump of consumer electronics.

    It should last long enough for something else to let go …

  • Umbrella Strut Splinting, Round Two

    Two more umbrella struts snapped and required the same repair, but, having drained all the suitable snippets from the Box o’ Brass Cutoffs, some lathe work was in order:

    Umbrella strut splint - cutting
    Umbrella strut splint – cutting

    I used the carbide insert in the mistaken belief it’d be less grabby, then applied the cutoff tool.

    Break the edges, slide splints over the ribs, slobber epoxy on the struts, slide splints into place, apply masking tape for a bit of compression & alignment, and let it cure:

    Umbrella strut splint - curing
    Umbrella strut splint – curing

    Three down, five to go …

  • Astable Multivibrator LED

    Having run out of dead CR123A lithium cells, I soldered up another holder to work through a handful of dead AA alkalines:

    Astable Multivibrator LED Blinky - AA Alkaline mod
    Astable Multivibrator LED Blinky – AA Alkaline mod

    It’s amazing how much light comes from a single wearable LED powered by a dead battery in a dark room!

    Stipulated: I should have 3D printed a CR123A cell adapter. Maybe next time …

  • Hawk vs. Squirrel Scuffle

    A light overnight snowfall revealed an early morning drama:

    Hawk vs squirrel scuffle - overview
    Hawk vs squirrel scuffle – overview

    I think a hawk stooped on a squirrel, perhaps launching from the utility pole by the garden, scuffled across the driveway to the right, and hauled breakfast off to a nearby tree:

    Hawk vs squirrel scuffle - approach
    Hawk vs squirrel scuffle – approach

    The driveway always shows many tracks, but the ones entering from the center-right don’t continue out the left:

    Hawk vs squirrel scuffle - tracks right
    Hawk vs squirrel scuffle – tracks right

    Another view:

    Hawk vs squirrel scuffle - tracks left
    Hawk vs squirrel scuffle – tracks left

    A pair of squirrel pups appeared in the last week. They’d make a good, easily carried hawk breakfast.

    Go, hawk, go!

  • MPCNC: Stepper Motor Back EMF

    A plot of the back EMF for an  Automation Technology KL17H248-15-4A stepper motor looks like I’m making stuff up again:

    KL17H248-15-4A stepper motor - Back EMF vs RPM - data
    KL17H248-15-4A stepper motor – Back EMF vs RPM – data

    Maybe the only questions I ask are ones with linear solutions?

    Anyhow, the data comes from the Z-axis motor in the lathe:

    Stepper back EMF test setup
    Stepper back EMF test setup

    Scary-looking, but reasonably safe. The chuck holds the motor shaft so it’s not going anywhere, the boring bar prevents any rotation, and the motor bearings do exactly what they’re supposed to. Shorting the motor leads would definitely put a hurt on the PLA frame, so I didn’t do that.

    The scope sat on the floor beside the lathe, capturing waveforms and doing calculations:

    Motor Back EMF - 500 RPM
    Motor Back EMF – 500 RPM

    Some waveforms look bent:

    Motor Back EMF - 300 RPM
    Motor Back EMF – 300 RPM

    I asked the scope to measure the RMS voltage, rather than the peak, because it’s less sensitive to distortions.

    Each winding produces one electrical cycle across four mechanical full steps, with the windings in quadrature. One shaft revolution thus produces 200 / 4 = 50 electrical cycles, so converting from shaft RPM into electrical cycles/s goes a little something like this:

    Electrical cycles/s = (shaft rev/min) * (50 cycles/rev) / 60 (s/min)

    Which works out to a tidy 0.833 Hz/RPM, basically spot on the last data point’s 839 Hz at 1000 RPM.

    The motivation for this comes from the third column in the scribbles: back EMF = 22.7 mVrms/RPM = 32 mVpk/RPM.

    A rapid move at 12 k mm/min = 200 mm/s shows the motor current collapsing to the ragged edge of not working:

    G0 X 200 mm-s - 24V 200mA-div
    G0 X 200 mm-s – 24V 200mA-div

    Converting motor speed to shaft RPM:

    RPM = (axis mm/s) / (32 mm/rev) * (60 s/min)
    RPM = (axis mm/min) / (32 mm/rev)

    So the shaft turns at 375 RPM when the X axis moves at 12 k mm/min, with each motor generating 8.5 Vrms = 12 Vpk of back EMF.

    The MPCNC wires the two motors on each axis in series, so the 24 V power supply faces 24 V of back EMF (!) from both motors, leaving exactly nothing to push the winding current around. Because the highest EMF occurs at the zero crossing points of the (normal) winding current, I think the current peaks now occur there, with the driver completely unable to properly shape the current waveform.

    What you see in the scope shot is what actually happens: the current stabilizes at a ragged square-ish wave at maybe 300 mA (plus those nasty spikes). More study is needed.