This graph gives me confidence that defocusing will solve my overflow problem. It’s a profile of the number of photons/electrons captured (vertical axis) versus the distance from what I thought was the exact center of the star RR Lyrae aka HD 182989.
(It is amazing how fast the computer works this out! I’m used to my middle school or high school students working things out like this by hand at first — it’s a very slow and tedious process! Let us give a tip of the hat to Williamina Fleming, who was the first person to notice and record that RR Lyrae was a variable star. She did so by examining glass plates on which were little dark spots made by stars’ light striking particles of suspended silver nitrate, without a blink comparator! Wow!)
Notice that there is one
If I defocus the camera a bit, that saturated value would get spread out over an airy disk that might look like this:
I went up to Hopewell on Wednesday night, and practiced once again taking images of RRLyrae with my Seestar S50, but this time with the built-in light-pollution rejection filter in place. I figured that would reduce the number of photons by a lot, and maybe by enough to stop overwhelming the pixels.
Unfortunately, it was not sufficient, so, since I cannot reduce the number of seconds of exposure for each sub-image (or ‘slice’ as AstroImageJ calls them) below 10, and I cannot change the ISO or gain for the chip, the only choices left are, in order of ease of implementation:
De-focus the images to spread the photons into a wider range of pixels, hopefully not causing any of them to become saturated, but not so much as to confuse the plate-solving app;
Make a black, circular mask smaller than 50 mm in diameter and put it in front of the lens, reducing the total number of photons;
Persuade the engineers and programmers at ZWO to change the software to allow users to reduce the length of exposures, and to allow time lapse photography with what they call Star-Gazing but everybody else calls deep-space observing.
Number 1 I will do next time.
By the way, the exact mechanism by which this variable star dims and brightens is still not fully understood, though its timing cycle is extremely regular and quite well known.
No Auroras for me:
It was very cold and windy so I couldn’t stand being outside up on the Bull Run Mountain ridge for very long at a time. The sky was almost perfectly clear the entire night, and the beautiful winter constellations were extremely bright, and it was fun watching them make that apparent great pivot around us.
I saw no auroras; since I was was groggy (from forgetting my meds) and quite cold, so I spent most of the night inside napping and trying to get warm, but went out from time to time to look around and to check on the progress of my little Seestar. So when the peak happened I was probably dozing. Not too many other folks saw it, apparently, and the images I’ve seen were not nearly as impressive as for other aurorae on other dates. Oh, well.
As described in my last post, I got a light curve for a known variable star in my little Seestar S50 a few weeks ago that showed absolutely no variability whatsoever over a roughly 4 hour period. Since this star’s variation occurs extremely regularly, there is a known formula that will give you the precise location in its cycle if you feed in the Julian day (JD). I plugged the start and end times for my run, and got the following:
And was confused
So RRLyrae should have dropped from something near 7.3 magnitude to around 7.6 magnitude, which is a LOT for this sort of thing. But my graph of brightness of RRLyae, compared to a nearby star of roughly the same magnitude, looks like this:
Which is barely any change at all. The few pairs of dots below the blue blob line are glitchy data that should be ignored; notice that it happens for both stars. In fact, I see more variability in the pink comparison star’s brightness than I do with RRRLyrae.
Was the scope indeed pointed at the correct star? Well, I had plate solving on each and every frame, and they all agreed, so, yes.
I did notice a problem with saturation, but didn’t know exactly by how much. Nikolaos Bafitis suggested that I use my mouse to look more closely at the centers of the star images themselves in AstroImageJ. I did so, and at last noticed that one of the boxes held the number of pixel counts right under my mouse pointer. Duh! Sure enough, my target star, RR Lyrae, had a count of 65,533, which is 2^16, and (I looked it up) that is precisely the maximum for these pixels on these CMOS cameras. So that’s why RR Lyrae’s brightness was so steady: it was always OVERFLOWING.
So I have to figure out a way to gather fewer photons per pixel around the target and comparison stars. There are several possible ways of doing so without changing the electronics or trying to mess with the operating system or user interface.
Reduce the ISO setting from the current default value.
Shorten the exposure time.
Change the focal ratio by placing a circular mask over the lens aperture.
De-focus the images so that the light is spread out over a larger area.
Add some sort of filter.
Unfortunately right now, the Seestar doesn’t allow you to do either number 1 or number 2. It would be nice if ZWO engineers would add those capabilities in the ‘advanced’ menu,
Number 3 is quite doable. I happen to have on hand a large roll of black Kydex plastic and a set of Forstner bits to make nice holes with. But it this would require a fair amount of time and effort. It would also reduce the resolution of an already rather small 50mm lens.
Number 4 is more easily doable: turn off the autofocus feature and do some experimentation to find a good fixed de-focus point. However, if the stars are too fuzzy, then plate-solving becomes much harder and slower.
Number 5 can be done by using the built-in light pollution filter, whose transmission bandwidth is very small. It’s the bottom graphic below.
The graphics above come from an excellent Unofficial Seestar handbook written by Tom Harnish. He has a number of suggestions that I hope the engineers at ZWO pay attention to and follow.
The option that seems easiest is number 5, using the light pollution filter. If I couple that with the built-in time-lapse feature, I won’t fill the Seestar’s entire memory with a zillion FITS images.
I hope to try this tonight up at Hopewell Observatory, where I can set this up, have it run all night connected to mains power, and I can sleep in a nice warm cabin.
I’m still struggling to do simple astronometry even on a well-known variable star like RRLyrae. If you could measure its brightness for several nights without any breaks, you should in theory get a light curve like this:
I don’t. I’m still trying to figure out why my light curve for RRLyrae is so flat.
In 2004, during a two-week astronomy summer class at Mount Wilson, with a professional astronomer on hand guiding me at every step of the way over a couple of nights, I got light curves looking like pieces of the good example above. (Why only pieces? Because you can’t image a star in the daytime or when it’s cloudy or if the star is on the other side of our planet!)
A couple of weeks or so ago, inspired by an exoplanet light curve taken by a 9th grader with a Seestar, I had the opportunity to run my tiny automated Seestar S50 for 8 hours outside at Hopewell Observatory, which is a nice, safe location, connected to wall power. The weather was perfect for it. The scope is about the size of a large cookie tin on a tripod. It did nothing but take ten-second photos of a small region around RRLyrae from whenever stars came out until dawn.
Afterwards I then had to start analyzing those 972 images. My first step was to learn how to use YET ANOTHER astro-imaging package, called AstroImageJ. It’s quite impressive, but It pisses me off that every few years I have to learn an entirely new piece of software, and just throw out nearly everything I learned regarding anything software-related over the past 60 years!
I eventually figured out how to get AIJ to verify that the little scope was in fact looking at my chosen star — and it was.
I then asked AIJ to compare the brightness of RRLyrae to the brightness of five or six other stars of similar brightness that happened to be located in the same field of view, for each image. (Today’s computers quickly do all sorts of math on the values of certain pixels in certain rings around certain stars, at lightning speeds, but the human computer of 1899, Williamina Fleming, who discovered this star, had to do it completely manually by comparing the size of the spots on a glass photographic plate. My hat is off to you, Ms Fleming, and all the other unsung female computers!
Here is a screenshot of the very last image in the series I took. The RA and Dec are the coordinates of RRLyrae, which AIJ has circled in green. The stars circled in red are comparison stars. That 20.28′ legend is in arc-minutes, 60 of which equal one degree. So the field of view is a bit over half a degree across and roughly a degree vertically.
To my surprise, my results were totally different from what I expected to find.
The blue dots are RRLyrae’s brightness on some scale that the computer cooked up, and the pink ones are from one of the known comparison stars. The x-axis goes from roughly 0.48 to 0.64, or 0.16, which is 1/6 of a day, or 4 hours.
The cases where both the blue and pink dots drop down below 1.0 are garbage caused by some glitch and should be ignored. But one thing is for sure: there is no sawtooth spike in my data for RRLyrae’s brightness during those 8 or 9 hours!
Four possible reasons are:
I’ve made a great scientific discovery! (probably not correct)
2. Wrong star? (I don’t think so. Checked and re-checked)
3. Perhaps those 8 hours happened to correspond to a flat place in the light curve (Possible — I just noticed that these images end before midnight, but I thought it kept working until dawn! Must re-check!)
4. The pixels all are too saturated, ie were exposed for too long,, which fills up the pixel with too many electrons. (This is possible, I guess, but each of these were merely 10 second-long exposures, which doesn’t sound very long to me, but maybe I’m missing something important).
Saturation is what the following graphic seems to indicate:
If it is indeed saturation that is making all the stars not change brightness, then what do I do?
I don’t think I can control the gain or ISO inside SeeStar, but I can ask for shorter time exposures, I think, by trying a time lapse and asking for shorter exposures, if possible. I just need to have time and a location to let it run all night without anybody disturbing it, making a time lapse of the sky.
Guy's Math & Astro Blog 