MORE ON MARKING

The advantage of moving the light curve, with the cursor in the center of the screen, is that you see the chosen data point in context, with data showing before and after. However, if you wish, you can also move the cursor left and right, while the light curve stays put. The '<' and '>' keys (the ones above the ',' and '.' on my keyboard) do this job. You don't need the shift key to get at them: shift means something else in this context. The '>' key by itself moves the cursor right by 1 data point each time you hit it, which is OK if the curve is uncompressed -- you see it move right away -- but if the curve is compressed, even though it moves to the next datum (and the new values are displayed on the top display line) it will stay on the same pixel column until it comes to the end of the column group, then move one step to the right. If you have the curve compressed by 16, say, you have to hit the key 16 times to traverse a full group. You can hold down the Shift key along with the '>' key, and the cursor will move by one column group per hit, or scan right by pixel columns if you hold it down so it repeats. This is usually what you want. If even this is too slow, hold down the Ctrl key, and each hit on the '>' key jumps the cursor to the right by 25 columns. The '<' key works the same way, except that it moves the cursor to the left.

You can, if you choose, mark the whole light curve this way, moving the cursor and the light curve separately. It's harder, though. It is also sometimes confusing if you get to thinking that the left arrow key (which moves the light curve left) and the '<' key, which moves the cursor left, do the same thing. They really don't. If you insist that they do, though, you can tailor your copy of Qed so the cursor goes the same way with either the left arrow or the '<' key. At the bottom end of the qed.ini file there are customizing constants, and this is the second of them, called "revaro", followed by its default value: '0'. If you make this a '1' with a text editor, qed will honor this the next time you start it up. This option was demanded by a Polish observer, so I think of it as Reverse Polish Notation.

Customizing Qed

While we are right here, let's consider the rest of the customizing stuff on the bottom line of the qed.ini file. This file is generated by Qed when it starts up and fails to find a qed.ini file, putting it wherever you keep the qed.exe file, using internal defaults for the customizing constants. If you already have one, Qed uses that. The default line looks like this:

blms 250 revaro 0 smsky 9 autobr1 0 autobr2 0 vbos 1

The first constant adjusts how rapidly blinking points blink, and the default value (in milliseconds) causes blinks twice per second (250 ms on, 250 ms off). It's in there because older LED display screens were very slow, and fast blinking did not work very well. You can make the blinking more frantic by making this constant smaller.

The smsky constant smooths a sky buffer (using a 9-point running boxcar by default) just before you subtract sky, and puts that operation into the oplist. It defers to you: if you smooth the sky before you subtract, it doesn't do it a second time. You can turn autosmoothing off by setting the constant to 0.

The next two constants invoke autobridging just prior to a write operation, on each light curve separately. This action is off by default, since some purists don't like to bridge, ever. But if you are persuaded by the arguments in the bridging discussion below, you can set these to values appropriate to a given run, and Qed will remember to do it for you. The program Qmrg can't deal with unbridged data, so if you plan to use it later, you had better bridge in Qed.

The final constant sets the verbosity level; setting it to 0 will tell Qed to show you errors only, 1 (the default) shows warnings and errors, and 2 (the maximum) Tells All.

Rationale for Reducing Ch2 Data

When we first started this business of time-series photometery, we used the Ch2 data only to identify regions of the light curve affected by clouds, and we didn't bother to reduce the data in Ch2 because it was so terribly tedious. Some (older) observers still think this way. We have learned, however, that Ch2 data can often be extremely valuable, so we now routinely reduce the "constant" star light curves as well as data from the one we think is variable, as we have done in the examples above. Any time we see identical modulation in both light curves -- when they dance together -- we know something is wrong. It's often light cloud, sometimes invisible even to the night-adapted eye. If it's not too terrible we can sometimes remove its effect by smoothing the Ch2 data, then dividing the Ch1 light curve by it. It doesn't always work, but sometimes it does, and you can't do it at all if you don't reduce Ch2.

Sometimes funny results do not come from clouds: we learned about g-mode pulsations in the earth's atmosphere after the volcano Mt. Pinatubo erupted and spewed high-level ash into the atmosphere between us and the stars. We found that all the stars we looked at had about the same periodic modulation, near 450 seconds. This included the "constant" stars observed in Ch2. Had we not reduced the channel 2 data and analyzed it, we might never have known what was happening. A periodic change in atmospheric density, with obscuring ash becoming more, then less obscuring, did the job.

Good things can happen in Ch2 as well: we found a very interesting Delta Scuti star that had been chosen as a "constant" monitor star for Ch2. The main target star wasn't near as important. Moral: reduce the channel 2 data unless there is really something wrong with it. And never trust one channel data. Never.

Design courtesy of Ian Shorrock