TTL Vetinari Timebase

A few days ago, a post on HackADay.com featured a Vetinari clock. Though I have yet to read any of the Discworld series, I found the concept so intriguing that I began to consider my own build.

Not wanting to repeat the work of others, only with a different CPU, I set out to find another way. Eventually, I arrived at a LFSR (Linear Feedback Shift Register) based design. Here is a link to a simulated 8-bit version. 

In the simulation, the LFSR has a few extra gates to force some logic 1s in to the shift register at start-up. The clock input to the counter is running at 128 Hz. When the counter reaches 255, its' carry ouput goes high, first causing the LFSR to advance to the next value, then loading the counter with the LFSR's new value. Every 255 carry events, the LFSR is back at its' original state and the counter has counted 32,640 clock cycles.

Rummaging my parts stash, I found a 74322 8-bit shift register and 7486 quad XOR to build the LFSR. No 8-bit counter to be found however, so a pair of cascded '161s will have to do. A little extra logic help from a 7400 quad NAND, and it's time to build. Time? What kind of prototype would this be if it didn't have a 555 timer? It's a hack, but the 555 is running at 125 Hz and I didn't have to go look for the signal generator.

If we scale this up to 16 bits, it could run directly from a 32768 Hz oscillator. It would have the correct time every 18-ish hours. A wonky timebase, a 7 segment display made from LED filaments, this might be a new project.

Cleaning a shop-vac filter in 1 minute flat

It took me way too long to figure this out. Until a week ago, I would blast the filter with compressed air. What seemed like a dozen cycles and an hour later, the job would be done. One late afternoon, staring at yet another clogged filter, here's what I did:

1) I tracked down the adapter plate for the old style cylindrical filter, it looks like this:

You'll need two of these if your vac has a cylindrical filter. Alternatively, you could look for a press-on filter for your vac. This type:

2) Next, a deep-dive in to the spare parts bin to find a 8mm (5/16 inch) steel rod that was about 1.5 times the height of the filter.

3) Put the adapter plate on the open end, then skewered that assembly with the rod. Here it is, ready to go:

4) Set the vac to blow, with the concentrater attachment at the end of the hose.

5) Hit the power, and hang on! The filter rapidly spun up past 1,000 rpm, or so it seemed, and a cloud of dust, dirt and dander went flying.

6) I moved the blower wand up and down the height of the filter a few times, then changed rotation direction just for fun. A full minute later, there is nothing visible blowing off the filter and it looked to have its' original blue color.

Disclaimers:

You might not want to try this in an urban area, it may turn the neighbors hostile. However, my next HackADay project might be filter spin-chamber with an exhaust debris capture bag.

The photos above were shot with a spare filter that had been cleaned with the method described.

I guess I'll have to post a short video of me airing my dirty filter some day.

Networking chicken and egg

I had a recent need for mobile computing, preferably with a larger screen size. So I dusted off the GalliumOS powered Toshiba chromebook to discover it refuses to connect to wifi. Delete the connection entry, reboot, create a new one. Nope. Hmm. Network admin brain cells start warming up, a command line or two later, and I have an interesting error message about "no available address". Ok, over to the desktop to check the access point's status screen. Isn't there a special address I need to use, or something? Rooting around the desk unearths the manual and the necessary settings. Boot a live CD for the interim? Nope, too scuffed up.  Fine, ifconfig<enter> "command not found"? Oh, right /sbin/ifconfig<enter> "command not found". SAY WHAT??? My recent upgrade to Debian-Bullseye didn't include those ancient net-tools for which I've memorized the syntax. By this time I've done a full reset on the AP, but the wired ethernet connection should work with minimal intervention, right? Hours later at least the wifi is working and has the correct settings, but the wired connection to the desktop is still dead. Umm, no, couldn't be that. <checks hub under the desk> Only one connection indicator? The desktop _is_ plugged in, that means...

All that time wasted, because of a broken tab on an RJ45. The cable had unplugged itself one or another time that I flipped over the AP to check or re-check its' default values. All I want for Christmas is a RJ45 crimping tool. ;)

Oh, right. Back to the chromebook and why we're really here. With a fully functioning network, updated firmware on the AP, and a nice clean block of 192.168.0.* for DHCP leases the 'book still reports no address. Since it hasn't been used in many months, dhclient -r? Nothing changes. Using nmcli's monitor mode, I notice that it is alway failing at the DHCP lease step. A bit more digging in DHCP land, but nothing changes. I'm not sure why, but I checked the date/time on the 'book to discover that, while the date was off by about a month, the year was somehow set to 2166! Uhh, what? The month being off by a little, due to a dead battery, should resolve as soon as NNTP runs. Without a network to correct the time, a century-expired DHCP offer would be rejected, right? Is it time for a deep-dive in to the relevant RFCs?