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

  • Dell 75UYF Battery Teardown: Cell Capacity

    Putting that battery into the Dell 8100 laptop produced the dreaded blinky light of doom, so it has been on the shelf for maybe half a year. Having gutted the cells from the case, the next step was to discharge the cells completely, thereby producing the lower four curves in this plot:

    Dell 8100 Laptop Battery Cells
    Dell 8100 Laptop Battery Cells

    I arbitrarily labeled the cell pairs 1 through 4. Pair 1 has the lowest remaining charge and the other three seem very closely matched.

    I recharged the four cell pairs one-at-a-time from a bench power supply set to 4.2 V. Each pair started charging at about 2 A, somewhat lower than the pack’s 3.5 A limit, so the supply’s 3 A current limit didn’t come into play. You probably don’t want to do this at home, but …

    The usual charge regime for lithium cells terminates when the charging current at 4.2 V drops below 3% of the rated current (other sources say 10%, take your pick). The pack’s dataplate sayeth the charging current = 3.5 A, so the termination current = 100 mA. I picked 3% of the initial 2 A current = 60 mA and stopped the charge there, so I think the cells were about as charged as they were ever going to get.

    As nearly as I can tell, increasing the voltage enough to charge at a current-limited 3.5 A (a bit beyond my bench supply’s upper limit, but let’s pretend), then reducing the voltage to 4.2 V as the current drops would be perfectly OK and in accordance with accepted practice, but I’m not that interested in a faster charge.

    Unlike the other three pairs, Pair 1 quickly became warm and I stopped the charge. Warming is not a nominal outcome of charging lithium-based cells, so those were most likely the cells that caused the PCB to pull the plug on the pack. The other pairs remained cool during the entire charge cycle, the way they’re supposed to behave.

    However, even with that limited charge, Pack 1 had about the same capacity as the (presumably) fully charged Pack 2, showing that the cells get most of their charge early in the cycle. Pairs 3 and 4 had more capacity, but they’re not in the best of health.

    The blue curve in this graph shows the discharge curve for the 1.1 A·h Canon NB-5L battery (actually, a cell) that came with the SX230HS camera:

    Canon NB-5L - first tests
    Canon NB-5L – first tests

    Notice that it remains above 3.4 V until it produces 1.1 A·h at 500 mA, which is roughly its rated capacity. The other traces come from those crap eBay NB-5L batteries.

    The two best pairs of Dell cells can each produce about 1.3 A·h at 1 A before dropping below 3.4 V (the cursor & box mark that voltage in the top graph), so they’re in rather bad shape. Strapping the best two pairs together would give a hulking lump with perhaps three times the life of the minuscule NB-5L battery, so I think that’s probably not worth the effort.

    Particularly when one can get a prismatic 3.7 V 5 A·h battery for about $30 delivered, complete with protective PCB and pigtail leads…

  • Quilting Pin Caps: Recycled O-Ring

    While doing something else, I rediscovered the fact that common 5 gallon plastic bucket lids have an O-ring gasket that seals against the top of the bucket. Some seals are hollow tubes, some are solid rods:

    5 gallon can lid gaskets
    5 gallon can lid gaskets

    The white O-ring has about the right consistency to serve as a quilting pin cap, along the lines of those 3D printed and silicone rubber filled cylinders. Although the rubber / plastic stuff isn’t quite as squishy as silicone snot, it holds the pin point firmly without much of a push.

    Chopping the O-ring into 10 mm sections produced another small box of prototypes:

    Lid gaskets as pin caps
    Lid gaskets as pin caps

    Garden planting season remains in full effect, shoving all quilting projects to the back burner and delaying the evaluation phase of the project…

  • Garden Knife Scabbard

    Mary uses an ancient paring knife (that, back in the day, my father had sharpened beyond all reason) to harvest garden veggies, which called for a scabbard to protect the blade, the bike pack, and the fingers.

    I snagged a random block of acrylic from the heap, straightened the long sides, milled a channel just wide and thick enough for the blade down the middle, then added small recesses at the right end for the knife’s haft:

    Garden knife scabbard - main block
    Garden knife scabbard – main block

    The cover is an acrylic sheet, solvent-glued and clamped in place:

    Garden knife scabbard - clamping cover
    Garden knife scabbard – clamping cover

    The cover exposes about 1/4 inch of channel so she can lay the point in place, rather than precisely aligning the point with the slot. I suppose I should have used gray acrylic to provide some contrast; maybe we’ll add a snippet of tape.

    Then mill four sides flat, break the edges & corners with a file, and it’s all good (in a blocky kind of way):

     Garden knife scabbard
    Garden knife scabbard

    The blade has become sufficiently bent over the years that simple friction holds it in the slot. It’s open on both ends so she can flush out the inevitable dirt.

    I was going to engrave her name on the back, but came to my senses just in time…

     

  • Forsythia Clearing

    It was decided, in that place where what is decided must be, that the time had come to hack back the giant forsythia stand encroaching from the neighbor’s yard. The stuff tip-roots, so anything that stands in its way gets assimilated, and the only way to make headway is to tear it out by the roots.

    We eventually clearcut a section about 15 feet wide and 40 feet long by the simple expedient of lopping off everything that stuck up:

    Cleared Forsythia
    Cleared Forsythia

    Removing the roots required prying with a 7 foot length of 1.5 inch octagonal steel bar braced on a chunk of 4×4 inch lumber rammed up against the roots. With my full weight on a 6 foot lever arm, the roots would just barely break free.

    A dozen wheelbarrow loads like this went atop the branches on the heap:

    Forsythia root balls
    Forsythia root balls

    That’s my kind of outdoor work: kill them all…

    Mary raked and seeded the debris field just before the next rainfall. It ought to be good for another few years.

  • NIC Backpanel Shortening

    Actually, that NIC didn’t slip right into place, because its backpanel plate was sized for a full-height PC case. Unlike the cheap stamped steel you find these days, NetGear used much thicker metal that required an attack with the bandsaw, a hammer, and some files to clean up the raw edges.

    But it fit pretty well after all that:

    Shortened NIC backplate
    Shortened NIC backplate

    You can just barely see the NetGear logo wrapped around the right-angle bend…

  • Upstart vs. rc.local

    In the process of figuring out how to set up the isolated WiFi Internet link on the file server, I discovered that the /etc/rc.local file runs before the eth0 interface that connects to the outside world comes up. As a result, my DynDNS host address hadn’t been updated in quite some time.

    Worse, trying to set up eth1 failed, apparently because there’s a bunch of other network infrastructure that doesn’t start until eth0 comes online. Part of that infrastructure involves iptables; the added rules simply vanished.

    The solution seems to require writing an upstart script that waits for whatever events it needs, does what needs to be done, and then goes away. The whole upstart mechanism and its event list seems, um, lightly documented, as I discovered there, but the custom setup formerly in /etc/rc.local now lives in /etc/init/local.conf:

    description "Stuff that used to be in /etc/rc.local"
    author "Ed Nisley - KE4ZNU"
    
    start on (local-filesystems and net-device-up IFACE=eth0)
    stop on shutdown
    
    script
    
    logger Starting local init...
    
    logger Updating dyndns
    ddclient -force
    
    logger Bringing up eth1
    ifconfig eth1 192.168.3.1 netmask 255.255.255.0 up
    
    logger Setting iptables
    iptables -A FORWARD -i eth1 --destination 192.168.0.0/16 -j REJECT
    iptables -A INPUT -i eth1 --destination 192.168.0.0/16 -j REJECT
    iptables -A POSTROUTING -t nat -j MASQUERADE
    
    logger Ending local init
    
    end script
    

    That code assumes the outbound network interface will be eth0, which won’t work on a system using a pure wireless connection on, say, wlan0 or anything more exotic. I haven’t a clue how to parameterize that selection. Most likely, one would write another upstart script that would emit a custom signal based on the usual suspect …

    It also assumes the networking infrastructure triggered by eth0 lighting up has hauled itself to its feet and is ready to roll. That seems to be true, although I’ll admit the script is, at best, lightly tested.

    With the eth1 NIC up and iptables rules added, I think this script will restart eth1 when it goes down, but it’s not clear where the requisite network-device-down event comes from (certainly not from any script in /etc/init/*conf):

    description "Restart eth1 when it dies"
    author "Ed Nisley - KE4ZNU"
    
    start on net-device-down IFACE=eth1
    stop on net-device-up IFACE=eth1
    
    script
    
    logger Restarting eth1...
    ifconfig eth1 192.168.3.1 netmask 255.255.255.0 up
    
    logger Ending eth1 setup
    
    end script
    

    But, eh, at least the isolated interface comes up and packets go where they should (and not where they shouldn’t). Early results are encouraging…

  • Isolated Internet Access for Guests

    We provide a camping spot for touring bicyclists riding through the Hudson Valley and, as you’d expect, most of them arrive toting netbooks, tablets, and other net-enabled doodads. While I’m a nice guy and they’re uniformly nice folks, I’d rather not hand them the keys to our house network, so I recently set up a WiFi Internet-only access point that’s firewalled from the LAN.

    The general idea:

    • Use a stock WiFi router to handle DHCP / DNS / WiFi for guests (192.168.2.x)
    • Add a second NIC to the file server as eth1 (192.168.3.1), connected to the router’s WAN port (192.168.3.2)
    • Forward packets between eth0 (house network 192.168.1.x) and eth1, except …
    • Use iptables to prevent router clients from seeing the house network

    The network layout:

    Guest Internet Access Overview
    Guest Internet Access Overview

    The parts came from the Big Box o’ Network Stuff:

    • Linksys / Cisco WRT54G router (Version 8, so OpenWRT won’t run)
    • NetGear 10/100 Mb/s Ethernet PCI card

    The router setup:

    • Static WAN at 192.168.3.2
    • Router base address 192.168.2.1
    • DHCP range 192.168.2.100 through .149, lease time 1 hour
    • DNS entries 4.2.2.1 (L3), 65.88.88.2 (NY Public Library), 129.250.35.250 (NTT)
    • WiFi access to the web admin page disabled (admin only via CAT5 in the Basement Laboratory)
    • Non-broadcast SSID, not that it matters very much
    • WPA2-PSK with an XKCD-style password

    The NIC Just Worked: the drivers come along with the kernel. Because it’s not a general-purpose network interface from the server side, eth1 setup doesn’t require much effort:

    ifconfig eth1 192.168.3.1 netmask 255.255.255.0
    

    I discovered the hard way that trying to define the eth1 interface with Network Manager caused no end of heartache & confusion, not least of which is that having two NICs somehow activates Ubuntu’s internal firewalling & port forwarding. Suffice it to say, just set the NM’s GUI to Ignore the eth1 NIC and do what needs to be done manually.

    With one NIC, Ubuntu runs iptables in “let it be” mode: everything’s allowed, nothing’s blocked, and all packets get forwarded. The tables are empty and the default ACCEPT policy passes everything.

    Adding a rule to the FORWARD chain prevents the router from sending packets to the house network:

    iptables -A FORWARD -i eth1 --destination 192.168.0.0/16 -j REJECT
    

    That still allows a ping response from the file server’s eth0 NIC at 192.168.1.2 back to the WiFi clients, because packets addressed to the server pass through the INPUT chain. This rule squelches those packets:

    iptables -A INPUT -i eth1 --destination 192.168.0.0/16 -j REJECT
    

    Although packet forwarding is enabled by default, another rule turns on the NAT machinery required to shuttle packets between the 192.168.3.x network and the outside world:

    iptables -A POSTROUTING -t nat -j MASQUERADE
    

    While fiddling with iptables rules that involve packet state tracking (which these do, at least implicitly, I think), you must reset the packet state memories to ensure new packets aren’t regarded as part of an established connection. Install the conntrack utilities, then reset the state as needed:

    sudo conntrack -F
    

    And then it Just Worked.

    Now, back in the day, you’d just put those configuration lines in /etc/rc.local and be done with it. Unfortunately, nowadays the upstart process kicks off rc.local well before the system is in a usable state: somewhat before eth0 is active, which means any automagic network-related activity falls flat on its face.

    So an upstart configuration script is in order… more on that later.

    Some useful, albeit occasionally befuddling references:

    One could, of course, buy dedicated hardware to do all that and more, but it’s nothing you couldn’t accomplish with a bit more configuration on a stock Linux box. Heck, you could even serve an Upside-Down-Ternet to anyone who deserves it; the original has some other suggestions that made the big time.

    A tip o’ the cycling helmet to Dragorn of Kismet for getting me started…