Wireless All Sky Camera





Introduction: Wireless All Sky Camera

About: Most of the things I build usually relate to either astronomy, physics or woodworking in general.

An all sky camera is a device designed to take pictures of the entire sky over a certain amount of time, usually to monitor meteor showers or other astronomical phenomena.

I built mine to monitor the northern lights. I live in the Yukon and we sometimes get beautiful aurora displays during the night. However, I also have a day time job and I need my 8 hours of sleep. I created this camera to record a movie of the entire night. That way, I can replay the movie in the morning and never miss any aurora night.

Step 1: Requirements and Materials

My requirements for this camera are the following:

  • needs to photograph most of the sky
  • needs high sensitivity to low light
  • should be weather proof
  • no wires should run to the house
  • needs to be autonomous
  • needs to create a movie from pictures and upload it to the internet
  • needs to start at dusk and stop at dawn

After thinking about it for a while, I decided that the device should include its own computer and send the pictures using wifi. As for the camera, I decided to use an astronomy camera that would be small enough and was powered over USB.

Here's the list of materials:

  • ASI224MC camera from ZWO (ASI120MC or MM works too and is cheaper)
  • wide angle lens Arecont 1.55 (It gives a wider field of view than the lens that comes with the camera)
  • Raspberry Pi 2 (or 3)
  • 64 GB micro SD card
  • Wifi module (no need if Raspberry Pi 3)
  • Short right angle USB cable
  • 4" ABS pipe with end caps
  • Acrylic dome

I thought about adding a dew heater but after a few month of testing, I never got any frost on the acrylic dome. This is possibly due to the heat produced by the raspberry pi itself.

Step 2: Wiring

In this instructable, I will assume that you already have raspbian installed on the SD card.

The wiring is relatively easy. Plug the USB cable to the camera on one side and the raspberry pi on the other. Plug the wireless dongle into one of the 3 remaining USB ports of the pi. Insert the micro SD card in its slot and plug the raspberry pi to its 5V adapter.

In order to keep things tidy, you can fix your camera and computer onto a plywood board like I did on the picture.

Step 3: Build the Enclosure

The enclosure is made of a 4" ABS pipe, a flat end cap and a threaded end cap with its lid.

The flat cap goes on top and is drilled to the diameter of the camera. The threaded cap goes at the bottom and a hole (for the extension cord) is drilled in the centre of the lid.

The acrylic dome can be fixed onto the top end using weather proof silicone. I used an acrylic ring but it makes things more complex than they need to be.

You can now fix the enclosure onto your deck, your roof or any other location with a good view of the sky.

Step 4: Software

Update: If you need to change the way the capture works, you might have to make changes to the C++ source and compile it on your Raspberry PI. To do this, follow PeterD192's detailed instructions in the comments.

Update 2 (Nov 11th 2016): I have set up a GitHub page with an install script to make things easier for everyone: https://github.com/thomasjacquin/allsky If you use it, you shouldn't have to use any of the following instructions.

Original Instructions:

In order to capture images with the camera, we need to run a program in the terminal. ZWO provides an SDK in order for developers to communicate with the camera. Using this SDK, I modified one of their C++ example and compiled it for the raspberry pi. Here's a list of dependencies that need to be installed in order to get the program running.

  • OpenCV to capture the image of the sky (You can get a compiled version here)
  • Sunwait to calculate the civil twilight of your location. There is a compiled version in the archive. Make sure you copy it to your path:
    sudo cp ~/allsky/sunwait /usr/local/bin
  • Required dependencies:
    sudo apt-get update && sudo apt-get install libusb-dev libav-tools gawk lftp entr imagemagik

To make things easy, I have attached an archive. Extract it at /home/pi/allsky.

From the lib folder, you will need to run this in order to use the camera without being root:
sudo install asi.rules /lib/udev/rules.d

You will also need to add libASICamera2.so to your library:
sudo cp ~/allsky/lib/armv7/libASICamera2* /usr/local/lib

Another thing you will need to do in order to automate everything is to run the main program on startup of the pi. You can open ~/.config/lxsession/LXDE-pi/autostart and add this line:
@xterm -hold -e ~/allsky/allsky.sh

Remember to set your wifi connection in order for the pi to upload videos.

allsky.sh contains all the parameters you might want to play with: GPS coordinate, white balance, exposure and gain.

Step 5: Collect Images

Now that the raspberry pi is ready, you can plug your all sky camera. The startup script should call allsky.sh which in turn calls the binary file named "capture". It will determine if it's day time or night time. In case it's night time, the capture will start and take a picture every 5 seconds (or whatever value you set in allsky.sh). At the end of the night, the capture will stop and avconv will stitch them together and upload a video to your website using FTP.

Step 6: Watch Your Time Lapse Videos

The video produced by avconv should weigh between 30 and 50 mb depending on the length of the night (here in the Yukon, we can get from 18 hours to 0 hours of night time) and should be viewable on any web browser.

In the event that you find something interesting in the video, you can access the individual images on the raspberry pi. They will be in a folder named after yesterday's date.

Here's a page showing my own videos with almost all night archived starting January 18th 2016. Some have beautiful northern light, others have clouds, snow or rain.

Space Contest 2016

First Prize in the
Space Contest 2016

13 People Made This Project!


  • Make it Move Contest

    Make it Move Contest
  • Casting Contest

    Casting Contest
  • Woodworking Contest

    Woodworking Contest

We have a be nice policy.
Please be positive and constructive.


20 Questions


Hi, Thomas. Great share of info.

I am using asi120mc, downloaded allsky.git. followed all through your instruction.Key in Lat Long number. Key in ftp server login . choosen GUI

rebooted. screen showing allsky.sh running. detected asi120. saving 5s exp image every 10ms. press Ctrl C to to stop. and cd '..allsky/' [connecting....]

i go to my ftp server. i didnt se any images uploaded. i go to var/www/html/images or img , also no new image file being uploaded or created

i am lost. please kindly help . thank you

Hi Louis, the images are saved in the following directory: /home/pi/allsky/images/

If the image wasn't uploaded to your server, it's probably an FTP configuration issue. Have you connected to this server before? If not, try to ssh to it in order to add it to the known hosts:

ssh <your-server-url-or-IP>

Run ./allsky.sh again and wait for the ftp debug information to show up in the terminal. It will tell you if the transfer worked or failed.

Setting up a second (colour) unit based on 178MC. Everything seems to be working fine except the timelapse creation is not working (creates 0 length mp4 file). If I run avconv command manually, I get this error:


frame= 42 fps=1.8 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed=

frame= 43 fps=1.8 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed=

frame= 44 fps=1.7 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= x264 [error]: malloc of size 20515824 failed

Video encoding failed

[libx264 @ 0xceda40] final ratefactor: 30.79

Conversion failed!

This is the manual command I am using:

pi@allsky:~/allsky $ avconv -y -f image2 -r 25 -i images/20180410/%04d.jpg -vcodec libx264 -b:v 2000k -pix_fmt yuv420p images/20180410/allskytest-20180410.mp4

individual images did get numbered sequentially and there are no 0-size files. They are all jpg's.

Any ideas?


Hey Dave,

I'm still trying to figure out how the instructables comments threads are organised. I think my answer is still here but kind of hidden. I had to expand an arrow to see it.

Anyway, yes you can resize the images using the Image Magick's 'mogrify' command. Instead of creating a whole new set of scaled down images, it overwrites them. Here's the doc:


You could probably call the command at line 17 on timelapse.sh

3 more answers


Hmmm, Thomas's answer from yesterday seems to have disappeared? Anyway, you were right on the money Thomas. Images are the full 3096x2080 (~1.8M files). And the memory does drop from around 700MB to about 30MB before error (usually gets to about 40+ frames). Interestingly, when I watch the memory use on my 290MM based unit (smaller sensor/file sizes), the free memory also drops from 600-700MB down to 20-30MB (and stays in the range) , but it does not error out.

I found these references:



So I tried increasing the CONF_SWAPSIZE from 100 to 1000 (swap space on SD Card) and it worked. However, the timelapse creation takes much longer to complete (3-4 hours). Not a problem for me as my Pi has nothing else to do during daylight hours!

However, downsizing the images before timelapse processing might be a more elegant solution (as you suggested). Any suggestions on how to downsize images on-the-fly before being fed into avconv? Perhaps an imagemagik command?


I am having a similar issue; real long time to make movies, sometimes works, sometimes it just hangs. I am using an MC120 so my image size is only 1280x960 but still have issues. I am using the same code as above. I get a warning "deprecated pixel format used. make sure you did set range correctly" but it gets past that. It starts running frames and starts to hang around 50-60 frames into the process. I will try running 'top' in another terminal.

I did a reboot on the RPi and it seems to be running better. I am actually running avconv while I am remote desktoped (xrdp). TOP says avconv %cpu 392 (?) %mem 37.9 The CPU chart at the top is mosly maxed out. the %cpu line in TOP - 2nd line

$cpu 32.5 us 0.6 sys 65.9 ni 0.1 id 0.0 wa 0.0 hi 0.2 si 0.0 st

meanwhile it avconv task completed in a couple of minutes, so I am not sure what the issue was?

Hey Dave, What's the size of an individual image? Is it the full 3096*2080?

It seems like a memory allocation issue. There's 1GB Ram total on a RP3. I'm wondering whether avconv is trying to use more memory to build the timelapse than there's left in RAM. You can run the command 'top' in a terminal and run avconv in another. Look for the memory usage.

One way to check would be to scale the images down and try running the ./timelapse.sh script manually again.

Hello Thomas, finally it is working, I face only the high CPU load when I am running the graphical interface and having too short timings, so far I did test the camera having too much light, so it was not representative. I addition, I set more appropriate settings for the camera. the latest problem is with FTP, I get a message telling that the name could not le resolved, I did set the IP address, now I change it by the server name, I will see if it works. Using intercatively the ftp client it is working. I will tell you if I face other problems. So next step, is to build the enclosure, once done, I will install it outside.

I let you know when is works so you can add one more location on your map.

Thank you very much for your valuabe support and best regards.


The cpu is going to more than 80%, all is slow. I test the ASI102Mc with OACapture installed in PI 3, working more or less fine, sometimes the picture in unstable, I would like to know if thos eproblems are only with the ASI120MC, what you write is that with the ASI224MC it is working fine, if it is the case I purchase the other one. I juste want to have the AllSky camera working and user what you have so well developped. Thank you for your feedback. Best regards. Daniel

I will check my CPU load tonight. In the meantime, you can type "top" in a terminal to see which process is taking all the cpu.

Dear Sirs, I have finaly get some images using the ASI 120MC, but the PI3B I am using, is sometime overloaded, what is not a good sign, is the problem only with the model 120MC or is it with all ZWO models? I test on the RPI3B an ATIK GP camera, it was working fine without any problem, Could this camera be used for the AllSky application? Thank you very much, I am not a Linux specialist, so some question I can have will sound basic. Best regards


Hi Daniel,

When you say overloaded, what do you mean exactly? I do not own an ASI120MC but I know it works fine with a P3 and ASI224MC. In theory, the ATIK camera could be used but it would require a custom capture.cpp using ATIK's SDK. Currently, the app is only using ZWO's SDK.

I've installed on a Pi 3 with the latest version of Stretch. I'm getting nothing but black images. Not even sure where to start troubleshooting. Camera is a ASI120MM-S

Hi, the logic for day and night behaviour is in capture.cpp between lines 483 and 502.

You can copy lines 484 to 492 into the DAY conditional statement. That way it will save both during the day and at night. However, it will use the same exposure.

ZWO provides 2 functions in its SDK. The first one is the single exposure mode which is the one I'm using. It doesn't have an auto-exposure feature. The second mode is the video mode which has auto-exposure. I haven't tried it yet but I am planning to. It will require a few changes to the .cpp file.

1 more answer

disregard. there is a default image preview and since it was daytime, it wasnt updating the image. Ok, next question, any way to do auto exposure so I can capture during the day? Not too important, but nice to have, and then how do I override the daytime no save?


I've got a pi 3B setup as described in the git readme, all seems to be working for the most part. Poking around I noticed dmesg showing a lot of USB device resets - about every six seconds for device 4 and my exposure time is 5 seconds with 10ms delay. Just wondering if anyone else is seeing these? I haven't tried a different USB port on the pi for the camera yet since it's currently mounted outside.

[Mar19 21:06] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910084] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910069] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.900074] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.919992] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.900148] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910138] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.909947] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910164] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910020] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.900001] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[Mar19 21:07] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910126] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910071] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910010] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910070] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910099] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910067] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910105] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.900006] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910110] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[Mar19 21:08] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910023] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.880182] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.909952] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910091] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
pi@allsky:~ $ usb-devices

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=04.09
S: Manufacturer=Linux 4.9.59-v7+ dwc_otg_hcd
S: Product=DWC OTG Controller
S: SerialNumber=3f980000.usb
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=9514 Rev=02.00
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA
I: If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub

T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=ec00 Rev=02.00
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=smsc95xx

T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=03c3 ProdID=120a Rev=00.00
S: Manufacturer=ZWOptical company
S: Product=ASI120MM
S: SerialNumber=00000
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbfs

pi@allsky:~ $

I am also running the120MC camera, I do have those messages but I believe each one has a timestamp and there are so many only after so many times of accessing the camera. Stop the allsky program, and clear the messages with sudo dmesg -c. then start the program again and you will see a reset for each camera access (even if you are not capturing images due to daytime). I have not tried to track this down in the code but I am sure it is there somewhere. It does not seem to effect the performance as far as I can tell


3 more answers

I believe it's happening once per capture cycle (exposure time + delay time), and they are still occurring during daylight hours because the capture code is still doing a capture, it's just not saving the captured image during the daytime. The message is coming from the kernel, and I believe the dwc_otg is related to the pi's USB driver. I also have a ASI290MC and it puts the same messages in the dmesg log. I agree - it doesn't seem to be affecting performance/function other than filling up /var/log/messages.


Thanks for checking - I wonder if anyone else that has a 120MM/MC is getting these? I still need to try a different USB jack an a different pi.


I checked on my camera and I couldn't see any messages like that in dmesg. Does it seem to impact the performance?


Hi Thomas,

Thanks for this wonderfull project! I built it with an ASI120MC, but I seem to have an issue every now and than. The palette of the camera sometimes has only about 16 coulors. After a reset it is usually OK again. Please have a look at this movie of one of our short May nights, at about 18s I reset the RaspberriPi via the web interface.


What could be the cause of this?

Thanks for any insights.

Best regards,


PS I attached an image of my camera, made of a piece of 6 inch drain pipe.

2 replies

Hi Albert,

Thanks for sharing the video and a picture of your camera. You seem to have a good dark sky at your place.

I have seen the issue with the indexed colours before and I believe it happened when I was starting and stopping `./allsky.sh` manually multiple times in a row. My theory is that some process was duplicated (most likely `entr`). I am re-writing that part of the code in version 0.6 to minimise issues like this one.

Also if you're logging to the Pi using VNC or remote desktop, it may launch another instance of `./allsky.sh`. A future version of the code should also take care of that.

Let me know the colour issue happens again and if you find a way to reproduce it.


Hi Thomas,

Thanks for the explanation, so my camera is probably not the problem.

What you are saying sounds very logical and it could well be the problem. Regularly I log in with VNC so I will try to avoid that in the future.

For now I will reboot the camera once again via the web-interface and leave it running til morning.

I can't really complain about my sky, but at the moment there is only astronomical twilight here at 53 degrees north, so it could be even better. Even so I moved my telescope to a remote site where the sky background is even one magnitude darker.

Thanks again!

Hi Thomas,

Just started building one of these in Winchester UK. Got the Pi and ASI120MC all up and working together thanks to your excellent tutorial. Mechanicals next. I also plan to add a temperature/pressure/humidity sensor to the pi to collect a bit more info. Many thansk for posting the project


1 reply

That's awesome Vern! Please send a picture once you have completed the project. I love to see what builders come up with. I'll add you to the map.

Thank you again Thomas. I downloaded last nights images and used a desktop program to build the star trails. At any rate I couldn’t have done that without your project. THANKS.

Here’s my finished box with dome heater.

5 replies

how'd you go about building & powering your header line? been looking for ways to combat dew & frost on my end (not gonna be too much of an issue in about a month.. but just want a solution for now). have thought about trying to automate it (calculate dewpoint and start a heater, or something like that), but it's a bit beyond my knowledge so far.

Looks like a solid waterproof case... with heat as well! kind of like the "Deluxe" allsky enclosure. Have you tried setting the startrails treshold to something higher than 0.1? Maybe 0.3 would work in your case. Keep me updated. I'm curious what settings work for users.

I just so happened to try 0.3 last night. Star trails built and look great.
I haven’t gotten a keogram in a few days. Not sure why.
I did get a perfect timelapse too. Startrails and a timelapse of an entire night all from the pi with no intervention. Progress. Super excited!
I linked to your project in every timelapse description. The auto upload to YouTube is also working perfectly.

Excellent, glad to hear that.

For the keogram, I have a theory.

If you use a long exposure, the first image can be all white. In order to optimize disk space, image magick stores this image in a greyscale format (only if using dark frame subtraction I believe).
Then, when you reach image 5 to 10 or 15, it's no longer completely white so image magick returns an RGB image.
The problem is that the keogram script is setting the output target to the same colorspace as image number 1. So when it reaches image 5, 10 or 15, it's trying to put RBG into a single channel image.... which fails.
My current fix is to add "-type TrueColor" to line 23:

convert "$FULL_FILENAME" "$DARK_FRAME" -compose minus_src -composite -type TrueColor "$FILENAME-processed.$EXTENSION"

In the meantime, if you want to re-generate the keograms, you can delete the first few images of your sequence and run the command manually.


This has a fun project! I am using a ASI120MM. A couple of things I have learned and some questions....

Its important to remember to update the drivers on the 120* cameras - you get the segmentation fault on line 20 of allsky.sh if you don't.

In my current configuration the bottom of the camera about level with the bottom of the dome, so all of the camera is in the dome. This puts the camera lens (stock lens) pretty close to the dome which seems to make for stretched out stars around the edge of the image. I guess this makes sense since the wide angle of the camera is looking through more of the dome. I'm going to make a new longer enclosure which I hope fixes this.

Are there any concerns with leaving this out in the daytime and having the sun shining on the sensor? What about heat building up in the enclosure?

I noticed in the upper left corner where the time stamp appears in white, I've also got another timestamp in yellow (only shows up as the image brightens) - photo attached. What's putting that there and how do I get rid of it? It doesn't change either.

One last one - when I went to check on the pi/camera this morning I couldn't ssh into or get to it via the web interface. My router said it was offline. I had to power cycle it. Does the pi go to sleep after a period of time?


6 replies

Hi Mike,

Thanks for the feedback. Yes, USB2 cameras need a firmware upgrade in order to work properly. I believe I added a note in the Readme file on GitHub.
For the dome, it depends what diameter you're using. In my case, a 4" dome doesn't add too much distortion to the horizon because the lens is close to the center of curvature. Moving the lens away from the dome will lessen the distortion. I also find that the stock lens that comes with the camera isn't really sharp on the edges.

I haven't had any problem with heat and sunlight on the sensor. The camera has been running fine for 2+ years. If you live in a hot place, you could paint the tube in white to minimize heat accumulation.

Are you using vnc or remote desktop to connect to the RPi? If so, you may have 2 instances of "capture" running. The camera auto starts at boot but you can disable the autostart if you need to.

The pi doesn't go to sleep. If it's not showing on your router, it may be slightly out of range. A dropping connection can come from various reasons. Try moving the camera closer and see if it still works in the morning.

Thanks for the suggestions. I'm using some white PVC so I'm about as good as I get with tube color!

Still not sure what causes my lost connection to the pi, still working that. I have a strong wifi signal so i don't think that's it. I'm either connected to the pi via the allsky GUI or ssh'ing to the pi. A 'ps' only show a single instance of allsky.sh running.

I am wondering if the wifi instability is somewhat related the usb reset messages you're getting. I don't really have suggestions about how to debug the issue but in my case, wifi is reliable and I don't see anything abnormal in dmesg. Is the wifi also dropping without the camera plugged in and without allsky.sh running?

No connection problems for several days now. But I'll still investigate a bit when I get a chance.

Found the pi unresponsive a couple of times again. This last time I noted that the keogram and startrails had been generated but not the video (zero length file I think). I see there's a note near the end of allsky.sh about pi 3's having an issue with timelapse creation - might we worth a try to uncomment the cpulimit line for a bit.

You can try to run ./timelapse.sh manually and look at the output in the terminal. There might be some useful messages. The latest change on that file was the addition of "-pix_fmt yuv420p" in order to make it compatible with some adobe product. You can try without it.

I added a Real Time Clock to my Rpi 3 as the firmware clock was not keeping the correct date and time. I have been using ImageMagick to enhance the images from my ZWO120MC. I admit I have not played around much with camera settings other than to set exposure, but the results were less than impressive even for 10 sec subs. I have written a script to stretch the image data and enhance brightness and contrast. The results are an improvement over the raw data. I am post processing the images (on a pc) in bulk and then creating the movie using ffmpeg. I like the results and I may mod your software to preform the enhancement on the fly. I am still bothered by condensation on the dome and looking into some form of heater to keep it dry. The question is were to get the power from for the heater as I don't want to draw power away from the Rpi and there is not a lot of room left in the tube. I will come up with something.
coords: 35.02N 76.7W

1 reply

Ronald, there was a recent update to the code that may fix the tearing in images. It is using a newer version of the ASI library and it now compiles statically. It may solve your issue with broken frames.