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.

Tag: Improvements

Making the world a better place, one piece at a time

  • NPN RGB Astable Multivibrator Timing Adjustment

    NPN RGB Astable Multivibrator Timing Adjustment

    Back in the beginning of July, I replaced the NP-BX1 battery in the RGB Piranha astable multivibrator with a 18650 lithium cell and a USB charge controller, then watched it blink for the next two weeks on the first charge:

    Astable - 10 11 12 uF tweak - 027
    Astable – 10 11 12 uF tweak – 027

    However, the blinks looked … odd and some poking around with a Tek current probe showed the red and blue astables had locked together, so they blinked in quick succession. Alas, I don’t have a scope shot to prove it.

    I built all three astables with the same parts, figuring the normal tolerance of electrolytic caps would make the astables run at slightly different rates, which they did at first.

    This being a prototype, I just soldered a 1 µF cap onto the blue channel’s existing 10 µF cap:

    Astable - 11 uF cap - detail
    Astable – 11 uF cap – detail

    You can barely make out the top of the additional 2.2 µF cap on the red channel, through the maze of components; now, they definitely have different periods.

    Aaaand the scope shot to prove it:

    Astable NPN - 10 11 12 uF tweak - 10 mA-div
    Astable NPN – 10 11 12 uF tweak – 10 mA-div

    The bottom trace shows the battery current at 10 mA/div. The first pulse, over on the left, has the red and blue LEDs firing in quick succession with some overlap, but they separate cleanly for their next pulses.

    You don’t want to build a battery-powered astable from NPN transistors, because the 8 mA current between blinks is murderously high. In round numbers, each of the three LEDs blinks twice a second for 30 ms at 20 mA, so they average 3.6 mA, less than half the current required to keep the astables running between blinks. Over the course of 14 days, the circuit drew 11.6 mA × 336 hr = 3900 mA·h until the protection circuit shut it down.

    The lead photo shows a harvested 18650 cell, but I started with a known-good Samsung 18650 cell rated at 2600 mA·h at a 0.2C = 520 mA rate to 2.75 V. It’s comforting to see more energy trickling out at a 0.005C rate!

    I must conjure a holder with contacts for an 18650 cell, support for a trio of 2N7000 MOSFET astables, and some kind of weird spider with the RGB Piranha LED on the top. Even a harvested 18650 cell should last a couple of months with a much longer blink period (500 ms is much too fast), less LED current (this one is shatteringly bright), and a lower average current.

    And, yeah, I’ve been misspelling “Piranha” for a while.

  • Pan Lid Handle Quieting

    Pan Lid Handle Quieting

    A surprisingly heavy stainless steel pan lid from the local ReStore has only one fault: when placed upside-down on the counter while we’re tending the pan contents, it will rock back and forth for nearly a minute. The lid has a rubberized insert for finger protection:

    Pan lid - original handle
    Pan lid – original handle

    However, the inserts cover only the side of the handle, so the metal arch rests on the counter. Setting it up in the shop let me scuff up the handle contact points:

    Pan lid - contact point
    Pan lid – contact point

    Then some Dremel grinding wheel work recessed the handle just barely below the inserts and changed the arch enough to keep it off the counter:

    Pan lid - recessed handle crest
    Pan lid – recessed handle crest

    The lid now stops rocking after a few seconds and is much quieter while doing so. It may require a bit more grinding, but it’s much better after this small intervention.

  • Makergear M2 V4 Nozzle: Silicone Refresh

    Makergear M2 V4 Nozzle: Silicone Refresh

    After a year and a half, the silicone coat I’d applied to the M2’s nozzle had pretty much worn away, so I peeled off the remnants, buffed up the brass, and mushed on another coat:

    Makergear M2 V4 Nozzle - High-temp silicone coat
    Makergear M2 V4 Nozzle – High-temp silicone coat

    The coverage isn’t even, particularly in the direction I can neither see nor reach with the hot end still in the printer, but it’s way less hassle than recalibrating the Z=0 position. The very thin layer over the brass around the nozzle will vanish immediately on the skirt surrounding the first part.

    I should definitely recoat the nozzle more often, because PETG doesn’t stick to silicone nearly as well as it does to brass: a nice new coat makes the PETG burned-snot problem Just Go Away.

  • Harvesting 18650 Lithium Cells

    Harvesting 18650 Lithium Cells

    With a Dutchess County Household Hazardous Waste Collection Day coming up, I’ve been harvesting usable lithium cells from a variety of old batteries:

    Harvested 18650 3P lithium batteries
    Harvested 18650 3P lithium batteries

    The pile of 18650 3P blocks over on the right are some obviously corroded deaders and the lowest performers from these tests:

    Harvested 3P 18650 Packs
    Harvested 3P 18650 Packs

    I doubt they’ll get recycled, as there’s entirely too much overhead involved in dismantling boxes full of cells like these, but I hope they’ll get a decent burial somewhere.

  • Closing the Dmesg Audit Firehose

    I’m not entirely clear what’s being audited in the Manjaro Linux boxes I’ve recently set up, nor what the difference between res=success and res=failed might mean for the x11vnc unit:

    [   98.632347] audit: type=1131 audit(1594859418.419:110): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=x11vnc comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   98.632348] audit: audit_lost=46 audit_rate_limit=0 audit_backlog_limit=64
[   98.632349] audit: kauditd hold queue overflow
[   98.649743] audit: type=1130 audit(1594859418.433:111): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=x11vnc comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
[   98.649745] audit: audit_lost=47 audit_rate_limit=0 audit_backlog_limit=64
[   98.649746] audit: kauditd hold queue overflow
[  100.515527] audit: type=1101 audit(1594859420.299:112): pid=843 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="ed" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'

    That’s the better part of two seconds in the life of the box and, later on, the pace picks up. Casual searching suggests nobody else knows what’s going on, either, apart from the fact than that it obviously has something to do with systemd and, thus, is just the way things are these days.

    Add audit=off to the default kernel command-line parameters by editing /etc/default/grub thusly:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=whatever udev.log_priority=3 audit=off"

    Then update the bootloader:

    sudo grub-mkconfig -o /boot/grub/grub.cfg

    Whereupon dmesg becomes all quiet and (mostly) meaningful to this civilian.

  • Lending a Hand

    Lending a Hand

    This being repotting season, Mary trimmed a pair of leaves from a bay tree and wanted to dry them for cooking, so I offered to lend a hand:

    Bay leaves drying in helping hand fixture
    Bay leaves drying in helping hand fixture

    Two hands, in fact.

    The whole affair now sits on a kitchen windowsill, shriveling by the day, and the leaves should be ready in a month or two. Yum!

  • Copying All! The! Files! (Except Some)

    All our data files spin around on a nearly full 1 TB drive in a “file server”, a grandiosely overqualified and dirt-cheap off-lease Dell Optiplex desktop sitting in the basement. It’s been running headless and unattended for the last half-dozen years and is badly in need of replacement, so I must copy all its files to a newer, even more overqualified, and equally cheap off-lease Optiplex.

    Copying the files from the /mnt/music collection on the existing server to the identically named directory on the new server proceeds thusly:

    sudo mount -o ro fileserver.local:/mnt/music /mnt/nfs
sudo rsync -ahu --progress --log-file=/tmp/music.log \
 --exclude="/lost+found" \
 --exclude=".Trash*" \
 --exclude=".dtrash*" \
 --delete \
 /mnt/nfs/ /mnt/music

    Mount the existing collection (from the old server) in read-only mode to avoid heartache subsequent to confusion. It could happen.

    The first time through, add a -n option for a dry run, then inspect the log file for surprises.

    The various --exclude options avoid copying trashed-but-not-yet-deleted files from the various trash directories maintained by various file handlers. In the process of sorting this out, I learned the DigiKam photo manager creates a .dtrash directory holding deleted files for each of its Album listings, appearing down near the bottom of the top-level album wherein you’ve quasi-deleted photos via “Move to Trash”.

    The --delete option removes files on the destination (new disk) if they’re not on the source (old disk). I started this migration earlier this year, before the world fell apart, and have moved / consolidated / renamed various directories & files in the interim, so deleting the previous copies from their old locations makes the destination match the source.

    So far, so good …