*** UNDER CONSTRUCTION *** Credits: Some of the information here is gleaned from this startrails blog
Using the 'stock' lens (which has an effective FOV of 9.79x7.3 arc min) and simply pointing the (NoIR) camera out of the window (at max ISO (800) and slowest 'shutter speed', for the 5Mpixel Pi-camera that's 6s, for the Pi camera v2 (8Mpixels), that's 10s) it is actually possible to make out meteor trails, the Moon, many of the brightest stars and (of cousre) aircraft lights :-). However (chances are) you will have to 'guide' the camera and 'stack' the frames (even at 10s) to see anything fainter
Meteor watching
The Moon and meteors are actually bright enough to be 'seen' by the Pi camera (with the 'stock' lens) at way less than the max. 6s exposure. A meteor will 'burn up' in a second or so, so no 'extra light' will be received in a longer exposure, although your photo's will look 'nicer' if they also contain background stars
The real reason for using long exposures is to improve your chances of actually 'capturing' the meteor. If it takes 1 second to 'save' the photo, then 1 second exposures means you have halved your chances - whilst 10s exposures means you are reducing your chances by less than 10% (1s in 11s).
So most 'Meteor watch' guides will suggest longer exposure times (up to 30s). Further, if you leave the camera on contineous 'shoot and save' at 30s a shot, you have to check less than 120 a hour (although that does mean up to 1,000 per night) whilst 10s shots means you have about 60x60/11 = 327 an hour that need checking.
If your camera is sensitive enough, you can run it in movie mode. This means 'taking photos' at 25fps, which means you have hours of 'footage' to check.
If you want to contribute to UKMON (UK meteor watch network) you will also need 'exact' timing data = and that's another issue
You might think that at 25fps you are not collecting enough light, however you can often find meteor tracks on ordinary CCTV 'camera footage' which is shot at 15-30 fps.
To get extra light, the Pi camera can be run in mode 4 ('-md 4') which gives you 1296x972 pixels (4:3) with 2x2 binning and a frame rate from at 1-42fps (so you can go as low as 1 fps without loosing the 'save' time that still images impose). At 1296x972 pixels you will get images a much better resolution than the 'typical' CCTV camera (which is 640x480, or, if you are very lucky, 960x540).
On the other hand, CCTV camera output is analigue AV i.e. 'raw', whilst a Pi camera movie will be h264.
As of mid 2016, the raspistill / raspiyuv utilities limit the (5 Mpixel) Pi camera to maximum 'shutter speed' of 6 seconds (although the Pi Camera 2 (8 Mpixel) max. is 10s). This means 10 photos a minute, 600 an hour or 6,000 per night !
Note that the 'still image' exposures are achieved using a slow 'rolling shutter'. On a 6s exposure, the last scan line of the image will be 'read' from the sensor about 1/3rd seconds after the first (not a problem with stars, could be an issue with meteors !) Although storage might not be a problem (6,000 photos at 2.2Mb ea is 'only' 13.2 Gb) checking them 'manually' will take ages This means some sort of 'auto detect' software, in which case we might as well use it on the Pi so it only 'saves' photos that contain a meteor 'track' (and discards the rest). Note that 'in the old days' you could use 'VHF radiowave back-scatter' to detect the meteor and trigger the saving of a free-running capture - however in most countries the old high-power analogue VHF TV systems are no longer broadcasting = so no more 'back-scatter', no more 'eassy detection' .... Keeping only the 'interesting photos' is exactly the same problem we face when using the Pi camera for CCTV, although for CCTV we call this 'motion detect' (and usually want to do it 'on the fly' when exposing at 4 photos a second (rather than 6s per photo) i.e. some 20x faster ..
One package that 'does the job' is "Meteotux PI", which can be found here.
Using raspistill / raspiyuv (for meteor watching)
Whilst you can run in video mode from 1fps and up, for high quality you have to run in raspistill 'still image' mode. Still image JPEG beats h264 video, whilst RAW is even better - however JPEG's are only 2-3Mb whilst RAW is 15Mb (i.e. at least 5 times bigger). Since the rate at which the Pi can take still images is data rate limited, RAW photos will take at least 5x longer to save
My tests show a maximum achievable raspistill JPEG still photo rate of about 4 frames per second (to ram-disk). Full resolution quality JPEG's are about 2.2Mb each, so you will 'run out of ram' after about 100 photos or 25 seconds. It is thus vital to discard 'uninteresting' photos at 4fps (or better).
Fortunately, a clear night sky tends to be rather 'static' and consists mostly of 'empty space' (black sky) - so the JPEG sizes should be small. When something (a meteor) lights up the sky, the JPEG size should 'jump' - so (in theory) all we need to do is compare the file sizes (in RAM) and only save (i.e. move to SDHC) the 'bigger' ones
We set up two scripts. The first runs the Pi cameras 'for ever', writing the jpegs to ram-disk with a file name = todays date +4 digit serial number. The second checks the file size against some 'empty sky' size and deletes the 'same sized' ones whilst moving the 'different' ones to SDHC.
Only the 'check' script needs to be 'clever' :- loop: Get the ram-disk directory (in ascending order) If the 'file count' is less than 3, jump to loop Check the first file in the directory (the oldest one), if 'large' copy it to SDHC Delete the oldest file Jump to loop
If we run the camera at 4 fps and find lots of 'interesting' photos, there is some danger of running out of ram-disk (as even a Class 10 SDHC card will be hard pressed to do better than 3 fps).
For meteors, this will not be a problem - each 'event' will generate a handful of photos and meteors tend not to arrive 'all at once' :-) This means the 'low end' Pi's with 256Mb ram (of which 100Mb is a practical ram-disk limit when not using the display) are idea for 'meteor watch' use In the CCTV field, however, an intruder might be 'within sight' for minutes at a time - in which case we need large ram-disks and thus a 'higher end' Pi. A 512Mb Pi, with a 220Mb ram-disk has room for approx 100 'full frame' jpegs (at 2.2Mb each). If the ram-disk is being filled at 4fps, and emptied at 3fps, it will 'fill up' at 4-3 = 1fps and thus 'overflow' in 100 seconds (1.6 minutes). Of course, if we are using 'binning', the file sizes will be 1/4 the above (and we have 6.4 minutes before overflow)
Using RAW rgb format (raspiyuv rgb)
You can get the RAW yuv from the sensor converted into rgb by the GPU before saving it. For example, to run contineous 6s exposures, running all night :-
raspiyuv -rgb -tl 6000 -fp --nopreview -bm -ISO 800 -awb off -awbg 1,1 -t 999999999 -ss 6000000 -o %04d.rgb This will generate 'RGB888' which is a byte interleaved format (ie pixel 1 R, pixel 1 G, pixel 1 B, pixel 2 R, pixel 2 G, pixel 2 B, etc.). (RGB565 and RGBX32 also exist, and can be requested via MMAL but not (currently) from raspistill/vid) A nice feature for the rgb888 format is that you can easily "convert" it to a PPM image by adding a header :- P6 2592 1944 255 (where h=2592 and w=1944) To add this header to an existing file (image.rgb), use:- (echo -e "P6\n2592 1944\n255"; cat image.rgb ) >image.ppm this allows many programs to open the image.