Darrin B's pages

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.

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?

During the summer, when I wasn't cutting firewood or working on the WellWell device, I was applying my wrench to the Passodeo. It just wasn't running right. Potential culprits included a few five dollar parts, so I replaced those first. Sure enough, testing the throttle position sensor did reveal a bit of jumpiness, but the overall situation did not improve.

Being a 20+ year old car, the next most likely culprit would be the fuel pump. A 15 dollar part, ok. The shop manual tells me that there are just 10 bolts to remove to do the job. Easy-peasy, right? Again, the manual writers omitted the first step, 1) Remove body from frame.

A few choice words and a lot of pressure washing later the bolts were located and removed. It may sound easy, but there was so little clearance, I could only move the wrench one ratchet click at a time, by my fingertips only. Parts ordered, parts received, bolt threads cleaned, reassemble!

There are three hoses from the tank, fuel out, fuel return and a tank vent. Be sure to mark their connections on the fixed endpoints before dissambly. The return and vent happen to be the same size on the Passodeo and I managed to swap these lines. Oops. The result was fuel dribbling from the vent port at the rear of the car. Opening the gas cap relieved the pressure enough to stop that. More troubleshooting needed.

Just to be certain that I would re-connect the right line to the right port, I disconnected the vent line at the purge solenoid/valve at the intake manifold to blow air through the line. No flow? WTF? Is there another valve somewhere? No, following the rubber hose to the steel tubing to the rubber hose at the far end revealed nothing interestng. A quick puff of air on the removed rubber hose was rewarded with a shower of charcaol granules. The hose was completely plugged. Checking at the other end revealed the same problem. Oh, no is the steel line also plugged? It sure was. Repair, replace, or bypass? It is a pipe, a small one, but still a pipe. I crafted a drain snake from a speedometer cable that I had not yet installed in a friend's car and a length of plastic drip-irrigation tubing. It took a couple of hours, but that line is flowing freely now! The vent valve and its' filter were plugged with granules, too. Better check the purge valve, that I replaced a few weeks ago. A few more chunks fell out of that.I can only wonder how much made it in to the intake, and then through the valves. Time will tell, I guess.

I read them. I'm paying the price.

When I was shopping for a new phone, only de-Googled models were on the list. The one I chose claimed full T-Mo compatibility, but after the episode with my previous phone, I was dubious. According to the T&C, returning the phone would be at my expense, shipping it to an address in Canada. Well, ok. Buy now.

It arrived, from France, days ahead of the replacement SIM I ordered from my carrier. After two weeks of online support chats with the carrier, I gave up on the phone. It just would not work on the network. (T-Mo band 12 seems to require some sort of special VoLTE white-listing, which I suspect that this phone didn't have.)

I filed the paper work required by the vendor and shipped it off to the address specified. The shipping charge set me back $130. But this is what I agreed to, right? After a week, or so, in customs it it is out for delivery. It was refused! This was also about the time a shipping label arrived from the vendor. Huh? The phone sat on the shipper's truck for another week before the return to sender caught up to it. Then another week in customs, and finally the phone is back at the shipper's office here. It will be another $150 to take possession of the phone from the shipping company? What!!! At least they didn't manage to crush the phone in transit.

Slapped their label on it and off it goes. Nearly three months later, still no refund.

This is a work in progress, and will look like one for some time to come. The vehicle in question is a '96 Honda Passport (also known as the Isuzu Rodeo).

For reasons unknown, the Passodeo decided to eat a spark plug one morning. Ceramics and machined moving steel are a bad mix, great clouds of billowing smoke ensued.

Why a 6VE1? This area's rebuild shops had at least a 2 month lead time, if they were even willing to even specify one. A rebuilt 6VD1, on reasonable terms, could not be located. A used JDM 6VE1 popped right up. Days of rummaging forums later, the 6VE1 was ordered.

Comparing the two engines, the 6VE1 looks to be a better laid out engine. Some bolted on pieces were integrated in to the block casting and coolant ports were relocated to require fewer rubber-metal interconnections.

Step 1: remove body (Looking back, this could be the better choice.)
alt. Step 1: Remove most things other than the body. We went as far as unbolting and moving the front axle.

Take note that Isuzu uses a 'forward pull' clutch. If you haven't encountered one, read up about them before beginning.

Intake Manifold: Using the 6VE1 intake, with 6VD1 injectors stuffed in to it for compatibility with the existing electronics. A bit of grinder work on the manifold helped the fit. At present, the intake control valve is not connected, so the high RPM performance may be a bit less than optimal. It turned out that there was an air leak in the cobbled together intake that caused a check-engine code, or two. Sealing the joints with silicone tape partially cleared up a few of them. Someday, we will have to install a customized intake system.

Exhaust manifolds: 6VE1 bolted right up to the stock exhaust system

Bell housing: Mated up after relocating some guide pins. Only a small sheet metal cover remains to be fabricated.

Throttle: Mounted the 6VD1 cable actuated body on an aluminum adaptor plate. I'll upload an openscad file. Attaching the intake to the air filter box, took a bit of hacking and hacksawing.

Engine oil dipstick: Checking the oil level may require a contortionist's assistance. 

Since 6VD1 accessories are on separate belts and the 6VE1 uses a single serpentine belt, some re-rigging had to be done. Mostly, we just swapped the pulleys.

The radiator fan was destroyed while the engine was in the warehouse. The conversion to a serpentine drive causes the fan to rotate in the opposite direction, so a replacement was needed.

Pwr. Steering: The ECU is expecting a signal from the power steering pump. If we get a check engine code, we'll go back and swap the pumps.

Wire Stretching: Sensors were re-arranged and a larger intake manifold means that there are a lot of wires to be moved, cut and spliced. The cam sensor could not be transferred from the older engine, so the new sensor's plug was spliced in to the harness.

Crankshaft sensor: This was the part that prevented immediate success. Could be that it was damaged or wired differently, but the sensor from the 6VD1 dropped right in. The car started up on the second try.

MAP sensor: Another sensor that needed to be spliced in. In testing, it appears to use the voltages for power and signal. However, the red wire is not +5V from the ECU.

The result: There are a few check engine codes to sort out, but it is running quite smoothly and has very good performance.

Ordering replacement parts in the future will be amusing. Should I order both '98 Trooper and '96 Passport parts, then return the one that does not look right? (This just happened with a potentially faulty MAP sensor.)

May 2024: The intake mentioned earlier was not quite up to the task. Rebuilding it, this time with RTV silicone sealant and a tuna can, cleared a few codes. The tuna can serves as an interface between the Trooper intake tube and Passport's MAF sensor, and plenty of places to apply the adhesive sealant. Also, be sure to bind the leads on O2 sensors before installing them. It turned out that I broke...

This page started as a real world test of an idea sprang from a thread on Stack. I'll be adding bits of content here, for many months.

The focus of the content will be GAL type devices, since I see them as a good starting point in the wide world of PLDs. Within limitations the info here can be applied to older PAL devices, or be expanded to make use of newer devices.

If you've never used one of these gadgets, the place to start is simple boolean logic. AND, OR, NOT and their friends. Karnaugh maps (K-Map) are nice to know, as are DeMorgan's Theorms, but mastery of these principles are not required, just learn them as you need to.

Got a handle on boolean? Great! Now grab any old TTL chip in the 7450 to 7465 range, most of those are "AND-OR-Invert" devices. Build a circuit and you have a hard-wired version of a K-map.

The next step would be in to PAL family of devices, but they're one-time programmable. One tiny logic error and you have an unusable chip.

Here we go! The part numbers of a GAL device (PAL also) describes the maximum number of inputs and outputs available, as well as the internal post-processing function. A GAL16V8 can make up to 16 of the pins function as inputs, and up to 8 of the pins can be used as outputs. The 8 also describes the total number of "cells". Think of each cell as being a 7450-type device, a 7474 flip-flop, a tri-state buffer and an inverter. All outputs have an internal connection that can be used as a logic input to another cell. However, if you need more than 8 external inputs you will have to either reassign an output to be one of the inputs or you could use the clock and output enable inputs as global inputs but lose the flip-flop and tri-state ability. Unless you're making a Signetics 25120 WOM, you'll want to save at least one of the cells for output duty.

A question you may be asking now is "How many chips does this device replace?" Well, a 16V8 contains 4x 7474 dual D-type flip flops, 8x 8-ish input OR gates, 2x 7486 quad 2-input XOR gates, and a small mountain of 7400s. Your ability to wrestle logic equations (DeMorgan-ize) plays a big role in the answer. My current best wedges (mostly) an 8 bit up/down counter with clear in to a 16V8, requiring a pair of 3 input AND gates and a pair of 3 input OR gates to function.

That's quite a lot to grasp all at once, and there's more to come. Stay tuned...

Drop your PinePhone just once...

It wasn't a big fall, just a minor nick on the shell and no effect on the screen. Now there is no calling or texting, in or out.

Place a jumper across two test points to force the modem in to a download mode. Motionless for two minutes while it boots up? Forget that, solder a jumper on the test points. No joy, the modem still not showing up in lsusb.

At least, the Pine has replacement parts available. It took longer to find the micro-screwdriver kit than it took to swap the main board. (The kit was on my desk.) Load the latest Mobian build, and we are back up and running.

The Pine is also the absolute easiest phone to develop an app for. It starts like this:

#!/usr/bin/python3<br>

import tkinter

That's it! In less than a month, I had an app ready for my Well Well project. Much of that time was  learning to use Python.

First, a question. Can anyone out there tell me how the water system in my home knows that it is late afternoon on Friday? Six of the eight times the system has failed, whether due to lightning, freezing or some other cause, it was within an hour of 5 p.m. on a Friday. As a consequence of the time, all of the area well service businesses have closed up shop for the weekend and I am facing a weekend of many inconveniences.

Here I am again, this time it is a frozen water line. That's the second time this winter. I believe that the culprit is the drain-back valve that is in the well shaft. Replacement must wait until spring, because large service trucks and steep, snow-covered driveways are not a good mix.

Part of my water pumping system is a monitoring device. Its' primary job is to shutdown the pump when the well runs dry. When things siezed up earlier this winter, I took note of an infra-red(IR) output built in to the monitor and the availability(for a price) of a device to display the output. Ooooh, time to dust off my reverse engineering skills.

An unknown IR signal, I'll start with a plain old phototransistor. A second transistor to make it a cascode, and a third to amplify the signal up to clipping. A few ideas later, I have a 3.3V digital signal piped straight in to my preferred micro-controller, the Z8. A digital storage scope would be nice, but it would spend most of its' time taking up space. Just a little bit of code and I have established the minimum and maximum pulse lengths that the well monitor is transmitting. A bit more code and the bits are on a timebase, guess I have a low-budget digital 'scope after all.

Staring at bits with GnuPlot (after processing with a bit of software) I identified a few interesting features, long break, short break, preamble and chunk. After modifying the code on the Z8 to start after the long break, the repeat cycle was found to be 16 chunks.

It's been a month, or so, since the last update. The input circuit has been modified a bit, it is now just the phototransistor and a PNP transistor. Using an IRDA port on another dev board, I was able to ascertain that my cobbled together system had no trouble detecting micorsecond duration IR pulses. Once I worked out how I could use the counter's gated mode with the DMA controller, I became able to measure the input signal in real-time. With a bit more code, I was sending a VCD file to Pulseview. Time to parse.

It was when I split the signal in to segments and then stacked those segments that a few interesting patterns emerged. Spliting the signal in to even smaller pieces, it became clear that it was a 32 bit value, without any encoding, was being transmitted.

Though I could take a software only approach to collecting the bits, using the SPI (Serial Peripheral Interface) port would likely have benefits. But where to get the clock signal? An on-chip timer should do nicely. Some re-wiring, new code, and a few terminal control characters later, I'm watching a grid of 32-bit values on my desktop. Thanks to a winter snow storm, I was able to determine that the bits were inverted. How is that possible? One of the values that the well monitor reports is line voltage, the snow storm caused the line voltage to drop a little. Late in the day the sun came out and all of the area grid-tied solar installs drove the line voltage higher. The value I suspected to be the voltage decreased. Inverting the bits and waiting for sunset to drive the voltage lower again, confirmed it. The line voltage is reported in tenths of a volt, 0x09AA -> 2474 -> 247.4 V which is well within 1% of the reading on my volt meter. 59 values to go...

Two, three really, values changed when the pump turned on while I watching the data stream from the control box. The voltage dropped by a few volts and two zero values changed to values of about 0x460. Could it be the real-time current reading? But two of them? Oh, right it is a two-phase, 240V system. Nice, the box monitors...