This phone call had a number I knew all too well, even without the caller ID showing the name… K1 Remote Operations. A this time of night it would be a problem, a serious problem. This particular problem would have me on the road back to the summit an hour later.
Midnight runs to the summit are not common, but they do occur in my life. Usually we can work remotely, the night attendant serving as our remote eyes and hands. Just press the right button, flip the correct switch, done. Not this time. We tried, for over an hour we tried.
I really did not want to head back up. I had just gotten down a few hours ago, having spent the day on the summit working on the usual long list of things that need to get done. Days on the summit, in the thin air of nearly 14,000ft elevation are physically draining.
The irony of this malfunction is that I had seen it before. The dome had tripped out inexplicably on previous occasions. The problem would occur then disappear. Once it vanished you could not troubleshoot it. Unlike most of our other systems there are no logs from the shutter drive, nothing records what was going wrong.
The Friday before this it had happened to me again. But this time was different, I had a maintenance computer attached to the PLC serial port. This time I saw the error, something in the code labeled speed mismatch. No idea what this was, or how it worked. Again the error disappeared, and I could not troubleshoot further as the weather was getting worse. No opening the shutters again.
I needed a chance to figure out what this fault was… Later that day I read through the code, figured out this feature was a speed check to insure that both sides of the shutter are driven evenly. A check to compare the right and left sides of the shutter and to fault if the difference is too large. Two words of memory were compared, if the difference was too large it faulted the shutter drive.
With the Keck Observatory open house approaching I am helping get one of the most popular activities ready. At the last two open houses we have made flasher pins, we will do so again this year.
Flashers? These are a simple circuit built on a PCB that flashes a pair of LED’s. Nothing serious, just a bit of electronics fun. The activity allows folks to learn a little electronics and soldering.
The PCB is configured as a pin or badge, with a brooch pin soldered to the back that also serves as a switch to turn on the LED’s.
The original design came from John Maute at SAO. The circuit is based around the venerable LM555 timer IC configured as an astable multivibrator. The LM555 timing circuit is simple enough to solder together in a few minutes, complex enough to look cool and provide a real introduction to an electronic circuit.
In this ever complex world in which we live the rules are always changing, and usually getting more complex. A modern, information society has many rules that govern who owns what. Copy a photograph from the web and you are probably breaking the laws concerning copyrights. There is a complex and sometimes contradictory set of laws that governs all manner of ownership in this technological age.
Do you know the rules?
Buy a CD with your favorite tunes… Can you copy the tracks onto your phone? Can you create a video with the music and post it to YouTube? What about that expensive photo software package? Can you put it on your laptop and desktop? The rules are often complex, and often the answer is not clear cut.
Increasingly we do not actually own what we buy. At least that is what many corporations will tell us.
You would think that the answer is easier if the thing we are talking about is a physical object. If you buy a car, can you re-paint it, install a new stereo, or ignition system. Of course you can do that. Can you? Sometimes the answer is no.
Increasingly corporations attempt to maintain control of a product after the sale. They use many tools to do this. One is intellectual property, copyrights and copy protection on the software that is now embedded into many of the things we buy.
It does not happen very often, but it does happen. Driving up to the summit in the night to fix the telescope. As an operations engineer it is part of the job, but I can think of only a handful of times in my decade on the summit I have actually done it.
Considering it takes the better part of two hours to get to the summit there is no point in trying unless the issue occurs early. You have to consider the issue… Can you fix it in the middle of the night? Will there be any night left once you fix it? Do you just call the night and head up the next day with a full crew and a good night’s rest to fix it properly?
This particular problem was discovered first thing upon opening. Well? Lack of opening for the night. The top shutter on Keck 2 would not move, fault lights all over the place. Hard to look at the sky with the top shutter closed. I worked the issue over the phone for a while with Nick as far as we could.
The conclusion? I would have to work the problem in person to fix it, I have to go up.
Can I fix this? Probably. I found myself leaving the house before 9pm for a run to the summit.
I was looking at some photos and realizing how much perfboard I have used in recent years. I routinely find myself building small circuits, and that process almost always begins with grabbing a bit of perfboard from the supply stash.
Perfboard is the basis of point-to-point wiring and has been around since well before I started in electronics as a young teenager. It is generally a small circuit board with holes drilled in a 0.1″ grid.
The holes are usually about 0.042″ and will accommodate a wide range of electronic components without modification. Cheap perfboard will have no copper pads or traces, good perfboard will have a pattern of copper traces and pads to which you can solder your components. Better yet is perfboard with plated-thru holes and pads on both sides.
A minor code revision as I slowly get everything working properly. I am adding new modules as I need them for other projects.
The latest GenPIC deployed will be a coolant valve controller that allows remote control of some glycol valves in the AO bench. It is a pretty simple device, just four relays with some automatic timing rules and a serial control interface.
In the process I added support for the service connectors including parallel and simple serial modules to the GenPIC code base, may as well release it. Thus you get code release 0.2…
How do you power a device that must stay on through an event that may cause a power outage? Battery backup of course. But that answer leads to whole new level of complications. There must be a circuit in place to allow power to be drawn from the battery or the power supply. The proper battery technology should be chosen. You need a another circuit to care for the battery, allowing for very long term reliability. Long term? Years.
A good answer for the battery technology is sealed lead-acid. A properly used lead-acid battery should last a decade or more while providing power to operate for over a day. Lead-acid may not be a good choice for a portable device where weight and size are the primary considerations. But for a stationary application this venerable technology is a good choice.
What about the charge circuit? A simple charger that can fully charge the battery, but not overcharge the battery is needed. In the case of lead-acid charging is usually accomplished by charging to a chosen voltage before shutting off or lower the voltage to a safe lower value called a “float charge”.
I have had hardware for a while now, it is about time I release some firmware that actually runs it.
Here it is!
The first GenPIC code revision is a test and demonstration release. It contains support for one serial port, an LCD character display, user input including the encoder and pushbuttons, the indicator LED’s, timer generation, analog input including onboard temperature readout.
Also included is a serial command interpreter implementing a serial interface usable with any serial terminal. There is also a user interface system with a state setup that provides multiple input screens. This should handle a wide array of basic control capabilities, either using the serial port or through using the LCD screen and the encoder.
The code allows you to exercise many of the basic functions of the hardware and provide a framework on which a real application can be built.
It works, it runs, it looks fairly good. Now time to make something useful with it…
I have been messing about with electronic circuitry for almost four decades. I recently came across an early example of my work. The device is a digital event counter built around classic 74xx series logic. A chain of 74190 decade counters feed a set of 7447 decoder drivers and seven segment LED displays. A plastic project case with switches and connectors reminds me I have been building little devices for a very long time.
In some ways the unit is very similar to one of my more recent builds. Perfboard and point-to-point wiring are still standard construction techniques. The technology may have changed across the years, becoming far more complex, but some parts have remained the same.