This is a quick weekend project. I wanted something that would send
random strings of characters in Morse code, grouped into sets of 3 or 4
at at time. This little box has a power switch, a speaker, a knob for
volume, and a knob for sending speed. It's powered by a 9v battery, and
is controlled by an Arduino Nano. There's really not much else to it
except for the code.
The sound pin in Zachary's violin was inadvertently knocked over. There's a tool for fixing this problem, and it is not expensive. However, it was also not available on short notice, so I made one.
The tool is a 1/8" steel rod set in a handle of rosewood. To make the tip, I hammered the end of the rod into a spade shape, hardened it, and then ground it to a sharp flat blade. I then bent the rod to fit the shape of the violin, which is a standard 4/4 size. Afterwards, I polished the rod, oiled it slightly, and set it in the handle. The handle was a short segment of a hard rose cane I had taken during pruning, and was shaped on the belt sander.
To use the tool, stab the sharp end into the sound pin (grainwise), carefully thread the pin and tool through the F-hole, and then carefully upright the pin just below the treble foot of the bridge. This took me a few tries, but it wasn't too demanding. Just make sure the bridge is already mostly in place with the strings just barely tightened before you begin, otherwise uprighting the bridge will surely topple the sound pin.
"Intermittent" can be a problem, but not in this case! Based on the numerous power budget calculations I've done, impulsing the pendulum in Clock 4 every minute is too much to ask. After having gotten the escapement to impulse every period (2 seconds) reliably, with run times around 8 hours, it seemed like the right time to go back to trying to get the intermittent part working again. Especially, the run times without intermittent escaping were limited by drive cord length -- I had a four fall pulley in place for the clock to run that long.
Therefore, I added more deep cuts to the count wheel, now five in total.
This means that the escapement should be triggered every 30/5 = 6 pendulum periods, or every 12 seconds. The pin wheel has 30 pins, so will then have a period of 12 seconds * 30 = 360 seconds = 6 minutes. The pin wheel is driven through a 1:10 mesh for the drive wheel, so it should make a rotation every hour. I can therefore drive the minute hand from the drive wheel, although it will run counter clockwise.
With some tuning, the Clock 4 runs with 8 lb of drive weight, directly driving a barrel of 1.2 inches. The clock's run isn't perfect, as (1) the count wheel double counts immediately following an impulse and (2) sometimes this double-counting skips over an impulse.
But given these issues, Theodore measures the following periods in current configuration:
53 seconds for the count wheel
4 minutes 24 seconds for pin wheel
Given these measurements the drive barrel will make one rotation about every 44 minutes. In that time, the weight will have dropped 3.7 inches.
Thus the power consumed is:
3.7 inches / (12 in/ft) * 8 lb / (44 min * (60 s/min)) = 9.4 * 10^(-4) ft lb / s = 1.28 mW
They are made from the 20190612_equatorial.svg file in my github repo. You can't see the shadow of the gnomon on the clear one, but you can totally see it projected (correctly) on the ground! The etching on the white background didn't show up initially, so I set some ink onto. It's nothing fancy; I just smeared black whiteboard marker ink over the face of the dial, and then wiped off the excess ink with my hand. It's not waterproof...
American University's Design and Build Lab got a new laser cutter. Since the astrolabe I made before was drawn as a set of SVG files, I figured that it might be nice to make another astrolabe on the laser cutter. Indeed, the result is beautiful!
This astrolabe is cut from 1/4" black acrylic with a 1/8" clear acrylic rete (star chart). I etched the rete on the back of the clear acrylic, so there is no visible parallax error. The pointer is 3d printed PLA. The brass hardware was hand turned on my lathe. All of the hardware is friction fit with no adhesive used. This astrolabe is for a fixed latitude (39 degrees North), so the center pin is (essentially) permanent. The movement is smooth, but tight. This is a nice improvement over my previous astrolabe, in which the hole in the rete has enlarged over time.
Unfortunately, we had trouble aligning the back. The horizontal
alignment is perfect, but it's vertically shifted by about 2 mm. This
means that the elevation scale runs off the top of the astrolabe. None
of the back scales are very useful as a result, even though it is still
attractive. I think the cause of the vertical shift was an alignment
key (which doubles as the ring attachment point) that we added to the
front layer, but not the back layer. We attempted to compensate for
this difference, but evidently failed. However, the compass scale on
the front can still be used for elevation
sighting, although this requires subtracting 90 degrees from the reading
to obtain elevation.
By joining the count wheel pusher lever of the the Woodward escapement to the escapement trigger, you can make the escapement trigger once per period. This is the most frequent that the intermittent grasshopper can be triggered. Triggering every period already happened by accident, but I decided to force it to occur by linking the mechanisms together without using the count wheel. This way, I could debug the escapement mechanism... and there were indeed problems there. I think I've resolved them, and this modified mechanism reliably runs until the weight hits the floor.
Currently, the mechanism runs on 1 lb 14 oz, falling 3.9 inches every 10 minutes. Converting to standard units, this means that the weight falls
3.9 inches * 25.4 mm/inch / (10 min * 60 s/min) = 0.17 mm/s
1 lb 14 oz = 0.85 kg = 8.3 N
Thus the power consumption is 0.17 mm/s * 8.3 N = 1.37 mW.
This is substantially more pessimistic than my previous figure of 0.325 mW averaged over one minute for the count wheel assembly. This is even with an improvement resulting from a few changes I made. The pendulum is now hung from two sharp brass points resting in brass cups.
This new hanger ensures a positive positional lock and a definite axis of rotation for the pendulum with substantially less friction than before.
I also made a number of small improvements including reshaping one of the pin
wheel pinion teeth, aligning the impulse hook, and stopping the
detent's fall a bit earlier. Finally, I removed every other pin in the pin wheel, which means that the period of the pin wheel is one minute.
Update: 5/13/2019.
By clipping off the tail of the locking detent to make it somewhat more delicately balanced, I can reduce the drive weight by 6.5 oz. Thus, the power consumption is
When I was a student at RPI, I found a pdp-11/45 on the JEC loading dock. The machine had no power supply and had a destroyed memory management board (M8108). I cobbled together a power supply and replaced the board, and it was running well enough to flash its lights.
That was about eleven years ago -- the little boy in the video above is turning 13 tomorrow -- and the machine stopped working shortly after the video was taken.
This month I started investigating the cause of the trouble. I found that the +5V power was sagging severely when the machine was powered, which isn't terribly surprising because the CPU alone draws something like 40A! Evidently the industrial power supply I had purchased wasn't doing its job. Unfortunately, what used to be a $50 power supply was now upwards of $400, since the manufacturer had closed. A little looking around, I decided to replace the +5V only at 50A.
The resulting power supply got the machine to start up, but it was very erratic. It would crash at various weird places, and for no particular good reason. This had me going for a long while, but fortunately the machine was made to be debugged... you can select from two internal clocks: a crystal (the default) and an RC oscillator. You can adjust the frequency of the RC oscillator, but it's not very stable. You can also wire in a single-step switch, which I had done in the past. None of this seemed to help, but I learned that my frequency counter is pretty stable in the process.
Accidentally, I found that the machine would crash when I bumped the power supply wiring harness.... and found that the screws that connected the harness to the power supply were loose.
Tightening the screws fixed that problem!
But there were more problems. Several of them were easily resolved by polishing all of the card edge contacts. This is not hard, but takes some doing.
This got the machine to the point where it had been before it stopped working. It could load my custom, simple OS, EMON, and run programs entered from the console.
But I had previously wanted to load other software, could I do that now? Since I do not have any peripherals aside from serial lines, using a emulated TU58 tape drive seemed the best option. Since I last checked about a decade ago, tu58fs has been written, and seems to be the most convenient. So I tried to get XXDP and RT11 running, but both failed.
XXDP in particular was stopping at address 000550, this seemed to be similar to what was described here. Using the disassembly provided there, I agreed that this was a checksum error. But since the tape file booted on SIMH, I knew I had a good image.
By manually digging through what the boot loader had loaded into the pdp-11's memory, I verified that everything was perfectly loaded. The checksum was being computed incorrectly! I wrote a simple program to compute the checksum of that good block... and the checksum came back wrong. After simulating the code carefully in python, I determined that the cause was that the carry bit was getting set way too often. The carry was set whenever it should be, but also whenever the highest bit of the destination register was set.
I traced this back to the output of one multiplexer chip. It was being held low when it shouldn't be, but only about 0.9V... an uncertain level. Fearing the worst, I replaced the chip.
I socketed the replacement just in case I had to replace it again. This is perhaps unnecessary, and it might cause issues if I ever get a floating point unit. But since this board is the frontmost large board, it's not a problem.
Sadly, this didn't do the job... the carry still was getting set incorrectly. Tracing forward, it turned out that the destination register's highest bit has a special active LOW line that runs on a trace parallel to the carry bit. A tiny bit of solder had bridged those two lines at the following chip.
Evidently, this chip had been replaced previously -- not by me -- and the job was not done carefully. Cleaning up the solder job and removing the bridge fixed the carry problem.
The machine now boots XXDP!
But, as the screenshot shows, there are still problems... I originally had 32 kW of memory loaded, for a total of 28 kW available for programs. (The top 4kW is always reserved for memory mapped I/O.) I have verified that all of this memory can be accessed and used without issue. Although the memory management unit is not needed to access 28 kW of memory, apparently XXDP prefers to have it available. The memory management unit (embodied in the M8107 and M8108 boards) is actually installed, but it is evidently not working correctly.
In order to get XXDP to boot, I had to pull the top 16 kW out, which is the four cards above that are obviously displaced. (The memory lives in a separate cabinet above the CPU because I had trouble finding a sufficiently powerful power supply for it. Since it takes unusual voltages, I didn't fancy building an appropriate power supply from scratch.)
Here's a video of the entire boot process, in which I key in the boot loader using the front panel.
