UMBRAPHILE© 2.3.1
 |
 |
UMBRAPHILE is free, courtesy of sofTouch
APpLications and Glenn
Schneider. You'll have to build the camera interface yourself,
but that is actually very easy. You should be able to do it in an evening
or two for about $35 or less.
VERSION 2.3.1 - Updated (4/17/2001) Release for 21 June 2001 Eclipse
Download UMBRAPHILE 2.3.1 for 68K Macintosh (494 Kbytes)
Download UMBRAPHILE 2.3.1 for PowerPC Macintosh (473 Kbytes)
Download UMBRAPHILE Documentation* (793 Kbytes)
Download UMBRAPHILE 2.3.1 Data File for 21 June 2001 Total Solar Eclipse (2K bytes)
Download UMBRAPHILE 2.3.1 Source Code (APL Level II for Macintosh 3.10e) as PostScript (547K bytes)
* Downloadable documentation (and that bundled with the S/W) may lag
up-to-the-minute "breaking" updates. Please consult the UMBRAPHILE
web site for the latest informatiopn and news.
Note: If your Web viewer does not automatically convert the above document(s), save as TEXT and convert from BinHex 4.0
(You can skip all this stuff, but fellow umbraphiles may relate to this).I am an umbraphile. Literally a "shadow lover", but properly applied, one who is addicted to the glory and majesty of total solar eclipses. Those who have basked in the moon's shadow will know what I mean without further explanation. Those who have not may have difficulty in understanding that umbraphillia is not only an addiction, but an affliction, and a way of life. The real raison d' etre for many of us. The more common and prolific term "solar eclipse chaser" is nearly synonymous, but somehow does not convey the depth of commitment to this lifelong endeavor.
Once every 16 months, or so, (on average) umbraphiles will drop whatever they are doing and trek by plain, ship, train, foot, and camel-back to gather along a narrow strip in some remote corner of the globe defined by the inexorable laws of celestial mechanics. Newtonian physics heeds no national boundaries, and neither do umbraphiles. Wherever the solar photosphere will be extincted, enshrouded by the ashen lunar disk, umbraphiles will revel in the quasi-twilight darkness. Many, including myself, will have lugged all sorts of ancillary accouterments along in an attempt to capture a bit of the magic reveled during those fleeting few seconds to review, replay, and later share with the unenlightened. Telescope, binoculars, cameras (still, movie, and video) are the non-living familiars of eclipse chasers and umbraphiles. Yet, the necessity of "working" during an eclipse demeans the moment. Every nanosecond should be enjoyed. Operating equipment detracts from the event and lessens our ability to be fully immersed in the phenomena of totality.
This was brought home to me in a series of conversations I had with a fellow umbraphile, Robert Slobins (who eclipse photos can be enjoyed in several issue of Sky and Telescope and Astronomy magazines). While returning from Banka Island, Indonesia (where I had observed my fourteenth solar eclipse) Bob implanted the idea of using a portable computer - with a relatively intelligent and "user friendly" front-end as a camera controller. The idea was not new, I had first seen something similar implemented by George Keene, using discrete electronics, in the late 1960's/early 1970's. But the concept was evolving in my head to design something that ANY eclipse chaser could easily use, even those who normally shy away from building hardware or writing software.
As a result, ROSE was born. ROSE was the "Reprogrammable Observer for Solar Eclipses". ROSE was a prototype and fell far short of the ultimate vision. For those who are interested ROSE was built around a Rockwell AIM-65 single board computer utilizing a 1-MHz 8-bit 6502 processor (the same which powered the now dust-collecting Apple II's of the world's closets), with 4K of on-board RAM and a 20-character alpha-numeric LED display. I think you can now find one somewhere in the basement of the Smithsonian. (I had previously used them in instrument controllers and data acquisition systems I had built for a variety of ground based astronomical instruments and space mission ground support equipment, so it made a logical platform for a starting point). ROSE required entering observation/exposure "sequence tables", either from the keyboard or "downloaded" from a pre-recorded data-tape on an audio tape recorder through a TTY interface at 300-baud. (For those of you who are under 20, I'm not making this up, this really is the way we used to do things).
Before leaving for the 1991 eclipse in Mexico I had computed circumstance for several dozen potential observing sites in Baja on a "real" computer, formatted these as needed by ROSE, and transferred them to the flip side of an audio cassette which contained the Beatles "Here Comes the Sun". I had hoped to end up at one of these sites and just plug in the sequence table (which contained U.T of exposure, and exposure time). I ended up, of course, banging in a new table by hand, from a previously unconsidered (but wonderful) site.
ROSE was packaged in an old Sampsonite attaché case, with sealed lead acid batteries, interface boards, and a series of ugly toggle switches and J-connectors on the sides. It was bungy corded closed, as the case latches were broken. To this day I'm amazed and amused that on my way to Mexico airport security at LAX passed ROSE through the X-Ray inspection with no questions asked while the woman behind me with a Compaq 386 portable was asked to turn it on and boot it up. The bottom line, however, is that as controller ROSE worked superbly. It permitted me to kick back in the Mexican sand and enjoy the July 11, 1991 eclipse from the east coast of Baja California for an uninterrupted 6 minute and 54 seconds and WATCH the longest eclipse for the remainder of my lifetime and still come with beautiful pictures of the event. The only unanticipated problem I had was overheating of the CPU in the 110-degree F dessert sand. A local resident kindly lent me an electric fan and a place to plug in a 250-foot extension cord (which I just happened to carry in my "contingency" package), to keep the CPU from flipping out.
Primed by ROSE's success I was ready to metamorphisize it into something that OTHER people could use, and thus was the genesis of UMBRAPHILE. The development of UMBRAPHILE, however, laid dormant for a while. The total eclipse of June, 1992 was visible from land, only at sunrise from the East coast of Uruguay and small portions of southern Brazil. The weather prospects, with the sun hanging on the horizon, were awful. For this reason I had elected to observe this eclipse by air and had the opportunity and good fortune to navigate a DC-10 into the path of totality for 6 minutes and 15 seconds. This tied up my PowerBook (a 170 at the time), as I had to develop special S/W for this job (but that's another story). For me this was primarily a visual event. The ECLIPSE FLIGHT S/W, designed to optimize the intercept profile of such a flight by providing closed-loop control to a aircraft's navigation system, may see the light of eclipsed-day once again at a future epoch (2003 over the Antarctic, anyone?).
UMBRAPHILE made it's full debut for the October, 1995 eclipse in Ghanoli, India (near Fatipur Sekri, but just north of dynamical centerline). ROSE would not have recognized it. UMBRAPHILE was mean, clean, eclipse machine. A stand-alone program running on a Macintosh PowerBook 520c. To run one or more cameras with an optimized exposure sequence all that was required was plugging a small black box into the AppleTalk port on one side, and camera electro-mechanical interface on the other, entering in the site coordinates and waiting for the moon's shadow. UMBRAPHILE has since been "packaged" with a user-friendly, simple, GUI interface. Both 68K and PowerPC version are available (sorry, no "fat" binaries - I don't believe in taking up space on other people's machines with non- executable code). You can have it, free, it's yours to try and use. If you have suggestions, comments, or criticisms, I'll be more than happy to listen. We've got more than enough time before the 2001 eclipse to make worthwhile changes to UMBRAPHILE.
First, UMBRAPHILE computes circumstances for solar eclipses based upon polynomial representations of Besselian elements and ancillary data read in from a FITS-like header file through a standard Macintosh file requester dialog. These data are in the form which are published in the USNO Astronomical Almanac, and NASA's Reference Publications on Solar Eclipses (Espenak) . The latter of these is now available electronically through Fred Espenak's incomparable and invaluable eclipse web server. A sample file, USNO style, is distributed with the UMBRAPHILE software. This INPUT file must be a plain vanilla ASCII TEXT file (eg., you can create it, using SimpleText, or your favorite word or text processor, but don't expect UMBRAPHILE to read PostScript or PDF). Here is what the content of the first part of an UMBRAPHILE input file look's like:
; UMBRAPHILE DATA FILE FOR 21 JUNE 2001 TOTAL SOLAR ECLIPSE ; FOR UMBRAPHILE 2.3.1 (OK for earlier versions ; *MUST* use this file for 2.3.0+) ; For an explanation see: http://balder.prohosting.com/stouch/ ; SOURCE = 'USNOAA' ; Must be 'USNOAA' or 'NASARP' DTYPE = 'TRIG' ; Must be 'TRIG' or 'DIRECT' ; ; PARAMETERS FOR COMPUTING BESSELIAN ELEMENTS - USNO STYLE ; Range = 0.458, 5.742 ; Range in TDT for valid coefficients T0 = 9 ; Base time for series expansion DELTAT = 0.0 ; Delta-T in seconds (0 if U.T. elements*) XCOEF = -1.67464697, 0.56497566 0.00010850, -0.00000887 YCOEF = -0.73741552, 0.05589798, -0.00012510, -0.00000099 SINDCOEF = 0.39779267, -0.00000237, -0.00000009, 0.00000000 COSDCOEF = 0.91747532, 0.00000099, 0.00000007, 0.00000000 ; DCOEF = 0.00000000, 0.00000000, 0.00000000, 0.00000000 MUCOEF = 314.56178906, 14.99919333, 0.00000030, 0.00000001, -0.00417807 l1COEF = 0.53716846, -0.00002234, -0.00001204, -0.00000001 l2COEF = -0.00917111, -0.00002217, -0.00001199, -0.00000000 tanf1 = 0.004601 ; Umbral Shadow tanf2 = 0.004578 ; Penumbral Shadow SD = 23, 26, 18.2 ; Solar Declination at Mid-Eclipse MUP = 0.261785 ; Time derivative of MU in radians/hour ; ; * Note: Delta-T = +65.0 seconds is "built-in" to these polynomial ; representations of the Besselian elements. For a different value ; of absolute Delta-T set DELTAT = Delta-T minus 65.0.Use the provided sample file as a template. The SOURCE indicates if the data have been obtained from the U.S. Naval Observatory's Astronomical Almanac, or a NASA Reference Publication. DTYPE specifies if the polynomial coefficients for parameter "D" will be given as trigonometric arguments in two series (SINDCOEF and COSDCOEF), or as direct arguments in one series (DCOEF). In the section headed "PARAMETERS FOR COMPUTING BESSELIAN ELEMENTS" put in the values of the listed parameters for the eclipse of interest and save the file. (In early versions of UMBRAPHILE this was entered via a very busy dialog in the program. Other folks testing UMBRAPHILE convinced me that reading an input TEXT file would be easier.) Don't worry if you don't know what all these data represent, UMBRAPHILE will figure it out.
0. Starting up UMBRAPHILE
Just double click the UMBRAPHILE icon.
You can compute the centerline circumstances for any total or annular solar eclipse over a specified time period at a specified interval. To do this select "CENTERLINE" from the UMBRAPHILE menu. You'll see a very simple dialog asking you to enter the start time, end time and increment for the tabulation of centerline circumstances. If you had not previously read in an UMBRAPHILE input data file you will be asked to do so at this point. To read in a data file, just check the Read Data File option, and a standard file requester dialog will be presented. Then locate and open an UMBRAPHILE input data file, such as ECLIPSE-21JUN2001_231.DATA, which is currently distributed with the software. If you want to read in a new data file (having previously read in a different one) , leave this box checked. If you are re-running a new set of circumstances for a different time frame, you don't have to re-read the data file and can deselect that option.
Try this, first using the default values in the dialog. When asked, point to a sample input data file distributed with UMBRAPHILE. A new scrollable window will pop up titled "Centerline Circumstance", which will be similar in format (though the values ill be different for other times and eclipses) to that shown below. Of cours, you can change the start, stop, and time increment criteria as you please.
The first line in the window echoes back the name of the input file. The columns are defined as follows:
HH MM SS indicates the Universal Time corresponding to the tabulated values of the associated circumstances. Note: UMBRAPHILE assumes that the polynomial coefficients supplied through the input file are for series representations in Universal Time (i.e., a delta-T correction has already been applied to Terrestrial Dynamical Time [TDT], Ephemeris Time [ET], or International Atomic Time [IAT]). Both the USNO and NASA provide data in this form. LONGITUDE Give the topocentric location of the center of the moon's shadow LATITUDE for the corresponding instant of Universal Time. These coordinates are based on a geocentric reference frame defined by the 1927 NAD. If a different reference datum is desired than subsequent transformations must be applied when high precision is required. Please note this if transferring these data to maps produced outside of the U.S. on scales, typically, smaller than 25,000:1. These coordinates are for Mean Sea Level. Corrections for elevations above (or below) MSL are applied when computing local circumstances for individual sites. Geographic coordinates are tabulated in both decimal form and as degrees, minutes and seconds. Note: Longitudes East of the Greenwich Meridian are positive. DUR s Gives the duration of totality, in seconds. Note: The duration is defined by a "smooth" lunar limb. Corrections are not applied due to the selenographic structure of the moon's limb for the topocentic libration. Such corrections can be on the order of seconds. This is discussed further in the section of this document describing the UMBRAPHILE Camera Controller with regard to the "diamond ring" sequence of exposures. W km Gives the width of the projected shadow ellipse, in kilometers ALTd Gives the altitude of the sun above the local horizon, in degrees ECCENT Gives the eccentricity of the projected shadow ellipse t Indicates the "type" of eclipse; T = total, A = annular
2. Centerline Contacts
You can also compuet the contact times for locations on the centerline of the path of totality as a function of the instant of mid-eclipse. To do this select "Centerline Contacts" from the UMBRAPHILE menu, and put in the starting and ending time, and increment desired in HHMMSS.f format. You will also have an option to select (or reselect) in UMBRAPHILE input data file. When you click OK, a new CENTERLINE CIRCUMSTANCES window will pop-up similar to the one shown below:
The Centerline Contacts window, like the Centeline Circumstances window is scrollable. The Univeral Times of maximum eclipse, as well as 1st, snd. 3rd, and 4th contacts, as well as the solar altitude for the corresponding centerline locations of each of the contacts, is displayed.
To compute the specific circumstances of the eclipse for a particular geographic location, select LOCAL CIRCUMSTANCES, from the UMBRAPHILE menu. A LOCAL CIRCUMSTANCES input dialog dialog will be presented asking you to enter the latitude, longitude, and altitude (in meters) of the site of interest. Use the format shown in the dialog (just replace the values in the corresponding boxes). Note that UMBRAPHILE uses the topocentric convention where longitued East of the Greenwich meridian are positive. The name you supply, for reference, will be used in the local circumstances output window. When computing Local Circumstances you may, optionally, apply limb profile corrections for second and third contact. If you wish to do this, the values of CIIOFF and CIIIOFF in the UMBRAPHILE data file will be applied if you check "Apply Limb Corrections" (see DIAMOND RING/CONTACT II+III PARAMETERS for more information).
If you had not previously read in an UMBRAPHILE input data file you will be asked to do so now. If you wish to read a new input data file, or re-read the one you used previously check the "Read Data file" box. If you leave the box unchecked, and have read in the values from an input data file previously, they will be used again. When you click OK, after pointing to an UMBRAPHILE input data file if needed, a new output window, whose name is that of the site, will pop up giving you the local circumstances of the eclipse for the site specified. Note that the central instant of mid-eclipse (if in the path of totality/annularity) will be reported as either "MID" or "MAX" depending upon whether limb corrections have been applied.
The latitude, longitude, and altitude of the site, provided in the LOCAL CIRCUMSTANCES input dialog, will be echoed back. The durations of the penumbral phase (first contact to last contact), and the umbral phase (second contact to third contact) of the eclipse is given in hours, minutes, and seconds. These durations, and those tabulated for the centerline circumstances, assume a smooth lunar limb. The Maximum Magnitude is one of several ways to express how much of the Sun's disk is covered when the eclipse is maximum for a particular topocentric location. This is defined succinctly by J. Meeuse in his "Cannon of Solar Eclipses" as folows: The Maximum Magnitude of the eclipse, M, "is measured along the line joining the centers of the two disks. In all cases, M is the ratio of two quantities. In the numerator of the fraction, one finds the value of the straight line segment passing through the centers of the two disks and having the Sun's limb that is nearest the Moon's center, and the Moon's limb that is nearest to the Sun's center, at its endpoints. In the denominator appears the value of the diameter of the Sun". Note that this is NOT the same metric as the "Ratio of Semi-diameters", or the "Obscuration" (by area), and should not be confused with either which are sometimes used elsewhere. For each contact which is visible from that site the Universal Time of the contact, and the altitude of the sun at the time of that contact (in degrees), is tabulated.
4. Circumstances for Local Noon
The local circumstances of the eclipse for the location on the Earth where mid-eclipse occurs at local noon may be computed by using the LOCAL NOON item in the UMBRAPHILE menu. This will usually be very close to (but not exactly) the point of maximum eclipse. When you select this, the geographic coordinates of that site will be determined and entered into the Local circumstances dialog which will be displayed. Then click OK (adjusting the altitude above MSL if desired), and the information described in the previous section (2. Local Circumstance) will be displayed. Note: For eclipses in the polar regions, this point may actually correspond to local midnight, if the moon's shadow is projected onto the Earth "over" the pole. There is not a separate menu item for this, but "local noon" actually has this meaning in that context.
UMBRAPHILE will run on ANY computer running a Macintosh operating system of version 6.0.X or later, though I'm only supporting System 7 and later. It has been tested up through MacOS 9.0.4 on a variety of platforms. If anyone discovers any as-of-yet unknown problems under older Mac OS releases I will try to address them as time permits. UMBRAPHILE will run non-Macintosh-like machines (i.e. non 68K or 60x PPC processors) running MAE (such as a Sun SparcStation), though your on your own on figuring out the serial hardware interface. UMBRAPHILE does not need much horsepower to run. In fact, it runs happily on the original first-generation series 100 Powerbooks. If you don't have a PowerBook, and want to revel in hands-free eclipse-watching rather than being a slave to your camera(s), you might consider purchasing an older PowerBook on the secondary market. Apple made lots of these, and there are many used/surplus vendors who have them going in and out of their inventory. My personal favorite for this purpose is the Model 170. UMBRAPHILE itself needs less than a megabyte of free memory to run, so even if you have an minimal machine with 4 Mb of RAM you should do fine. That's running pretty slim for all the newer MacOS's, but manageable with a trimmed MaOS 7.x. A used machine in good condition with 8 Mb of RAM, 80 Mb hard drive, battery, and a modem (typically 14,4 kbps for that vintage - not required but many have them) shouldn't cost more than about $100, or maybe less if you find a good deal. Though not an endorsement, you might want to check the Powerbook 100 series listings with eBay, I have found some good deals there myself.
What About G4 Macs?
I haven't worried too much about G4 machines, since G4 laptops
do not yet exist. However, the PPC version of UMBRAPHILE runs just
fine on G4 desktop machines. The USB interface both for G4 machines
and newer G3 laptops is another matter... For the new G4 machines
with a USB buss, rather than serial port, select "Serial port #1".
(It has been reported that selecting serial port 2 will cause the program
to hang up).
What About USB Macs?
UMBRAPHILE was designed to allow H/W control interface through
a serial (appletalk) port. By doing this the serial port is dedicated to
"talking to" a single device, i.e., an UMBRAPHILE camera interface.
The Universal Serial Buss, which
is replacing the Appletalk serial port(s) in new machines is designed to
communicate with multiple devices simultaneously, and hence is an interface
paradigm shift. In principle, UMBRAPHILE could be made to work with
a USB machine. In practice, I simply have not had the time to do
any experimenting along these lines, nor do I expect I will have time to
do so before the next eclipse. I therefore beg your indulgence in
this regard. If any UMBRAPHILE users wish to experiment with USB
computability and find an expedient route to make this work PLEASE
let me know so I can pass it along!
What About the Dark Side (er, PC's)?
Sorry, but I do NOT plan on porting UMBRAPHILE to PC type machines.
However, the source code if freely available (see Download section), and
if someone were to tackle this I would be more than pleased to see a port
for those who don't "Think Different". If anyone is seriously interested
in this (i.e., taking on the challenge), please contact me.
; CAMERA CONTROLLER PARAMETERS NUMEXP = 36 ; Number of Exposures (*MUST* be even) MAXEXP = 1.5 ; Maximum Exposure Time (seconds) MINEXP = 0.01 ; Minimum Exposure Time (seconds) MAXDCYC = 6 ; Maximum Solenoid Duty Cycle - Warn if exceeded ; ; Note: Set MAXDCYC = 100 to always supress warning ; ; DIAMOND RING/CONTACT II+III PARAMETERS CIIOFF = -2.1 ; Contact II offset from smooth dynamical limb CIIIOFF = 0.6 ; Contact III offset from smooth dynamical limb DRNUM = 4 ; Number of CII and CIII Diamond Ring Exposures (MUST be even) DREXP = 0.01 ; Duration (seconds) for Diamond Ring Exposures DRSEQII = -4, -3, -2, -1 ; Delta-Times for DREXP Relative to CII DRSEQIII = 1, 2, 3, 4 ; Delta-Times for DREXP Relative to CIIINOTE: MAXDCYC and DRIIIOFF are new in UMBRAPHILE 2.3.0, and are described below.
When building an exposure sequence table, UMBRAPHILE will define a series of NUMEXP/2 - DRNUM uniformly spaced exposures from Contact 2 to mid-eclipse. Exposure times will be logarithmically ramped from the minimum exposure time to the maximum exposure time, such that each successive exposure is longer by a constant multiplicative factor (the logarithmic base) then the previous one. The sequence is repeated in reverse order from mid-eclipse to third contact.
You can freely edit the numerical fields of the input file to
suit your needs. Some explanation of each of these parameters is in order.
NUMEXP specifies the total number of exposures to take during the eclipse, I can't imagine that anyone would really use a 24 exposure roll of film, but you never know. I usually take one exposure at the start of a roll of a "gray card" with my name and address on it, since I can reliably load my camera to take 37 exposures. You can certainly specify more than 36 exposures, if for example, you are using a large 35mm film magazine back.
MINEXP specifies the shortest exposure time to be used, which will be for the first exposure immediately following the contact II diamond ring sequence, and also for the last exposure immediately before the third contact diamond ring sequence.
MAXEXP specifies the longest exposure to be used. The longest exposures are taken just prior to, and just after, the instant of mid-eclipse. MAXDCYC To forewarn of possible over-heating, UMBRAPHILE will optionally check the exposure sequence table to see if the time-averged duty-cycle usage (activation) of the solenoid it is driving will exceed a user specified limit. For those using a fully electronic interface, or if this is not of concern in your implementation, set the value of MAXDCYC to 100.
CIIOFF allows you to specify an offset (or correction) to the computed time of second contact, and thereby shift the Universal Times of ALL of the exposures in the exposure sequence control table. You may wish to do this, for example, if the lunar limb profile for your site indicates that the center of figure is not coincident with the dynamical center of mass of the moon. Such a correction is usually not more than a few seconds, and is provided in sources such as the NASA reference publications on solar eclipses (Espanak and Anderson, available through the Internet). This may also be used to compensate for early or delayed termination of the diamond ring due to limb effects (also available from the same references). This correction, and CIIIOFF for third contact, may be applied when computing local circumstances through the Local Circumstances dialog (which was modified with UMBRAPHILE 2.3.0).
CIIIOFF Same as CIIOFF (above) but for third contact. When an exposure sequence table is built, CIIOFF and CIIIOFF will be applied to the computed contact times (in the abscence of limb effects) if this option is selected in the Local Circumstanced sialog.
DRNUM indicates how many exposures to take of the second and third contact diamond rings. UMBRAPHILE will compute the instant of second and third contacts for a smooth lunar limb. You will probably want to take a few exposures before and after these instants, respectively.
DREXP indicates the duration (in seconds) of the diamond ring exposures. The example above is for 1/100 the second exposures, which I find very good for ISO 25 film with an f/10 optical system. If you set this faster than the response time of the solenoid used to activate your camera shutter no pictures will be taken, so some experimentation will be needed for your particular setup (see the section on the hardware interface).
DRSEQII and DRSEQIII indicates when, relative to the instants of second and third contacts, respectively, the diamond ring exposures should be taken (time offsets in seconds). The number of entries here must match DREXP and must be separated by commas.In the above example a total of 8 diamond ring exposures of 1/100th second duration will be taken at one second intervals starting 4 seconds before second contact, and ending 6 seconds after third contact with the spacings indicated. This will leave 28 exposures (NUMEXP - 2*DREXP) to be taken during totality. UMBRAPHILE will determine the duration of totality (or annularity) for the site specified, and will then set up (NUMEXP - 2*DREXP) Universal Times of exposures to be taken during that time in an "exposure sequence table". The first exposure following the second contact diamond ring sequence will be taken at the instant of second contact with a duration of MINEXP. A series of (NUMEXP/2 - DRNUM) successive exposures increasing in duration, logorithmically, to MAXEXP just prior to mid-eclipse will be taken. This half of the exposure sequence will then repeat in reverse order to third contact. After third contact, the remaining DREXP exposures specified in DRSEQIII will be taken.
The complete exposure sequence is temporally symmetric about the instant of mid-eclipse. No exposure is actually taken at the instant of mid-eclipse. The two, longest, exposures (numbers 18 and 19 for NUMEXP = 36), straddle the instant of mid-eclipse. The Universal Times in the exposure sequence table refer to the start time of the exposure, not the mid- point of an exposure.
Note: UMBRAPHILE will support exposure times as fast as 1/1000th second (in both MINEXP and DREXP). The efficacy of either an electro-mechanical or fully electronic shutter interface for a particular camera to respond to such fast control signals must, obviously, be tested.
As an example, UMBRAPHILE computed the local circumstances for 1995 total eclipse from GHANOLI, India, using geographical coordinates entered interactively, then built the following exposure table using the parameters from the UMBRAPHILE input data file gor that eclipse:
## is the exposure number T-cont is the time in seconds relative to contact 2 for the first half of the sequence, and relative to contact 3 for the second half of the sequence that the exposures will be taken. T-mid is the time, in seconds, relative to mid-eclipse, that the exposures will be taken. T+CII is the time in seconds, relative to contact 2 that the exposures will be taken. UTof EXP is the Universal Time of the Exposure (hhmmss.dd). DURAT is the duration of the exposure, in seconds. 1/DURAT is the inverse of the exposure duration in seconds.
1. Assigning/Specifying the Serial Port.
The UMBRAPHILE camera controller software "talks" to your camera through a built-in serial port in your MacOS computer. Since the camera controller is designed as for field operations, most users will be running UMBRAPHILE on a Macintosh Powerbook. While, historically, Powerbooks have only one built-in serial port, the default port designation apparently changed with the advent of the G3 Powerbooks. With pre-G3 Powerbooks (eg., 100, 500, 5000 series), the built-in serial port was port #1, the Modem port. With the G3 series this, by default, seems to have changed to port #2, the "Printer" port. Of course, desktop Macintoshes (and clones) have two built-in serial ports. The first thing you must do when you select RUN CONTROLLER is tell UMBRAPHILE which serial port you will be running your camera interface through. This usually is Port 1. However, if you are running a G3 it may be Port 2 - but then again it may not be, as this depends upon how your system is configured. If you are not sure, just try one, if it does not work, the other will! You must also check that the selected port is NOT already in use by another application, or by AppleTalk. UMBRAPHILE will reprogram the communication parameters on the selected port, so if it is in use by another application, that application is likely to get "confused" and a conflict situation can arise. The RUN CONTROLLER menu item will pop up the following dialog:
If you are unsure of the status of the selected serial port, click WAIT! - Let Me Check, and verify the port is not in use. Note that if your computer has an Ethernet or IRDA port, you do not need to disable AppleTalk. Just make sure that AppleTalk is not active on the port you selected.
Note: At this time, we have been advised that on G4 desktop machines, port 1 should be selected, or the S/W might hang-up.
2. Changing the Serial Port Communication Parameters.
If you click OK - I'm Sure, Go Ahead., in the above dialog, you will then be presented with a second dialog which is used to reprogram the communication parameters on the selected serial port. By default, and appropriate for use of the electro-mechanical shutter activated solenoid described later on, UMBRAPHILE will set the port parameters as follows:
Baud Rate = 9600 BPI
Duplex = HALF
Character Translation Mode = ASCII
Parity = NONE
Stop Bits = 1
Data Bits = 8
Hand Shake = None
Control Character = '00'X
If you are using the UMBRAPHILE interface described in this document then you probably don't need to know this, and just click OK, Do it. If, however, you are using UMBRAPHILE through an interface circuit designed to control a fully electronic shutter activation mechanism, you may need to present a different signal to your interface circuit. You can do this by changing the port communication parameters in this dialog:
UMBRAPHILE will then ask you to click OK (in a confirmatory dialog) when you are ready to reprogram the port. If UMBRAPHILE is unable to access the selected port, for example if you specified port 1 (the Modem port) on a G3 laptop configured to designate "port 2" as the ID for the serial port, you will be so advised and asked to select the other port. Otherwise you will then be asked to:
2. Enter the Latitude, Longitude, Altitude (in meters) of the site, and provide a site name, through the LOCAL CIRCUMSTANCES dialog, which will automatically pop up. If you previously entered this information by running the eclipse calculator, just click OK. If you check the box which says READ DATA FILE, a file requester dialog will be presented asking you to point to the UMBRAPHILE version 2.2.2 data input file (such as ECLIPSE-21JUN2000_231.DATA, which is distributed with the UMBRAPHILE software). If you previously read in the input file you want to use you can deselect this, so you won't have to read it again.
3. UMBRAPHILE will the compute and display local circumstances for the site in a new pop-up LOCAL CIRCUMSTANCES window.
4. UMBRAPHILE will build the exposure table described above, and, optionally, check the duty-cycle utilization of the camera controller solenoid.
Most push-type solenoids are not designed for continuous activation, particularly if used in an "over-voltage" condition. If the time- averaged duty cycle exceeds 6% UMBRAPHILE will present an informational message/warning such as:
Now, don't let this scare you. If you have built the controller hardware (see below) with a really cheesy, cheap, low-voltage solenoid, have not heat-sinked it in any way, and are running it at 4-times overvoltage, it will probably fail to work with about a 6% duty cycle halfway through the exposure sequence. (The value of 6% was chosen emperically by testing serval different solenoids, but may be very different {more robust} for specific units). What happens is simple, it gets hot. When it gets too hot it can no longer produce the force needed to push down the shutter. Or, it could stick in the "down" position even when not energized, as the "plunger" thermally expands in it's collar, holding the shutter opened. Any reasonable solenoid run at even 2-times overvoltage should have no problem with a 25-50% duty cycle for several minutes. Presumably you will not be doing this for the first time during the eclipse (practice makes perfect), and you should have a good feeling about at what level your particular system will not perform as expected. If you do get the warning, and your happy with it just click OK - Run Controller Anyway. If not, and it's too late to change the hardware there are two things you can do:
1 - Decrease the maximum exposure time. You will loose some outer corona so you may need to compensate with faster film. 2 - Decrease the number of exposures.If you've built and "tuned" the interface before the eclipse this situation should not arise. Where can you get a good linear actuator (tubular solenoid)? See the notes in the Parts List section. Whew! enough about that.
The threshold against which the time-averaged duty-cycle of solenoid
activation in the exposure sequence table is checked is established by
the value of the MAXDCYC parameter in the UMBRAPHILE input data file.
As distributed (and in the above example) this is set to a very conservative
6%, but may be adjusted when you have gained some experience (and confidence)
in your hardware implementation. If you are using a fully electronic
interface this check is unnecessary, and you can set the MAXDCYC parameter
value to 100.
5. An Exposure Table window will then pop up, containing the information previously described. We're almost there, but first... UMBRAPHILE will let you run the controller in a "test" mode. Normally, UMBRAPHILE ticks away using your Macintosh system clock as a U.T. reference. So, make sure your system clock is set ACCURATELY to U.T. before firing up UMBRAPHILE!!!! Use Universal Time reference sources such as WWV, or UT downlinked from GPS satellites. When you are testing the system during practice runs you wont want to have to wait 24 hours between runs, or be fiddling with your system clock. So, UMBRAPHILE will present a small dialog which will allow you to specify an offset to be applied to your system clock. The dialog reads:
When you're running the UMBRAPHILE controller for real, make SURE that the time offset is zero and click OK. When you're testing you can adjust the offset to simulate any U.T. you want.
6. The UMBRAPHILE Timer window will pop up (assuming you clicked OK in step five). This is a real-time updating status display keeping you appraised (in BIG letters and numbers) as to where you are in temporally. The window will look something like this:
The title bar (first line above) has a continually updating U.T. clock. To the right of this is a counter which indicates which exposure is next (by number) and what it's duration is (in seconds). Below this the U.T. start time of that next exposure is shown, and to the right (updating) the delta time until that exposure. Below this three clocks are continually updating which give the time until (or since) second contact, mid-eclipse, and third contact. Three informational messages are displayed at appropriate times below this. At 10 seconds before second contact an audible alarm will be sounded through the computer speaker(s) and the message (in red) will be displayed. The one thing UMBRAPHILE will not do for you is take the solar filter off of your camera, but it will try to help you to not forget to do so. Between exposures the message WAITING will be displayed in green. While an exposure is in progress the message EXPOSING will be displayed in Red.
As the exposure sequence is executing, the rows (lines) in the exposure sequence table window which have been completed will be inverted (displayed as white on black), so the black rows of already finished exposures will "march" down the window during the eclipse.
The fastest exposure which can be taken, reliably and repeatably, will depend upon both your camera, and the solenoid you choose. The latter shouldn't be the limiting factor as many low-cost fast-acting push type DC solenoids are available which can do the job. For many 35mm cameras with mechanical or electro-mechanical shutters, the fastest response time of the button itself (due to hysterisis in the button mechanism) is about 1/100 of a second. If you try to push and release the shutter button faster than that it probably will not respond. This may also be true for fully electronic shutters, as the shutter button will probably still be a spring loaded device designed for human fingers.
IF your camera allows an electrical connection for an electronic trigger then you may be able to take direct control rather than electro-mechanicaly coupling a linear solnoid. See: Can I Use UMBRAPHILE to Drive a Fully Electronic Shutter Control?
In keeping with the idea of low cost, I have successfully used NIKON's bottom-of the line "electronic", now obsolescent, 35mm SLR model EM. It's not a fancy camera. It's shutter control is either a) fully automatic, b) one manual speed at 1/90 second, or c) has a "bulb" setting. It's not my ideal choice for normal photography, but for this purpose it's nearly ideal. It's not in production, but NIKON made lots of them. This means they are cheap on the secondary and used camera markets. You would have to look around a bit at camera shows, through mail-order catalogs, or internet-based resellers, but you certainly should be able to find one. It will probably cost around $100 - $150 with the winder depending upon the deal you can get and it's condition. It's shutter "button" is controllable to ~ 1/100th second, so it's fine for this application. It's also light weight and relatively small, which is a plus when you need to mount it, and it's attached solenoid on a telescope. Now, do you have to use one of these? Of course not. I'm just passing this along in case you need to purchase a camera for this purpose and that a really fancy, pricy, new 35mm SLR is not at all required.
The "transmit data" line of the AppleTalk port is connected to a simple TTL buffer/inverter. The design below calls for using a single NOR gate in a 7404 package (about 49-cents). The output of the gate, used as both a buffer and signal inverter, is connected to one side of the activation coil of a 5VDC fast-acting reed-relay (the other side to ground). UMBRAPHILE will normally condition the line to the TTL buffer so that no voltage would be output from the gate to the relay. This relay is used to switch +12VDC power on and off to the linear solenoid (or whatever supply voltage you are running for a particular solenoid). One side of the solenoid is connected to the switched +12V supply, and the other side returned through a common ground. In principle, a 5VDC solenoid could be used without an intervening relay. However, most 5VDC push type relays do not deliver sufficient force to reliably drive many camera shutter buttons (over a mechanical throw of ~ 1/4") rapidly enough without overheating. One could use a heat-sunk power transistor for this 12VDC switching task. A relay was used here for simplicity since no heat-sinking is required, its cheap, and it works.
When an exposure is to be taken, UMBRAPHILE will transmit a series of '00'X character, over the transmit data line. This will result in the buffer's output line going high (+5V), with a ~ 90% on-time duty cycle for as long as desired. It's not possible to assert this line high continuously, but at 9600-baud, having one bit toggle with the others high, is so rapid that the solenoid does not have time to react to the transitions. With many reed-relays you will be able to hear a 9600 Hz "squeal" when activated. This is perfectly normal, and indeed an audio indication that everything is working. The time-averaged voltage applied to the relay will be slightly less than 5V, but the deficit is sufficiently small that the relay will toggle without any problems. For those who are concerned, or are getting marginal performance, you could filter or "pulse shape" the output of the 7404 to the filter, but I've found this really isn't needed.
The linear solenoid is powered by a 12 Volt battery. I have chosen to use a 12VDC 1.2 Amp- Hour sealed lead acid cell. These are very common, small packages. New they sell for ~$20.00 from chain outlets like "Batteries Plus", but are readily available from parts resellers and surplus houses for ~ $10.00. These, of course, are rechargeable over many hundreds of cycles and are a much better value than dry cells. If you are using a 24 Volt solenoid, just use two of these in series.
I have chosen to power the TTL package and reed-relay with a separate 9VDC "transistor battery" through a 5VDC voltage regulator (click here for that schematic). There is no reason that one could not also power this using the 12V battery used for the solenoid (as shown in the above schematic). The reason I use a separate battery is to easily avoid any transient signals which could arise from switching on the solenoid, which (depending upon the specific unit) could have a relatively high in-rush current. Yes, one could filter against this, but simplicity said just use a separate battery.
Packaging and Cabling: The whole electrical interface unit fits into a small hand-held "control" box (about the size of a 36-exposure 35mm slide box). The circuit described above, and the 9V battery fit into the box. Mounted on the box are two miniature SPST toggle switches, a female RS- 232 jack, and a two conductor miniature plug to supply the 12V DC power from an external battery. You certainly could use a larger box and house the 12V battery inside to eliminate one cable and jack/plug connection.
I have used two separate switches for each battery supply. A unit on/off switch for the gate/relay and a separate solenoid arm/disarm switch. This probably isn't necessary, but it will force you to both turn on and enable computer control. This will prevent an "operator error" from accidentally using up film is a mistake is made.
Parts (of course you can substitute) 1 - 7404 6-gate TTL Hex Inverter 1 - 12-to-5 Volt DC Voltage Regulator 1 - SPST 5VDC reed-relay 1 - 12V DC push-type "fast acting" linear solenoid 1 - 12V 1.2 Amp hour sealed lead acid battery 2 - miniature SPST toggle switches 1 - 9V transistor battery* 1 - 9V transistor battery connector* 1 - 14 pin TTL socket (assuming you're not soldering to the TTL chip) 1 - small "project box" for packaging 1 - RS-232 jack (female) 1 - AppleTalk-to-RS232 (male) cable
* Optional, for separate logic supply (not regulated from +12V solenoid power).Nearly all of these parts, except perhaps the solenoid itself, can be purchased from parts retailers like Radio Shack, or you can mail-order from any number of wholesalers. Of course you can substitute or customize. This is intended just to give you an idea of one implementation. As far as a solenoid is concerned I have that one of the following two, both manufactured by LEDEX, will work well with most cameras:
LEDEX # 81840, 12 to 24VDC Small Push-Type Solenoid, ~45-ohms, 0.26-amps @ 12V, 0.533-amps @ 24V, ~6 oz. force over 1/8" travel) LEDEX #192795-001 24VDC Push Solenoid ~90-ohms, 0.27-amps@24VDC ~1 lb. force over 1/16"These specific models have been replaced (but are still available on the secondary market), and others certainly canbe used. I strongly suggest that you obtain a few of different varieties, and determine which works best for your camera. You may want to consider going directly to Ledex and buying a new one. Model numbers 3315 and 3325 look particularly promising and applicable for this purpose. (Find out what they have in stock as you probably can use one of several flavors, as the cost set-up for a production run is prohibitive).
If you do use a 24-Volt solenoid, use two lead-acid batteries in series, or a 24-Volt one (if you can find one), and be sure to use a voltage regulator which is designed for 24V input and 5-Volt output. This should be no problem as most regulators work in the range of 12-24, or 12-35 Volts. Actually, if you have a 12-Volt solenoid, you may want to try it a 24-Volts (2x over-voltage), as you can get more force out of it. As long as you are not energizing it continuously over-heating will probably not be a problem.
While this is not a formal endorsement, I have found a good source for parts, including solenoids, is C&H Surplus, 2176 East Colorado Blvd., Pasadena, CA 91170 (telephone: 626-796-2628). Their prices are very reasonable, and while their stock changes over time they also carry batteries and other parts so you could probably get everything except an AppleTalk connect there. (If you are a tinkerer at heart, and are lucky enough to live near Pasadena, this is a NEAT store to walk around in. Looks like a giant incarnation of my basement {when I had one!}).
If you want to use this on a camera tripod (rather than a telescope), then you will want to affix a 1/4-20 nut (either with a flange, or soldered/welded or epoxied on - depending upon materials used -but affixed in some form) to the bottom of the frame.
Note: Linear actuators which do not captivate the central plunger cannot be used in a horizontal configuration (as the plunger can be pushed out of its collar when returned after actuation). This can be a problem if you are photographing the eclipse at a small zenith distance. In that case you will need a "right angle" system to mount your camera (as naturally occurs on a Newtonian telescope, or a right-angle prism on a Schmidt-Cassegrain). Just thought I should mention this, though you would obviously discover this yourself the first time you tried this with such an actuator in a horizontal orientation - when the plunge comes flying out of the collar if not captivated.
Can I Use UMBRAPHILE to Drive a Fully Electronic Shutter Control?
Of course. However, the electronic interface requirements differ
significantly for different cameras. Some are very simple, some more
complex. There are so many flavors that we cannot possibly offer
specific suggestions to suit all. In some cases all one needs to
do is provide a "key closure", others a pull-up or pull-down at TTL levels,
and still others an edge-trigger. Whatever the case, it is generally
fairly easy to do just a bit of signal conditioning on the control signal
which is designed to drive the solenoid to provide whatever you need.
In some cases you may need to filter the 9600 Baud signal (which contains
"start bits") with an R/C filter, and then perhaps grab it at the right
voltage level with a Schmitt trigger. A little experimentation is
needed for different cameras. You can, of course, re-build the interface
circuit as needed (and reprogram the port to deliver a more compatible
signal). Here is one example (with
some caveats), kindly provided by Dan McGlaun. Thanks, Dan.
Miscellaneous, Minutiae and Multiple Cameras
Just a few other notes on using UMBRAPHILE.
I. You can export the content of any of the currently displayed
output windows (Centerline, Local
Circumstances, and Exposure Sequence
Table) to a text (ASCII) file. You can do this at any time EXCEPT
when you are actually running the controller (i.e., the clocks are running
in the UMBRAPHILE timer window). If you want to save the sequence
table you are executing you have two options:
II. You can also save all of the setting you have established in the various UMBRAPHILE dialogs, to be restored as is, at a later time. This will permit you to re-run a particular scenario or set of inputs, without having to enter your values, switches, selections, etc., over again. To do this select SAVE SETTINGS, and you will be asked to supply a name for your "Settings" file. You may restore those saved settings at any time by using the GET SETTINGS menu item. Note that saving the on-the-fly changeable UMBRAPHILE settings does not alter the parameter values in your input data file. Should you want to change these you will need to do so in an external text editor/word processor.
III. It bears mentioning that you can use UMBRAPHILE to control more than one camera simultaneously. In the case of a solenoid interface, all you need to do is parallel the solenoids. In the case of a fully electronic interface you can just fan out (buffer if needed) the control signal. UMBRAPHILE will be running only a single exposure sequence table so the two, or more, cameras will be taking exposures at exactly the same time, for exactly the same durations. Does this make sense? It does IF the reason you ar running different cameras is to capture the various eclipse phenomena which occur over a huge dynamic range with different focal length and f/ratio optics, and/or different ISO film speeds. For example, long lenses or telescopes which you might use to capture the inner corona, details of prominences and chromosphere (e.g., 1000 - 2000 mm EFL) tend to be rather slow (e.g., f/12), To capture the large extent of the outer corona and coronal streamers you'll need a larger field of view afforded by a shorter focal length (e.g.., 400mm). These lenses tend to be faster, again for example only, f/6. The "depth" to which you will record an image scales as the inverse square of the f/ ratios, and directly by the ratios of film speeds. If you are running two cameras with identical exposure sequences, a given exposure time will then be optimized for different dynamic ranges and capture different phenomena. For example, in the above case lets say you are using ISO 25 film for very high resolution images at f/12 with a long focal length, and ISO 200 film with the f/6 lens for outer corona. In that case, with these films the f/6 system will be (12/6)^2 * 200/25, or 32 times faster then the f/12 system. Thus while the long lens is capturing the inner corona, the short lens is capturing the outer corona. You can play the numbers games, but you get the idea, and capture a wide range of eclipse phenomena There is VERY little cost in running other cameras with UMBRAPHILE, just choose your film speeds, f/ratios (and focal lengths) judiciously.
Please feel free to redistribute UMBRAPHILE to anyone who may be interested. When doing so please keep this description and these instructions with the software (for the overly litiginous - please see LEGAL Stuff).
Cheers, and !CLEAR SKIES!
OK? Now the plug. UMBRAPHILE is absolutely free, no ifs ands, buts, or strings attached. We do have some other astronomy related software products of more general interest which is down-loadable on the World Wide Web. Why not take a look and see if you find something to your liking. Our URL is:
http://balder.prohosting.com/stouch/ or just:
Return to sofTouch APpLications Home Page.
For additional information send e-mail to: gschneider@mac.com or snail-mail:Glenn Schneider (click here to find out more about the author/creator of UMBRAPHILE and his eclipse chasing exploits)
Please take a moment to SIGN the UMBRAPHILE Guest Book.
 |
This site is owned by
Glenn Schneider |
 |
| [Previous]
[Skip
Prev] [Skip
-5]
[Next] [Skip Next] [Skip +5] [Random] [List] [Join] |
