Allsky cameras for meteors

[Chris Peterson]

I originally sent this to Bob Nemiroff and a few others as a private communication, but Bob thought it would be of general interest and asked me to repost it here. I'm discussing allsky cameras that are specifically intended for recording meteors.

As you may know, I operate a network of allsky cameras in Colorado, intended specifically for collecting meteor data. We have had cameras running for over five years now. The project is underfunded, and we are interested in making it as wide as possible, so we've been careful to seek the most cost effective approach. Currently, that means using PC164C cameras with fisheye lenses. We are able to set up each station for well under $1000, and I'm making some changes now that will reduce that to about $500 (less the computer, which does not need to be new or fast). The only problem with the PC164C is that it uses a 1/3" format sensor, and the fisheye doesn't quite cover it. With this setup we lose about 15° of sky in two directions. That isn't a serious problem since most of the installations are in locations that have a few natural obstructions, and in any case the most interesting events are usually higher than that. I also have one camera that uses a Watec 902HS. With its 1/2" sensor the entire sky is imaged, although it adds about $170 to the cost of a station.

For meteor detection you do not want an integrating camera like a StellaCam. You must collect true video (25/30 fps) or you lose all velocity information. With multistation integrated images you can get a path, from which you can make reasonable estimates for possible fall sites, but you can't get the initial state vector you need to calculate the orbit of the parent body, which is one of the most important things you should want to do when studying meteors. The velocity profile is also required for estimating the mass and composition of the meteoroid. If your only goal is meteor monitoring, save the money and use a simple video camera. If you use an integrating camera for its other features, be sure to set its frame rate to 25/30 fps when you are monitoring meteors.

Integrating cameras tend to be somewhat less sensitive than video cameras to meteors, since the effective exposure time is usually set by the time the meteor image is actually on a pixel. Both cameras will therefore have about the same signal, but the integrating camera will have somewhat higher noise from dark current and sky background. Our video cameras are sensitive to just under magnitude 2 in individual frames, and to better than magnitude 3 in externally stacked frames. This provides an ample number of reference stars for astrometric calibration.

Generally, high resolution is not required. We normally operate at only 320x240, but using sub-pixel centroid calculations and considering the best fit between multiple frames, our position accuracy is around 3 arcmin, which at typical meteor distances is only around 100 meters.

The cameras run day and night. A few have fixed iris lenses, but they haven't shown any sign of damage from the Sun. Nearly all of the most sensitive cameras these days use Sony SuperHAD exView sensors, and these slowly develop hot pixels due to cosmic ray damage. We notice this since many of our cameras are at high altitude, but it doesn't seem to impact the performance in any significant way.

From dark sites, we average 10 meteors per night, although the count varies considerably with the time of year and moon interference (there is a frequency chart at http://www.cloudbait.com/science/showers.html). Fireballs (mag -4 or brighter) are much more common than we expected, averaging about 0.7 per day (very large fireballs are documented at http://www.cloudbait.com/science/fireballs.html).

I'm in the process of getting all of our data online, which involves converting a lot of old data to a new format. About 15,000 events are available at http://meteor.cloudbait.com, with another 10,000 still waiting to be added. The site currently provides the ability to view still images of each event, and to map them. Soon to be added will be the ability to make orbital calculations for multistation events.

If you have any questions about these cameras, please let me know and I'll be happy to answer them. Given my experience over the last five years, I'm quite convinced that simple video is the best approach for monitoring meteors. If you're also interested in work that benefits from longer exposures, I'd consider setting up separate cameras for each application.

[nbrosch]

[quote="Chris Peterson"]

I also have one camera that uses a Watec 902HS. With its 1/2" sensor the entire sky is imaged, although it adds about $170 to the cost of a station.



For meteor detection you do not want an integrating camera like a StellaCam. You must collect true video (25/30 fps) or you lose all velocity information. With multistation integrated images you can get a path, from which you can make reasonable estimates for possible fall sites, but you can't get the initial state vector you need to calculate the orbit of the parent body, which is one of the most important things you should want to do when studying meteors. The velocity profile is also required for estimating the mass and composition of the meteoroid. If your only goal is meteor monitoring, save the money and use a simple video camera. If you use an integrating camera for its other features, be sure to set its frame rate to 25/30 fps when you are monitoring meteors.

Integrating cameras tend to be somewhat less sensitive than video cameras to meteors, since the effective exposure time is usually set by the time the meteor image is actually on a pixel. Both cameras will therefore have about the same signal, but the integrating camera will have somewhat higher noise from dark current and sky background. Our video cameras are sensitive to just under magnitude 2 in individual frames, and to better than magnitude 3 in externally stacked frames. This provides an ample number of reference stars for astrometric calibration.

Generally, high resolution is not required. We normally operate at only 320x240, but using sub-pixel centroid calculations and considering the best fit between multiple frames, our position accuracy is around 3 arcmin, which at typical meteor distances is only around 100 meters.

The cameras run day and night. A few have fixed iris lenses, but they haven't shown any sign of damage from the Sun. Nearly all of the most sensitive cameras these days use Sony SuperHAD exView sensors, and these slowly develop hot pixels due to cosmic ray damage. We notice this since many of our cameras are at high altitude, but it doesn't seem to impact the performance in any significant way.

From dark sites, we average 10 meteors per night, although the count varies considerably with the time of year and moon interference (there is a frequency chart at [url]http://www.cloudbait.com/science/showers.html[/url]). Fireballs (mag -4 or brighter) are much more common than we expected, averaging about 0.7 per day (very large fireballs are documented at [url]http://www.cloudbait.com/science/fireballs.html[/url]).

I'm in the process of getting all of our data online, which involves converting a lot of old data to a new format. About 15,000 events are available at [url]http://meteor.cloudbait.com[/url], with another 10,000 still waiting to be added. The site currently provides the ability to view still images of each event, and to map them. Soon to be added will be the ability to make orbital calculations for multistation events.

If you have any questions about these cameras, please let me know and I'll be happy to answer them. Given my experience over the last five years, I'm quite convinced that simple video is the best approach for monitoring meteors. If you're also interested in work that benefits from longer exposures, I'd consider setting up separate cameras for each application.[/quote]

[i]We tried a WATEC and it gave slightly reduced preformance compared with a cooled SBIG CCD. This, in stellar imaging, which is one of the goals of the NSL network. Since for meteors, as you rightly write, you need timed information, we are going to put low-obscuration rotating shutters in our cameras. This way we can have both the stars and the meteors.

[/i]

[RJN]

Thanks, Chris. Very interesting!

My main concern is not hardware cost. It is the ability to get two types of images from the same wide angle device. The first is an image or series of images that is maximally useful for meteor science. That would mean time-resolving the meteor. The second is an image or a series of images that are maximally useful for determining cloud cover and possibly even clear air opacity.

Why do both together? To get good perches. Many observatories want a cloud monitor, but they couldn't give a hoot about a meteor monitor. Usually, to get a new instrument situated at a major observatory takes years of paperwork and reviews. But this isn't true if the device is a cloud monitor -- observatories typically want those right away.

So the trick is, in my view, to get both of these goals with the same hardware. There appears to be two ways to achieve this. One is to use an optical chopper. Another is to use video with a high enough fame rate to time-resolve meteors. Noah Brosch is a big fan of optical choppers, but in my limited experience these are hard to implement in practice.

Another idea is co-add frames in a clever way. One implementation would be to keep adding a new video frame to a 10-second stack every 1/30th of a second, and drop the last frame off the stack. I don't know if this is possible.

Yet another idea is to "trigger" on meteors and only save images that might have a meteor on them. I believe this is done with the SBIG Meteor Camera. That link is here: http://sbig.com/products/allsky.htm .

I am considering putting together a small "mini-meeting" on wide-angle night sky cameras this summer, probably in August. Please contact me if you might be interested in attending such a meeting.

- RJN

[Chris Peterson]

My main concern is not hardware cost. It is the ability to get two types of images from the same wide angle device. The first is an image or series of images that is maximally useful for meteor science. That would mean time-resolving the meteor. The second is an image or a series of images that are maximally useful for determining cloud cover and possibly even clear air opacity.

Yes, I understand why you might want to do this. But to some extent you are compromising your data by using an integrating camera for meteor work. It isn't that you can't get good data (and my post wasn't intended to suggest that), just that if your primary goal is meteor monitoring, this type of camera isn't the best choice.

So the trick is, in my view, to get both of these goals with the same hardware. There appears to be two ways to achieve this. One is to use an optical chopper. Another is to use video with a high enough fame rate to time-resolve meteors. Noah Brosch is a big fan of optical choppers, but in my limited experience these are hard to implement in practice.

I'm not fond of choppers. Some time back I set up an Apogee camera with a chopper and fisheye (3-minute frames) next to a video allsky camera. The Apogee made beautiful sky images, but didn't catch quite as faint of meteors, didn't have as good of time resolution of the meteor paths, didn't have any absolute time on the meteors, and didn't provide nice tight images of the meteor as it traveled, so astrometry was difficult. And the chopper stopped working a few times when it got real cold outside. I'm happy to avoid too many moving parts.

Another idea is co-add frames in a clever way. One implementation would be to keep adding a new video frame to a 10-second stack every 1/30th of a second, and drop the last frame off the stack. I don't know if this is possible.

Some frame grabbing software does just this. But you still have the problem of missing timing information. But I have a test program that splits the incoming frames into two processing paths. One keeps a ring buffer of 500 frames, which is checked for motion in order to trigger recording to a file. The other keeps a floating average of the last 256 frames. I'm looking at this as an approach to keeping both a full rate video and a deep image for astrometric comparison for every event.

Yet another idea is to "trigger" on meteors and only save images that might have a meteor on them. I believe this is done with the SBIG Meteor Camera. That link is here: http://sbig.com/products/allsky.htm .

Yes, that's what our cameras do, but they save a short video rather than a still image. It's also what the Sandia Sentinel cameras do.

[nbrosch]

The Czech people, who do quite a lot of meteor imaging, use choppers on their large-frame photographic cameras quite successfully and have not reported problems with those. A chopper might work quite well if it is protected from the elements (i.e., located between the lens and the CCD). Since this location is in the camera enclosure, the temperature there is always warmer than that of the outside air.

Using a video camera and stacking images at, say, 30 sec or 180 sec intervals would allow also the detection of rather faint stars. It would be interesting to experiment with such stacking to see what limiting magnitude one could reach.

I think we should not give up the idea of keeping a deep record of the sky, since it might prove useful for transients, even if only for an upper limit...

[Chris Peterson]

The Czech people, who do quite a lot of meteor imaging, use choppers on their large-frame photographic cameras quite successfully and have not reported problems with those.

Well, with film there is little other choice. An interesting possibility with CCDs is electronic chopping, something I've not seen tried. Many sensors have photogates that can be biased to prevent pixels from recording photons (also called electronic shutters). It would be interesting to modulate these in order to effectively chop the signal. Might make a degree of timing possible without using a mechanical chopper.

I think we should not give up the idea of keeping a deep record of the sky, since it might prove useful for transients, even if only for an upper limit...

Certainly not. And I would probably not choose video for any camera with that primary purpose.

[tepickering]

i'll chime in with some of my experiences with video-based sky cameras. my first attempt used a PC164C camera. to get anywhere near the sensitivity we wanted, i had to coadd a LOT of frames. an example of a 2-minute (7200 frame) coadd can be seen at http://mmto.org/~tim/sky7200.fits. the problem with coadding images that are grabbed at video rate is that you're getting killed by the readout noise. a stellacam can reach similar sensitivity to this with just 32 frames of on-board integration.

our system at http://skycam.mmto.arizona.edu/ can reach 5th or 6th mag on clear nights using a stellacam II at its full 256 frame integration. it's a very effective sky and cloud monitor and updates its images every 10 seconds. it's also been very reliable. in 2 years of continuous operation we lost a monsoon month to a lightning strike and part of a day to a hard drive failure. and the lightning strike only killed the auto-iris control on the stellacam. that camera still works perfectly otherwise and is in routine use elsewhere.

there are definite tradeoffs between monitoring sky conditions and looking for meteors. my system is pretty good at seeing meteors, even relatively faint ones. there's no accurate timing or velocity information, though. i've been thinking about different electronic shutter schemes as possible ways to have our cake and eat it, too. the stellacam does have a built-in photogate-based electronic shutter. it should in principle be possible to hack the stellacam's electronics in some way to make that shutter chop at some desired rate. that would take far more electronic proficiency than i'm capable off, but it may be worth others looking into.

playing with my brother's 3D gaming glasses got me thinking about liquid crystal shutters. the glasses aren't too expensive (<$100), are of reasonable optical quality, and can cycle at better than 100 Hz. putting something like this in the optical path of an integrating camera would give you nice velocity resolution at the expense of having to integrate somewhat longer. there's still the issue of absolute timing of events, but at least with a stellacam you can narrow it to a 10-20 sec window versus a few minutes. i've looked around on-line for liquid crystal shutter windows, but haven't really found anything suitable. has anyone else looked for or has experience with such things?

tim

[nbrosch]

[quote="tepickering"]
playing with my brother's 3D gaming glasses got me thinking about liquid crystal shutters. the glasses aren't too expensive (<$100), are of reasonable optical quality, and can cycle at better than 100 Hz. putting something like this in the optical path of an integrating camera would give you nice velocity resolution at the expense of having to integrate somewhat longer. there's still the issue of absolute timing of events, but at least with a stellacam you can narrow it to a 10-20 sec window versus a few minutes. i've looked around on-line for liquid crystal shutter windows, but haven't really found anything suitable. has anyone else looked for or has experience with such things?

tim[/quote]

We considered liquid crystal shutters when we began thinking about the CONCAM IVs. These have definite advantages since they do not have moving parts. However, there is a price to pay.

The liquid crystal devices work by rotating the polarization plane of the light upon the application of an electric field. This means that there has to be a polarizing filter (plastic polaroid, probably) before the shutter. In the normally-open position the LC shutter polarizes the light parallel to that from the polarizer. In the closed position, the LC polarizes in the perpendicular direction. Therefore, in the closed position the polarizing directions cross and no light gets through.

The conclusion is that in the open position one loses at least half of the light, about a magnitude, in total sensitivity because of the front polarizer.

[nbrosch]

This is from a private Email exchange, but it might interest the forum thus it is put here as well:

I checked the spec sheet for the StellaCam III with the cooler as posted at http://www.optcorp.com/product.aspx?pid=319-325-9051. These cameras look great for looking at deep sky objects, but I wonder how well they do for meteors. The reasons are

a. the small array (811x508 pixels), the small pixel size (8.4x9.8 microns) implying a low dynamic range for single frames, and

b. the fact that this is an interline transfer CCD. If I am not mistaken, this means that between each pair of lines there is a dead region that serves to get the signals out FAST to maintain the video rate.

In addition, the spec sheet does not mention a digital output. With the video output one would need a frame grabber and a digitizer to at least eight bit, pehaps more to have better photometric precision.

The cameras may find a secondary use as sprite detectors, though I wonder how sprites would look through a fisheye lens. I think that these devices may need special export licenses and end-user-certificates, since such sensitive cameras may find other uses than astronomy...

[Chris Peterson]

I checked the spec sheet for the StellaCam III with the cooler as posted at http://www.optcorp.com/product.aspx?pid=319-325-9051. These cameras look great for looking at deep sky objects, but I wonder how well they do for meteors. The reasons are

a. the small array (811x508 pixels), the small pixel size (8.4x9.8 microns) implying a low dynamic range for single frames, and

b. the fact that this is an interline transfer CCD. If I am not mistaken, this means that between each pair of lines there is a dead region that serves to get the signals out FAST to maintain the video rate.

In addition, the spec sheet does not mention a digital output. With the video output one would need a frame grabber and a digitizer to at least eight bit, pehaps more to have better photometric precision.

Although I don't think the StellaCam is ideal for meteor work (as I noted earlier, I think video rate exposures are best), I don't think your concerns are at issue. For one year, I ran an Apogee AP6 (1Kx1K, 25um pixel, 14-bit digitization, 3-minute exposures) camera side by side with a PC164C, both with 180° fisheye coverage. The PC164C has small pixels, an interline sensor, and was digitized at 8-bits and 320x240 resolution. The PC164C was almost 1/2 magnitude more sensitive than the Apogee (to meteors), and the residuals on the astrometric calculation of meteor position were about the same for both cameras. The only advantage the Apogee camera provided was that it took much more light to reach saturation, and therefore the derived light curves were more accurate for fireballs.