Misadventures with an ESP-01 board (ESP8266 wifi module)

To add wifi capability to an electronics project, the ESP8266 chip is apparently a popular choice.  It is a microcontroller with a wireless ethernet stack built in.  We got three ESP-01 boards that feature this chip, an antenna, and some flash memory (1 MB).  They are very small!

The tutorials on this board are generally quite confusing, as you can incorporate it easily into a project of your choosing in many ways.  Many makers are familiar with the Arduino platform and are comfortable with its development tools, even though this isn't entirely necessary.  Also, there appears to be a tradition of "hello world = flashing LED" tutorials for Arduino.  This tradition extends to ESP-01 boards in a somewhat unfortunate way. 

The ESP-01 board ships with an old-school Hayes-modem "AT" command interface.  It talks to a host via serial at 115200 baud out of the box -- though with 3.3 V signaling instead of 5 V or RS-232 levels.  (Nearly everyone warns you that 5 V will kill the device, but that actually seems a bit suspect.  I imagine RS-232 levels would really toast it, though!)  In any case, if you hook up a serial terminal, you can talk AT commands and pretty easily connect the board to a nearby access point.  The commands are

AT+CWMODE_CUR=3
AT+CWJAP_CUR="<ssid>","<pwd>"

If you want to see what access points are visible, use

AT+CWMODE_CUR=3
AT+CWLAP

If you want to see what IP you've been assigned once connected, use

AT+CIFSR

The documentation for all the commands is located here. a nice short listing of commands is here.  It's essentially like a cross between old-school modem commands and sockets programming.

Since modern computers don't have a hardware serial port (and most old hardware serial ports don't support 115200 baud), you typically use a USB-to-serial converter.  There are many of these available -- I have several -- but for a quick hack you can coerce an Arduino into helping.  Actually, "coerce" is the right word, because what you do is hold the Arduino in a reset state (it's effectively disabled) while you hijack its USB-to-serial chip.  Here's the circuit that I used.  The resistors form a voltage divider that brings the Arduino's 5 V signaling down to 3.3 ish volts.  (It didn't make much of a difference when I hooked the RX lines directly together, though that is apparently ill-advised...) 

Since I am using an Arduino Mega held in reset, it seems that plenty of 3.3 V is available for the ESP-01, contrary to the many tutorials warning that a separate power supply is required.  I imagine you might have problems if you allow the Arduino to boot up.

OK, back to the unfortunate part of the story.  Since the tradition is to make an LED flash as your first project, there are many tutorials explaining how to make an ESP8266 flash an LED.  This involves -- naturally enough -- overwriting the flash memory with a program that simply toggles one of the GPIO pins.  However, this means that the modem firmware gets overwritten!  If you're a newbie (or even if you're not), this means that the ESP-01 board is now useless as a wifi dongle!  Putting the original firmware back is not exactly a trivial task.

I was faced with the task of reflashing 2 of the 3 ESP-01 boards we have.  (The remaining one was fortunately unharmed, so I was able to figure out how it was supposed to work!)

First of all, you need special software that understands how to flash memory on the board with the ESP8266 chip.  Fortunately, the right tool for the job is an open source python script esptool which has minimal dependencies.  Starting this up was no problem, and I started by re-using my existing circuit.  I figured that I would start by clearing the flash memory, since I already knew it to be useless...

$ python esptool.py --port /dev/ttyACM0 erase_flash

Sadly, this just hung while "connecting".  I hooked up my logic analyzer to the TX and RX lines, and was able to verify that data was getting transferred, so it looked like the chip was merely ignoring the commands.  After digging some more, I found that the right course of action was to ground the GPIO0 pin first.  This puts the ESP8266 chip into a "flash mode", which is required for programming it.  To start programming, you briefly pulse the RST pin to ground to reset the chip.  Then it happily started flashing the memory, or so I thought. 

However, as it turns out my board has a flash chip that doesn't like the default SPI settings.  Unfortunately, they appear to work just fine, and the files I flashed even verify correctly through esptool.  But they are wrong!  There are some dark words in Amazon reviews for the ESP-01 about defective boards, but that didn't seem to add up.  The boards were indeed talking -- I could watch the data transfer both directions on my logic analyzer -- so I didn't think they were defective. 

After a bit more poking, I found the solution.  The problem is that the default setting in epstool optimizes runtime, using the fastest protocol to write the flash.  Apparently this isn't supported by all flash chips, and it silently causes problems with some of them.  There's a detailed explanation of what's going on in the esptool documentation and on the Wikipedia page for the Serial Peripheral Interface. 

OK.

Let's flash the board correctly!

You can use the stock firmware, by following detailed instructions about the flash map in their documentation.  But there is also an enhanced version of the firmware that adds a few additional AT commands.  It's a little easier to flash the enhanced version since it's all in one contiguous block starting at address 0x00000 rather than several separate files flashed into different addresses, which is how the stock firmware is distributed.  In any case, the command to do the job is

$ python esptool.py --port /dev/ttyACM0 write_flash 0x00000 AiThinker_ESP8266_DIO_8M_8M_20160615_V1.5.4.bin --flash_mode dout

This set things right, and the boards once again respond to AT commands!

Morse code trainer

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.

Violin sound pin setting tool

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. 

Clock 4 now runs with intermittent impulsing

"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

Laser cut equatorial sundials!

Just for fun, here are two laser cut sundials!

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...

Astrolabe upgrade

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.

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.

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.

"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.)

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.

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!

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.)

Clock 4 pendulum measurements

Here are some measurements of the clock 4 pendulum, trying to get a handle on its performance issues.  Woodward is adamant that limiting count wheel friction was major concern in his designs.  He employed a number of countermeasures, including anti-friction rollers, a polished acrylic count wheel, lightweight stainless steel pallets, and the merest hint of watch oil.  I don't know that my situation calls for such measures, but I figured I ought to investigate.

The pendulum is a solid square black walnut rod about 2" on a side, and is 48" from knife edge to bottom.  It weighs 28.86 oz, which is fairly uniformly distributed along its length.  The pendulum was fitted with a crude bob constructed of short copper-clad steel rods bound together with a rubber band located 45" (on center) from the knife edge, weighing 26.75 oz.

I measured pendulum amplitudes as deflections from equilibrium. 

Provided the amplitude is greater than 2.5" (3 degrees) and less than 5" (6 degrees), the count wheel advances reliably.  The count wheel does not advance at all when the amplitude is less than 2.25" (2.6 degrees). Double counting occurs when the amplitude is greater than 5.5" (6.6 degrees).

Here are counts of pendulum full periods starting at 4" (4.8 degrees) and ending at 2" (2.4 degrees), which is basically a half-time.  Pendulum Q can be estimated from this by Q = 4.532 * number of periods to halve the amplitude.

• Unloaded pendulum: 65, 72, 68.  Median Q = 308
• Pendulum driving pull pallet and count wheel, but no backstop: 58, 54, 54.  Median Q = 245
• Pendulum driving count wheel normally: 52, 45, 50.  Median Q = 226.

This indicates a count wheel-only reliable run time of about 100 seconds, which I've confirmed approximately on previous days.  If you push it a bit, you can sometimes do better on occasion.

There definitely is a noticeable change in loaded Q caused by driving the count wheel, as Woodward warns.  But, the unloaded Q figures are probably the source of my trouble, though.  The unloaded Q is around the same as a marine chronometer's balance (and not a good one at that), and that needs an impulse every period to keep running!  (I already know that the clock can run if it impulses every second.... it's not supposed to do that, though!)

Although this is probably excessive for my needs, Woodward has a table that lists a "heavy seconds pendulum" at Q = 15 000.  I think I need a better resonator!

Triggering the escapement certainly consumes energy, possibly a large amount of energy.  But it's unclear how exactly to measure that accurately...

Clock 4 escapement triggers

The next step of constructing Clock 4 is the intermittent triggering mechanism.  Once per minute (one rotation of the count wheel), it triggers the impulse hook to grab one pin of the pin escape wheel.

The impulse hook was cut from the pendulum rod (mostly for aesthetics).  This version has a brass hook rooted in the block and anchored with super glue.  I later replaced this with a stiffer steel one.

The hook is counterweighted by filling the wooden block with lead.  This was sufficient for the brass hook, but not for the steel hook.  I added a screw and nut outrigger counterweight for that.  The steel hook turned out to be a good idea because the brass one was really very pliant, and was getting distorted by each impulse. 

The hook assembly rides on a brass pin on the pendulum.

The impulse hook is triggered by an assembly that sits behind the count wheel.  The straight segment gets grabbed by the count wheel driving pallet (hook) once a minute, and pushes the flat segment against the impulse hook to engage it.

I also made a wood and brass key to wind the clock.

Here is a video the escapement being triggered successfully from the count wheel.  (Hemostats are useful to keep parts in place...)

This has taken the past two days to get it adjusted.  Here is a video of an amusing -- and vexing -- fail mechanism.  Watch to the end... it gets worse!

Next up: the pendulum is indeed not running long enough (as the previous post probably suggests...).  I suspect I do need to increase the weight of the pendulum bob, regardless of the power needs, and figure out how to reduce the friction.  That first requires finding where the friction is...

Should you add more weight to the pendulum bob when the clock doesn't run?

Short answer: no!

Medium answer: adding more weight to the bob increases the per-period energy requirement of the clock, but only up to a limit.  So once you have the clock running reliably, you can (and should) add more weight to the bob to improve its timekeeping stability.

When clock doesn't run because not enough energy is getting refreshed into the pendulum (or other resonator), it's tempting to look for easy fixes.  Adding more weight to the pendulum bob certainly delays the inevitable, since the clock will run longer before stopping.  But it has a certain futile feel to it... will you ever add enough so that it will never stop?  Sadly, you cannot.  Fixing the frictional losses (best) or increasing the drive power are the only solutions.

The reason is a straightforward derivation ending in a simple formula.

First of all, let the angular deflection of the pendulum be A = A(t), a function of time t.  For small angles, this is governed by

A'' + (c/m) A' + (g/L) A = 0,

where m is the pendulum bob mass, g is the acceleration due to gravity, L is the length of the pendulum, and c is the frictional loss constant.  By the usual process for solving such a differential equation, the envelope of the oscillations will naturally decay like

A(t) = exp( - ct/(2m) ) A(0) ( .. trig functions .. ).

If T is the time of one period, the max amplitude is given by

A(T) = exp( -cT/(2m) ) A(0).

Now switching to discuss energy, the height of the pendulum is found by a little geometry...

... to be given by

h = L(1-cos A(t)).

Therefore, the energy change from one period to the next is

dE = mgL(cos(A(T)) - cos(A(0))) = mgL(cos(exp( -cT/(2m) ) A(0)) - cos(A(0)))

again applying a small angle approximation,

This expression is the one we're after, and really we want to know how it changes as we change m.  Clearly at m = 0, the change in energy is zero. Taylor expanding in m, we have the behavior for large m is approximately

Here is a plot of the overall behavior

The takeaway is that as you increase the mass of the pendulum bob, you must supply more energy to sustain oscillations, but only up to a limit.  For stable, reliable operation, you should ensure that the drive supplies at least that limiting amount of energy first first, before increasing bob weight.  Minimizing frictional losses should be the first priority -- which decreases c -- before trying to increase drive weight.  Only after the clock runs reliably should you attempt to increase the pendulum bob weight.

Clock 4 detent works!

Remaking the detent a few times did the trick.  Each time it worked a little better than the one before, as I flushed out the bugs.  I had a scare where I damaged the gate, but a little super glue seems to be holding it together.  Here is the detent that finally does the job.

The detent properly releases one pin at a time when recoiled by hand with a weight of just about 2.2 lb on the great wheel.

I did not have to modify the pin wheel. It is helpful to have a banking so the detent is held in a convenient position if all the weight is removed.  This also gave a good opportunity for testing the winding mechanism, which does indeed work.