Monday, May 13, 2019

More power calculations with Woodward's intermittent grasshopper

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

3.9 inches * 25.4 mm/inch / (10 min * 60 s/min) * (1.47 lb * 4.43 N/lb) = 1.08 mW.

Sunday, April 21, 2019

Restoring a pdp-11/45

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.

Monday, February 18, 2019

"Hidden" power losses in Woodward's escapement

I have been thinking about how my implementation of Woodward's intermittent grasshopper is not successfully transferring enough power to run.  The pendulum power requirements I computed earlier are certainly sobering -- even though this clock's pendulum already appears to be substantially more efficient than my other clocks -- they are not the only power loss. 

Since the escapement runs intermittently, I can dramatically increase the power supplied by the escapement by repeatedly triggering the escapement.   In one experiment I tried, the triggering mechanism got jammed, which triggered an impulse every swing.  This was enough to run the mechanism until the pin escape wheel got stuck. 

But even when triggered every swing, the power supplied is only marginally sufficient, even setting aside the pendulum losses.  If I look at the amplitude immediately before and after an impulse, it's not noticeably different.  This indicates that there are substantial additional losses that occur during the triggering and impulse.

What can cause this? The most obvious (though probably not the only) energy losses are caused by the fact that it takes a definite amount of energy (force times distance) from the pendulum to move both the triggering lever and impulse hook.  Since both of these fall back to their original positions after the impulse without returning this energy to the pendulum, all of this energy is lost!  So, the return counterweights should be heavy enough to ensure a reliable positive action, but otherwise as light as possible. 

(I recall now a similar issue with Clock 3, where my initial attempt at a sprung detent resulted in too much energy loss.  Since I couldn't get the wooden spring weak enough without breaking it, I ended up opting for a light counterweight.  It's probably still too heavy, and may account for much of the need for a heavy drive weight.)

Saturday, January 26, 2019

Clock 4 pendulum pivot

In an effort to reduce the pendulum pivot friction for clock 4, I have decided to try setting the pivots on metal points rather than wood.  The points and matching cups are cut from brass.


While a little hard to see, the pins mount in holes drilled in the end of the pendulum's hook-shaped protrusion.  Once mounted, I marked where they sat on the hanger, and drilled holes to receive the cups.  It sounds more complicated than it is; here is a zoom-in of the installation.


In the process of installing the pins, I snapped off the pendulum's hook.  So that is now gluing.  Once it's dry, I'll be able to tell if this helps to reduce the pendulum's running friction.

Update: after drying, for the unloaded pendulum, I get a median of 71 full periods for the amplitude to halve.  That puts the unloaded Q = 320, which is a little bit better than before.

Wooden astrolabe

I have wanted an astrolabe for a long time and decided to make one as a small project.  After reading Chaucer's Treatise on the Astrolabe -- which is still a very clear manual for the instrument's use -- I had the plan fixed in my mind.


The finished product works nicely and looks smart.  I can usually measure the time from the stars or sun to within about 10 minutes, and can measure true north within about 5 degrees or so.

As many sources on the internet point out (correctly!) that the astrolabe is a stereographic projection of the sky onto a plane that is tangent to the earth at one of the poles.  For northern hemisphere astrolabes, such as mine, the plane is tangent to the north pole, and the projection point is the south pole.  That makes the north pole (and the north star) the center of the instrument.  Since stereographic projection turns circles on the earth into circles on the projection plane, nearly everything sketched on the astrolabe is also a circle.  For instance, both the equator and the ecliptic, which is the path that the sun appears to move through the sky, are both circles.  Since the ecliptic is almost concentric with the equator, but twisted off the equator by about 23.5 degrees (the tropics!), the ecliptic looks like an offset circle on the astrolabe.

I could do all these projections by geometric constructions, but decided that merely projecting points was easier.  This I did in python, and to keep organized, I chose to design all of the curves and scales in a Jupyter notebook.  The notebook produces SVG files as output that contain the various curves, stars, and scales, all at a fixed scale for printing.  I edited each of the files by hand to add some more difficult annotations or to make aesthetic adjustments.  For instance, the back of the instrument has an equation of time, to which I added some small glosses for "sun fast" and "sun slow" as well as the build date.


The front of the instrument consists of the rete (a simplified star chart), the tympan (a replaceable model of the sky's azimuth and elevation curves for local latitude), and a scale around the outer edge for time and compass directions.  I used this file as the source of my star chart, from which I produced the rete file.

With the rete file in hand, I manually selected the ten brightest stars, and shaped the pointers.  The idea is that the outer two rings go on the body of the instrument, while the rete, proper, starts at the inner two rings.  The picture below is an earlier revision, with somewhat different scales on the rete.  It also contains both front and back pointers.

This earlier revision uses mean solar time, from which the true position of the sun cannot be read directly.  You need to use the equation of time to make this adjustment.  I found that was too error prone.  I prefer to have the front of the astrolabe show the true position of everything, and then correct for mean solar time afterwards if desired. 

I printed two copies of this file, so that I would have clean copies of each for construction.

You need one tympan for each latitude.  This one is for my local latitude.

This file contains the same outer scales as the rete so that the pages can all be scaled the same.  These outer two scales are cut off and disposed, which is why I left some intersections.  The bright red mark is the location of true north, common to all files.

It wasn't too difficult to arrange the lines of constant azimuth and elevation, though I noticed that there is very little documentation about how the "unequal hours" lines are traced.  After playing with the models a bit, I realized that these lines are the horizon line rotated about the local north direction, not rotated about true north. 

The unequal hours aren't particularly in a modern instrument, but were used for reckoning time in Italy until the introduction of weight-driven clocks.  The idea is that day and night are divided into twelve hours of equal length, starting at sunset.  The hours are therefore of unequal length throughout the year.  During the day, the unequal hours can be read from the position of the sun.  At night, the astrolabe is more useful.  By turning the rete so that the stars are oriented correctly, the position of the sun in one of the unequal hours tells you the time.  At least on my instrument, the sketching the unequal hours seemed to occupy unused space in a pleasing way. 

The instrument was built using my usual paper-on-wood scroll saw technique.  I used 1/8" birch plywood for the flat pieces.  The tympan is merely a laminated sheet of paper, so that it is thin and sturdy.  The two pointers were cut from oak. 

Here is the astrolabe disassembled.


The instrument has a brass pin that holds all the parts on the common center (the north pole).  The back pointer has a cutout that sets the pin into place.


This is important because you simultaneously want one edge of the pointer to align with the center of the mounting hole -- so that you can sight across it and then read an elevation on the scale -- and you want the pin there too.  The pin has to fit back into the pointer to give clearance for the sight line.


The front pointer has a similar construction, but I made a small brass button to keep the pin end.  Once the pin is installed, you merely bend the tip of the pin to retain it.  The marks along the front pointer measure declination -- angular distance from the celestial equator.


Finally, I added a thumb ring that sets through a larger pin.  I turned this with a small flourish, and silver soldered the ring closed.

Monday, January 21, 2019

Two easy projects

Sometimes it's fun just to make simple projects.  Here are two I built this weekend.  A wooden yo-yo


and a sundial for my office.


The sundial is intended to be mounted on the wall, which does not lie in a cardinal direction.  It's therefore what is called "vertical declining" sundial.  My office wall is parallel to 130 degrees, so the gnomon lies off center and the spacing of the hour lines isn't uniform.  I built it according to the description given in

A. Waugh, Sundials: Their Theory and Construction, Dover, 1973.

Hopefully it'll work!

Thursday, January 10, 2019

Clock 4 current power consumption

Continuing the thoughts from the previous post... How much power does the current Clock 4 pendulum and count wheel consume?  Especially, how much weight is really necessary to drive it?

I'll treat the pendulum rod and bob as two separate weights...

Rod = 28.86 oz = 0.818 kg, centered at 24" = 0.61 m
Bob = 26.75 oz = 0.758 kg, centered at 45" = 1.14 m

Potential energy for a swinging weight = m g L (1-cos(angle))

The amount of energy at the top of the test swing (4.8 degrees) is

( 0.818 kg * 0.61 m + 0.758 kg * 1.14 m ) * 9.8 N/kg * ( 1 - cos (4.8 degrees) ) = 0.046850 J

At the bottom of the test swing (2.4 degrees), the energy is

( 0.818 kg * 0.61 m + 0.758 kg * 1.14 m ) * 9.8 N/kg * ( 1 - cos (2.4 degrees) ) = 0.011718 J.

Assuming one period of the pendulum is 2 seconds (it's not, but will eventually be):
  • The unloaded pendulum takes 65 periods to consume that energy = 0.270 mW
  • The pendulum driving the pulling pallet consumes this energy in 54 periods = 0.325 mW
  • The complete count wheel assembly consumes this energy in 50 periods = 0.351 mW
We can conclude that
  • The count wheel assembly consumes 0.081 mW,
  • of which 0.026 mW is due to the backstop.
These power figures are somewhat in line with my previous clocks.  Clock 1 runs on 0.5 mW and Clock 3 runs on 0.8 mW.  So thus far, Clock 3 is more efficient by a bit.

Assume that the escapement is triggered once per minute, is geared through a 10:1 gear mesh, and is driven by a 1" diameter barrel.  How much weight is required for all of these power requirements?

The weight falls at an average speed of pi * 0.0254 m / (36000 s) = 2.216e-6 m/s.

Thus, it takes
  • 12.4 kg = 27.4 lb to drive the unloaded pendulum,
  • 3.7 kg = 8.2 lb to drive the count wheel (without the pendulum), and
  • 16.1 kg = 35.5 lb to drive the pendulum and count wheel assembly.
Way too high, I think!  I need to either improve the pendulum's Q or scrap the idea of the 10:1 gear mesh.

For testing purposes, if I were to drive the clock from the pin escape wheel directly, which has a 3/4" pinion, the weight falls at an average speed of pi * 0.75 in * 0.0254 m/in / (3600 s) = 1.6624e-05 m/s.  The amount of weight necessary to drive the pendulum and count wheel assembly becomes 2.16 kg = 4.8 lb.  (This may not be entirely safe since the pin escape wheel arbor isn't very strong.)