Close
0%
0%

Asteria Network

Next level citizen science project: an open & global network of low-cost meteor cameras. Goal: explore the Solar System from your home!

Similar projects worth following
NOTE: information on this page is outdated. Check globalmeteornetwork.org for latest.

------------------------------
// Space is fun [citation needed]. How about exploring secrets of the cosmos, but without NASA’s budget?
// Average shooting stars, also known as meteors, are caused by walnut-sized pieces of space rocks left behind by a comet. Observing those fragments as they ignite in Earth’s atmosphere can give us their orbits, which means you know from which part of the Solar System they came from. In cases of very bright meteors (aka fireballs), it is even possible to retrieve a fallen rock! How cool is that?!?
// The goal of this project is to observe meteors, by a global network of CCTV cameras pointed at the night sky. Each camera is connected to a Raspberry Pi 2 running open-source software for video capture, compression and meteor detection.
// In other words, with a meteor station attached to your house you’re exploring the Solar System’s f

NOTE: information in this project is heavily outdated. Please check https://globalmeteornetwork.org/ for more information (station building instructions are on wiki: https://globalmeteornetwork.org/wiki/index.php?title=Build_A_Camera)




You know we could get hit by a rock from space, right? I bet a large rock would do some serious damage though. Help us find them while they are still up there!

Every day hundreds of tons of small interplanetary objects enter Earth’s atmosphere. These tiny fragments can offer us unique view on Solar System formation and evolution. Yet, most of them remain unobserved.

The most common effect that these small objects produce when interacting with Earth’s atmosphere are meteors - better known as shooting stars. If a lot of meteors can be noticed coming from the same spot in the sky during a period of time, we call that event a meteor shower.

Besides offering a good backdrop for summer romances, the most popular meteor shower, the Perseids, are also a very interesting source of information about the Solar System. We know that they originate from the comet Swift-Tuttle. During its many passages close to the Sun it lost a considerable amount of small particles on its trajectory, which the Earth regularly passes through every year in mid-August.

But are there any meteor showers we don’t know from where they originate from, a comet or an asteroid? Can these unknown objects potentially hit Earth? The answer to both of these questions is - yes. Can we do something about it then?

We can observe. We must see what is happening on the sky and in our interplanetary neighbourhood.

With at least 2 of these systems whose cameras are looking at the same volume of the sky, meteor orbits can be calculated. That means you know from which part of the Solar System that meteor came from.

Perseids orbits (CMN data)

Average meteors are caused by walnut-sized pieces of space rock left behind by a comet or were chipped off an asteroid. Meteors pose not threat to us as they completely “burn” out in the atmosphere, but their orbits can be a very good indicator of something bigger on the way.

Very bright meteors are called “fireballs” and sometimes if the conditions are right, and the piece of rock that entered the Earth’s atmosphere and caused the fireball is big enough, you can recover a fragment of that rock on the ground (also called meteorite).

Most of the meteorites that are found today were not observed as fireballs, meaning we don’t know their orbits, meaning we don’t know where they came from. But if you observe the fall and collect the meteorite, you will hold in your hand a piece of a space rock you know EXACTLY where it came from. No need to send an expensive space probe to collect just a few dust samples.

Now the ugly part - that rock you are holding now had mostly the same orbit as its parent body (a comet or an asteroid). The trouble is that sometimes we have no idea what and where that parent body is, or if it poses any threat to us. That comet could still be somewhere in the Kuiper belt and on a collision course with Earth. Meteor orbits will help us by pointing us where to look for unknown parent bodies.

OK, enough fooling around, we can’t hide the truth. The REAL goal of this project is to save the world. But by doing that, we can maybe learn something about the Solar System on the way!

NOTE: information in this project is heavily outdated. Please check https://globalmeteornetwork.org/ for latest.

  • 1 × Raspberry Pi 3
  • 1 × WiFi module
  • 1 × 64 GB MicroSD Card Class 10
  • 1 × Real Time Clock module
  • 1 × USB frame grabber EasyCap UTV007 or SoMagic SMI-2021

View all 9 components

  • 2018 Perseids

    Denis Vida08/13/2018 at 14:07 0 comments

    The Perseids this year were quite a spectacle! Our network is slowly growing and how we have around 10 cameras all over the World - here are images from 3 cameras in Canada and Croatia. About 300 to 400 meteors were detected per camera on the night of the Perseid maximum.

    Elginfield station, Canada, IMX225 camera


    Tavistock station, Canada, IMX225 camera


    Hum station, Croatia, Hikvision Full HD camera

  • 2018 Lyrid meteor shower

    Denis Vida04/23/2018 at 14:01 0 comments

    Our experimential system with an IMX225 IP camera detected 102 Lyrid meteors in the last 2 nights! The image below shows a stack of all detections.

    The concentric circles are stars, the Polaris is in the centre of the image.

    The Lyrids come from a long-period Comet C/1861 G1 Thatcher and they are the strongest annual meteor shower coming from a long-period comet!

    Meteor showers are transient events, but Lyrids are one of oldest known meteor showers, they were first recoded way back in 687 BC. Their activity is usually low (about 20/hr), as it was this year, but sometimes we witness Lyrid meteor storms with over 100 and up to 700 meteors per hour!


    Very soon we are planning to publish details about the IP camera setup and the instructions how to build one yourself. We will also describe the calibration procedure and show that our system can produce science-grade data!

    Stay tuned!

  • First low-cost meteor camera is up for sale!

    Denis Vida02/06/2018 at 16:27 2 comments

    We've been very hard at work in the last 2 years, and we have finally completed the first RPi meteor camera system which is plug n' play and fully automatic!

    Software is thoroughly tested and fully automated, we have upgraded to a RPi3 and a very sensitive IP camera.

    The starting price is only 350 CAD (280 USD, 225 EUR) and the listing can be seen on eBay and will be up for a week! Here's the link: https://www.ebay.ca/itm/173143605844?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1558.l2649

    After this system is sold, we'll assemble more and put them up for sale as well. This is the beginning of our dream of a truly global and open meteor network!

    Here's what you get in the kit:

    • Raspberry Pi 3 in a case with a fan + 3.0A power supply
    • 64GB U3 MicroSD card with Raspbian OS and meteor detection software
    • Low-light 720p IP camera with a 4mm/f1.2 lens (sees +5M magnitude stars) in a waterproof enclosure (heater+fan)
    • Heavy-duty mounting arm
    • Power-over-ethernet (PoE) injector
    • Waterproof ethernet connector protector

  • We are still alive!

    Denis Vida01/12/2016 at 08:52 0 comments

    Dear followers, it's been a long time since out last post and we are sorry about that!

    Just after the last post we went to the International Meteor Conference in Mistelbach, Austria and presented this project to more than a hundred meteor enthusiasts from all over the world! We had a lot of fun at the conference and got very positive feedback from a lot of people about this project. Everybody's keen to have a modern low-cost solution for their meteor astronomy needs. During that time we have been busy with writing the conference paper for the project which you can download here.

    IMC2015 participants

    Shortly after the conference, classes started at our universities so we didn't have much free time to continue working on the project.

    At the beginning of December we finally started to make some new progress. A lot of old codes were rewritten, and now the code is more structured, it is better documented and the most computationally intensive algoritms are rewritten in Cython. This now forms a better foundation for future work.

    Also some progress has been made with the detection of fainter meteors. We still need to put a lot of work into this so the algorithm will be robust. You would be amazed by a wide variety of meteor types. And not to forget a lot of interference like birds, bats, planes and clouds.

    During the following months we will put in more work into this project and keep you informed!

  • Fireball detection

    Denis Vida09/02/2015 at 15:05 0 comments

    One of the most exciting things in meteor astronomy is the possibility to use video meteor observations for meteorite recovery. In 2011, the Croatian Meteor Network was the first amateour meteor network which achieved this by finding the Križevci meteorite.

    As it is impossible to store raw video data with this kind of low-cost system, we perform a unique kind of compression (described in the previous post). As the compression stores only the brightest pixels in a 256 frame block, very bright fireballs can often badly suffer from artifacts produced by this compression method, as there are several moments when a pixel has a certain maximum value (we call the problematic frames “space invaders” - they are shown below the fireball).

    Thus we needed a quick way to extract raw video frames of a fireball while they are still present in the memory. As the data is compressed in real time, we decided to use freshly compressed files for fireball detection.

    Here are the fireball video extraction steps:

    1. The data is thresholded to extract only very bright meteors (aka fireballs) which are 4 standard deviations above the background intensity
    2. The image is divided into 16x16 pixel blocks, and blocks which contain an amount of bright pixels above a certain threshold are marked as bright pixels on the subsampled (45x16) image
    3. As the compressed files contain information about the time (maxframe image), meteors can be show in 3D space (X, Y, time)
    4. Using our algorithm (details are given in the Appendix), lines in 3D space are found and line parameters are calculated
    5. 80x80 (or larger, depending on the fireball brightness) crops are extracted from individual raw video frames and saved to the disk

    The following animation shows the result of the fireball detection process.

    This process enables to have raw video frames which can be used for precise fireball analysis, without saving huge amounts of raw data. We have successfully tested this method and were able to detect and extract a wide range of meteors - from high luminosity fireballs to 0 magnitude meteors. A separate detection process is preformed for even darker meteors which will be described in one of the following logs.


    Appendix: Finding lines in 3D

    Finding lines in 3D space in real time on a device with such a low processing power is not a trivial task. Thus we have reduced the number of search points using the 16x resampling method, which was inspired by Peter Gural’s AIM-IT system.

    The main concept of the algorithm is to pair two points from the given point cloud, fit a line through them and see how many points are there in a given cylindrical volume around the line. The best solution is taken, its points are removed from the point cloud and the process continues iteratively while there is still a significant amount of points left. The solution is evaluated based on the following criteria, each with their own weight:

    • how many points are there inside the cylinder
    • how distant are the points from the fitted line
    • how distant are the adjacent points

    If the adjacent points are too far away, the solution is discarded as this means the gap between them is too large to form a plausible meteor path.

    As the search space consists of both spatial and time components, and it can be assumed that the meteors are transient events which progress in time, the algorithm is optimized to pair points which are not in the same time plane or the ones before.

    The algorithm is currently implemented in Python and limited to 200 points per one image. When there are more than 200 points in the point cloud, 200 are chosen at random. The C implementation of the algorithm would surely be several orders of magnitude faster - we leave this for some later versions of the software.

    The algorithm is quite robust, insensitive to outliers and noise. It can even detect meteors which are partially obscured by trees!

  • Compression

    Dario Zubovic08/05/2015 at 14:43 0 comments

    Now that the question of capturing the data with the RPi2 is resolved, a question of data compression arises. If you were to save uncompressed video on a disk using the current setup (720x576 @ 25FPS), during an average night of 12 hours you would end up with >400GB of raw data.

    So it is clear that some kind of compression should be used. Usual lossy video compression methods are trying to reduce redundancy in video data to suit human vision. Regarding video meteors, the problem is more complex - you need to do your best to preserve meteor features (spatial and temporal resolution and pixel intensity) so you can do meteor detection later.

    Usual video meteor setups have wide-angle lenses and relatively small resolution cameras. Our setup has a 64°x48° field of view and 720x576 camera resolution, which gives a plate constant of about 5 arc minutes per pixel. If you consider that an average meteor is at about 100km distance, one pixel corresponds to ~150m at that distance. This means that the real position of the meteor is actually quite uncertain and you shouldn’t compromise the spatial resolution any further.

    The method we use was first developed by Mark Vornhusen for his Skypatrol software, and later extended by Peter Gural for use with NASA CAMS meteor network. In essence, you are taking 256 raw video frames (10.24s at 25FPS) and saving only the brightest pixels as you can assume the meteor was the brightest event in that portion of time. In addition, you track when the brightest pixel occurred (coded as an 0-255 intensity which corresponds to the frame number), the average pixel values and their standard deviation.

    compressed image of a fireball

    reconstructed video from compressed image

    Thus you have reduced 256 frames to just 4 images (1:64 compression ratio) which you can use for meteor detection as the standard deviation can help you determine what is a meteor and what is the background.

    tresholding (used for detection)

  • Pain with meteor networks

    Dario Zubovic08/01/2015 at 18:13 0 comments

    Having a $100 meteor station in our hands (check out our first log), we realized there is a broader issue with meteor astronomy that could be solved. Currently, there are many separate meteor networks, often on national levels. Each one uses different combinations of software, data reduction routines and storage format. Paradoxically, data is often shared by amateur networks, while government funded (with public money!) networks keep their data as a hidden treasure.

    Meteor radiants plotted on a map of the whole sky (SonotaCo and CMN data). Meteor showers are represented by high-density areas of the same color (Perseids are the orange blob at the upper-center).

    Regardless of what we humans think, universe doesn’t care about national borders. If we were to set out to understand meteors, and through them our Solar System, these limitations cannot get in our way. A truly global network is needed. Such large network raises problems that can only be solved with community effort and open solutions. We are strong proponents of open data, which is still a taboo topic in meteor science.

    As the goal price of a single system is very affordable, we hope that many amateur astronomers, hackers, citizen scientists and students will be interested in the project. The system is envisioned to be very simple to install, use and maintain, with minimal knowledge of astronomy and computer use. We aim to expand that knowledge and introduce people to science and show them the importance of meteor astronomy and foremost - programming.

    We want to provide every high school or university that is interested one or more of these systems, and form a student science team which will work on data collection and processing. As the data will be shared via a central data hub, groups will be encouraged to cooperate with other participants on the project.

    On the other side, many amateur astronomers buy specialized equipment, expensive all-sky cameras and record meteors for their own satisfaction. We are here to offer a low-priced solution with free software which will enable them to fulfill their satisfactions and yet provide useful data to the community.

  • To SBC, or not to SBC...

    Dario Zubovic07/30/2015 at 15:24 0 comments

    … that never was the question. Rather, the question was which SBC shall it be?

    During the last year we have tested quite a few Single Board Computers, as our project has specific requirements. During that time, SBCs have evolved enough to satisfy our needs. In this post, we’ll try to chronologically document our experiences with different boards.

    Raspberry Pi B

    Being the most popular SBC at the time, it was obvious we had to test it. Unfortunately, RPi still had serious USB issues and fairly limited computing power (700MHz single core CPU, 512MiB RAM). With that hardware, we couldn’t reliably capture video with USB frame grabber device nor perform real-time compression. Although there is powerful GPU present (24 GFLOPs), there was no way to utilize it.

    Banana Pi

    Shortly afterwards, Banana Pi came out. The same price range as RPi B, but with a 1GHz dual core CPU and 1GiB RAM. Also, there was a SATA port for HDD. We thought that it will surely be able to do capture on one core and compression on the other. If we could just get that USB frame grabber to work…

    Raspberry Pi 2

    After some time, RPi2 came out. With 900MHz quad core CPU, 1GiB RAM and most importantly a strong community, it caught our attention. This time, we tested it with different USB capture hardware, finally finding an acceptable solution. At that moment software development started and software is growing rapidly ever since. Not only that we had to settle on the capture and compression solution, which would still require us to do detection on a separate machine, but it was possible to completely match capabilities of desktop machines with previous software solutions. Furthermore, we still had enough processing power left to implement new features.

    Same powerful GPU as on RPi B (VideoCore IV) was still used on new board. Turns out that it it’s possible to do some general purpose computations on it, certainly it’s not an easy task. Raspberry Pi Trading: please include OpenCL in next generation RPi! :)

    Odroid C1

    Although we were already deep into development with RPi2, we still wanted to test other available hardware. With same price of $35, but 1.5GHz CPU, Odroid C1 definitely was worth a shot. Amount of available RAM is equal as in RPi2 (1 GiB), but divided across two chips.

    Surprisingly, our compression timing tests showed that it’s actually slower than RPi2 (we’re running RPi2 @ 1GHz). We guess that this is caused by different core (A5 versus A7) or RAM frequency. Another issue is that the very moment when RAM fills up over 512 MiB, it suddenly crashed. The problem here is most certainly in 2 RAM chips and bad memory management between them.

    Orange Pi Mini 2

    $25 for a quad-core Cortex A7 @ 1.6GHz CPU?!? We had to try it. It crashed as soon as we started our timing tests and CPU core went to 100%. Turns out that placing your finger on SOC is same as touching a hot oven. Coolers didn’t help. We didn’t found a way to limit the CPU freq. We’ll post an update when we get our hands on liquid nitrogen…



    Conclusion

    We decided to use Raspberry Pi 2 as the heart of our station as it ticks every single box on our requirements list. Our software will perform faster on next-gen SBCs, but for now we’ll stick with RPi2.

    Linux-suxi project seems promising, but the list of officially supported hardware is quite small, with devices mostly having a higher price and lower processing power. Banana Pi M2 and Banana Pi M3 might be interesting with OpenCL, but community support is nowhere close to the RPi.

  • Terminology

    Dario Zubovic07/23/2015 at 20:08 0 comments

    Our friends at American Meteor Society have made an excellent poster explaining different terms used in meteor science:

  • Beginnings...

    Dario Zubovic07/21/2015 at 20:54 0 comments

    At Croatian Meteor Network, we have always strived for a meteor station to be as cheap as possible. By doing so, network quickly grew to over 20 stations. Having multiple stations covering same volume of Earth’s atmosphere allows precise orbit calculation. Over the years tedious task of manually examining and processing each image was replaced by automated software. Thus, focus has changed from data collection to data analysis. This has led to more than 100 new meteor shower discoveries.

    Triangulation

    But, there has never been complete satisfaction with capture hardware nor software. Current software solutions are often expensive and/or supporting only specific hardware. Most of the software is written for Windows machines, with few exceptions. Almost certainly, software is closed-source, no matter how advanced.

    Currently, if you would like to operate your own meteor station, you’ll most likely end up buying expensive cameras (~$400 per camera) and capture hardware (~$200), as well as a powerful enough PC for running obsolete software. We decided to tackle this issue by developing a flexible and open-source software solution based on 21st century methodologies. Recent advances in field of low-cost single-board computers offer us a replacement for expensive desktop machines without compromising real-time processing capabilities. Also, new generation of low-cost CCTV cameras have the same sensitivity as one order of magnitude more expensive branded cameras. While current solutions could cost you several thousands of US dollars we aim for complete video meteor station for under 100 bucks.

View all 10 project logs

Enjoy this project?

Share

Discussions

jippo12 wrote 09/28/2020 at 11:33 point

Cool project! I made all sky camera that uses raspberry pi and raspberry pi HQ camera. With Meteotux PI software it works great!

  Are you sure? yes | no

Adrien COSTANTE wrote 04/19/2018 at 15:53 point

Hi, I read you use an IP Camera with your ebay project. Does it possible to use an IP Camera with the github project? If yes, how we can do that? On github, you use a analogic camera. I would like to use a raspberry Pi 3 to do that. I bought a 360° IP Camera with imx225 sensor . It's possible to use it? Can you say me how we can proceed to do that? thank you

  Are you sure? yes | no

Denis Vida wrote 04/23/2018 at 13:50 point

H,

we don't have the instructions up yet, I'm thinking about providing a ready image file that can be flashed, as there are just so many details to get right.

The IMX225 can be used, we use it too, but our calibration procedures will not work with an all-sky lens. They are OK up to about 2.8mm (90x50 deg FOV), but wider than that and the calibration breaks down.

I will keep you folks updated when we have more systems to sell or when we publish detailed instructions for IP cameras.

  Are you sure? yes | no

Adrien COSTANTE wrote 04/23/2018 at 14:08 point

Great !! Thank you for your answer.

  Are you sure? yes | no

wyl831211wyl wrote 02/27/2018 at 08:21 point

Hello, I am more interested in meteor monitoring, 

ufocapture has been in the monitoring before, but 

ufocapture does not support ip cams, see your project can 

support ip cams, I would like to ask, what kind of camera 

you are using? Can any ip cam use your program? My English 

is poor. Thank you

  Are you sure? yes | no

Denis Vida wrote 04/23/2018 at 13:46 point

Hi,

sure, we're using IMX225, but I think IMX290 would work too. They are both CMOS. The resolution is 720p, more than that is not really feasable.

We are still working out the details and the instructions how to build your own, there are a lot of details how to get things right and we need to carefully document everything!

Any IP camera should do, but it needs to be sensitive enough to see meteors and enough stars. Also, we are focused on moderate field of vew meteors, not all-sky. This means that our calibration procedures will not work for all-sky cameras.

  Are you sure? yes | no

Haplo wrote 07/16/2016 at 18:25 point

Hi, I have all the components to make the project, but I am a totally newbie with RPI2. Is there any guide to follow for the configuration and the run of software on it?
Sorry my poor English.
Regards.

  Are you sure? yes | no

Dario Zubovic wrote 07/17/2016 at 09:39 point

I have sent you a private message :)

  Are you sure? yes | no

Nelson Saraiva wrote 03/02/2016 at 21:39 point

Hi, here in Brazil we have a Meteor Observation Network - Bramon (https://www.facebook.com/groups/bramon/?fref=ts). We using old PCs with HDDs.

Does a Raspberry Pi would work well, replacing a PC with an external hdd ? 

Thanks

  Are you sure? yes | no

Viva Penguinos wrote 12/03/2015 at 02:19 point

Hi!

I would like to know where you source your camera? Is there a reason why you specifically chose the camera for your platform?

  Are you sure? yes | no

Dario Zubovic wrote 12/03/2015 at 16:17 point

Hello!

We chose that camera because it's cheap and very sensitive (min. illumination 0.001 lux). If you can find anything better at that price range, let us know. :) We're buying it off Alibaba/Aliexpress.

  Are you sure? yes | no

Viva Penguinos wrote 12/25/2015 at 05:51 point

How are you telling the camera apart from the fakes? I see some of the Effio's camera in the range of $20 to $300

  Are you sure? yes | no

frankstripod wrote 08/15/2015 at 21:02 point

The video and system diagram look great. Great work :)

  Are you sure? yes | no

Chris Muncy wrote 08/06/2015 at 11:41 point

Just a quick morning message Dario. I just wanted to say that your project description write-up, is one of the better that I have seen documented on HaD.io. When you start making more progress and have more details refined, I'd love to hop on and get a camera set up in Texas and share in it.

  Are you sure? yes | no

Dario Zubovic wrote 08/08/2015 at 22:44 point

Thank you Chris! We'll have to get in touch soon regarding setting up a station. You can send me your email via private message, just to make tracking things easier.

  Are you sure? yes | no

Lucas Rangit MAGASWERAN wrote 07/30/2015 at 01:09 point

Nice project! Where are you putting the USB HDD and how are you powering it? Also, which camera enclosure did you use? I'm thinking of using http://www.amazon.com/Security-Housing-Enclosure-Outdoor-Surveillance/dp/B00GP13LI6 for a garden monitoring project using a Pi Camera module.

  Are you sure? yes | no

Dario Zubovic wrote 07/30/2015 at 02:36 point

Currently we're using larger SD card and transferring all data every day over FTP. This is to be changed ASAP. I'd suggest connecting your HDD to router, if possible, and use it over network.

Any enclosure will do fine. That one on Amazon looks a lot like ours.

  Are you sure? yes | no

Muth wrote 07/27/2015 at 08:30 point

Interesting !

How do you plan to make video capturing with the raspberry pi ?

I'm searching a sensible camera to capture stars as well, do you have some advice about a model/type ?

Looking forward to see your progress !

  Are you sure? yes | no

Dario Zubovic wrote 07/28/2015 at 15:57 point

Hello,

It really depends on what you are actually trying to achieve. Since we are targeting meteors, we need relatively high frame rate (25fps). In order to capture anything with such a short integration time, we're using high-sensitivity CCTV cameras (something like Watec 902H2 Ultimate, but way cheaper). Those cameras have analogue output. Video is fed to RPi2 via USB frame grabber (basically ADC). Look at the components list. Currently, frame grabbers represent the biggest problem, since userspace kernel drivers are far from functional.

In case you'd like to shoot long exposure photos, we guess a normal cooled astro-camera will work fine. Just make sure that it will work on Linux. Also, it depends which star magnitudes you want. Can you send us more details?

Send us PM if you'd like to setup an experimental meteor station. Some electronics and Linux skills are required.

Clear skies,
Asteria team

  Are you sure? yes | no

Muth wrote 07/29/2015 at 08:30 point

Hi,

Yes, there is a very wide spectrum of spec for cameras. Actually, I'm facing a problem with the large luminosity dynamic. I'm trying to get long exposures pictures, approx. 10min, continuously. During day and night. For daytime, I'm combining short exposures, or averaging the frames. It is working very well with the raspberry pi camera module.

I now try to get as nice images for night time. I can integrate for 10min, then I though I can get images of the stars. I reached the point where a main problem came with the Rpi camera. The automatic gain control software module don't push the camera's setting to the maximum : 6sec exp' time and 800iso, but stuck at 3.2s and 400iso. There, even with a better lens (I try a CS mount 4mm F1.4) It seems the system is not enough sensible, only very few of the brightest stars leave a trail. 

That's why I think of CCTV, modern ones could make HD pictures/movie, there is often an iris on the lens, and some are very low light sensible (I saw some model with 0.01lux).

I'll have a look on Astro camera, and iris lens.

It could be difficult on my actual place to setup a meteor station as I have large mountains reducing the field of view.

Thanks a lot for your reply !

  Are you sure? yes | no

Dario Zubovic wrote 07/30/2015 at 02:49 point

Great video!

CCTV camera that we're using is B/W when in high-sensitivity mode (min. ilillumination ~0.001 lux). Combined with resolution of only 720x576 I doubt that it will fit your purposes.

For your project, hacking some old DSLR (like Canon 350d) might be a good idea. You would achieve high dynamic range trough adjustment of exposure.

Regarding placing meteor station, mountains shouldn't be a problem. FOV isn't that wide and you could just point it higher above horizont.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates