I have written an article about International Time Recording (ITR) and International Business Machines (IBM) impulse secondary movements, including building your own master clock to control them. The article is in PDF format and because of it's size (37 MB) and NAWCC's file size limits, this PDF file can only be read or downloaded from the github.com site link below. To download a specific file, click on the file name and then click on the “Download” button on the following page. Please note if downloading a large file is a problem, the PDF file can be read from the github site. Included in this PDF are many photos, schematics, and tables. Here is the first two pages of the article without photos and this is the link to the Github.com downloadable files:
Electronic Build Project:
“A Computer Based Master for ITR & IBM
Minute Impulse Secondary Clock Movements”
By Joe Fox, KD4MS
I have seen many requests from people on various forums, asking for information on how to get an old IBM slave clock working. This article may help some of you. Movements, like the one in Photo 1, are often referenced as International Time Recording (ITR) or International Business Machine (IBM) slave clocks but this is a misnomer. The correct name for these movements is “Secondary Movement”. IBM minute impulse secondary movements, along with time and attendance recorders, time stamps, event programmers, buzzers, bells, and other time recording devices were used for decades in many schools, factories, and businesses for coordinating time and attendance.
This article describes how IBM's time control system works and discusses three different versions of a computerized equivalent master clock. A master is needed to accurately operate one or a hundred IBM minute impulse self-regulating secondary movements as timepieces. The electronic masters detailed here control three-wire self-correcting minute impulse secondaries (notice no second hand).
So if you are lacking a functional master, build one of the versions of this project and get your IBM impulse secondary working accurately and electronically without ruining your pocket book.
There are three choices of electronic processors offered here; each with different complexity's and costs.
1- An Arduino Uno or Mega, plus an Ethernet shield, including their open-source clones,
2- An ESP8266-12E NodeMCU wireless IoT network processor (the cheapest @$6.50),
3- A Raspberry Pie Zero W(ireless networked) computer. (as low as $5.00 plus memory)
Each version uses a pair of Insulated-Gate MOSFET devices to drive the impulse secondary's coil, and each includes their own version of software [in downloadable files]. The first two processors are programmed using Arduino's free Integrated Development Environment (IDE) software, and the third uses master clock software ported to Linux and executed at boot time...
All three versions of the computerized master clock are programmed to output two signals to their General Purpose Input Output (GPIO) data pins. This configuration uses the same logic as the wiring of the relay technology wiring design as shown in the 1938 IBM schematic (See Schematic 1).
Starting at the top of the hour, an A and B pulse is presented, for a duration of 0.4 seconds ON, then OFF, once each minute, with the following exceptions:
Secondaries that are late (slow) [due to mechanical or electrical failure] will receive the A pulse once per minute until the Master is at the 59th minute, then receive up to 21 rapid A pulses every other second, until late secondaries reach their 59th minute. After the 59th minute, the secondaries will switch from their Normally Closed (N/C) “A” contact to their Normally Open (N/O) “B” contact, and will only advance to the top of the hour on the next B pulse. Most secondaries will switch back to the “A” contact at four minutes after the hour, depending on the model of the secondary.
- The A signal is raised once per minute at zero-seconds, and on every odd second between 10 and 50 during the 59th minute. Therefore the A line will get an extra 21 pulses during the 59th minute, totaling 80 pulses per hour.
- The B signal is raised once per minute at zero-seconds for each minute except for minutes 50 to 59, where the B signal is stopped. Therefore the B pulse only occurs 50 times per hour.
Secondaries that are early (fast) [due to mechanical or electrical failure] will receive the A pulse once per minute until their 59th minute. Then they switch from their N/C “A” contact to their N/O “B” contact, and will ignore the A pulses while waiting for the next B pulse, before advancing.
The next B pulse will step all the secondaries forward from their 59th minute to the top of the hour and will continue to advance the secondaries with the B pulse until the secondaries switch their cam operated contacts back to the N/C “A” contact.
There are some early model secondaries that switch back to the B contact at 14 minutes past the hour and these are compatible with this master clock scheme since the B signal continues until 50 minutes after the hour. If a late secondary is more than 20 minutes late, but less than 50 minutes late, then correction will continue to the next hour's synchronization cycle. The service manual says, severely out of time secondaries could take up to three hours to become synchronized. Movements with more than a few minutes early or late without reason are considered in need of repair...
...NTP Time Request:
To keep the master accurate and on time, an Ethernet shield accesses the Wide Area Network (WAN) with an Network Time Protocol (NTP) time source request from the official U.S. government's time
keepers, the National Institutes of Standards and Technology (NIST). Their Internet Time Server is calibrated by an atomic Cesium fountain clock, and is a very accurate and reliable clock time base
choice for the Arduino based master. For the Arduino and NodeMCU versions, correct time is acquired from the NTP time servers at boot time and once per hour to update the Arduino's and ESP8266-12E NodeMCU's system timer (system clock). I am not sure when and how often the Rpi requests it's Network Time Protocol (NTP) time update as I believe it is coded into the Linux Operating System.The NTP time request is necessary because the ESP8266-12E NodeMCU and the Arduino model's on- board system clocks (crystal or ceramic resonator oscillator circuits) are not accurate enough to be a clock time base, not even close. For comparison, the IBM mechanical master clock, with its low expansion coefficient Invar Steel pendulum rod and temperature compensating mercury pendulum weight, like mine, had a guaranteed accuracy of ten (10) seconds per month, and that's back in the 1930s. My Arduino's system timers gain or lose about a half second per hour with current code [worst case] totaling up to about 360 seconds per month; that's 6 minutes! As you can see an external time base source is required. So, looking for an accurate time source, I considered the GPS module, Temperature controlled crystal oscillators, real time clocks (RTC), WWV (radio) modules, and an Internet Time Server as possible sources, I chose the cheapest and most maintenance free over time, the time server.
These computerized master clocks using the NTP time source will never be off more than one or two seconds, regardless of temperature, voltage, crystal aging, etc., either tomorrow or ten years
from now. The NTP time server request will correct any error in the processors timer at 58 minutes past the hour, for ever and ever. The Arduino's on board system timer (clock) is still used, but its timer is corrected every hour by the NTP time request, two minutes before synchronizing all the clock movements at the top of each hour. Bear in mind the impulse secondary has a resolution of one minute,
not one second. Only the master clock has a resolution of one second. The impulse secondary will only be on time for one second, then will become up to 59 seconds slow until it is brought forward at the next impulse, at zero seconds of the next minute.
There is useful information at the National Institutes of Standards and Technology (NIST) at :NIST Internet Time Service . Be sure to heed their warning that:
“All users should ensure that their software NEVER queries a server more frequently than once
every 4 seconds. Systems that exceed this rate will be refused service...”
See also: NIST Internet time service (This is the NTP description page and it is a different page at NIST.gov.)