952 replies to this topic

[decep]

I just wanted to make a quick announcement about the All Sky camera management software I have been working on.  Like many others, when I setup my first All Sky camera, I used Thomas Jacquin's fantastic allsky software.  It works very well, obviously.  My first camera was a ASI290MM, but I wanted to setup a color all sky camera and I wanted to see if I could use the Svbony SV305 [IMX290] camera which is at least half the cost of most planetary cameras in the same class.

 

I think one of the biggest requests for enhancement for Thomas Jacquin's allsky is supporting more than just ZWO and Raspberry PI cameras.  For this reason, I decided to build my software around INDI.  This would have the possibility of supporting any camera supported by INDI.  The SV305 INDI support was about 6 months old at the time I started, but seemed to be reasonably stable.

 

8 months later, I think the software is stable enough to be released:

https://github.com/a...is/indi-allsky/

 

At this point, the camera and image management is roughly at parity with Thomas Jacquin's allsky.  I do not have the fancy web interface, but I do have some simple web viewers.  The software is written in Python and utilizes the pyindi-client for the INDI interface.  Python may seem like a non-optimal choice, but most of the functionality is actually C-based modules (pyindi-client, OpenCV, pycurl, ffmpeg) so most operations are lightning fast.  The code is also implemented using Python multiprocessor semantics, so actions are implemented in parallel--operations like file uploads will not interfere with image acquisition.

 

I have been running both of my all sky cameras with my software for the past few months and INDI seems to be well up to the task for weeks of constant runtime.

 

Features:

• Theoretically supports any INDI camera.  The software will automatically detect the camera on startup (based on the indi servers running)
  • ASI290MM has been extensively tested.
  • SV305 has been extensively tested.
  • Verified several other models of ZWO cameras are detected and will operate.
• Time lapse movie generation
• Keograms
• Day and night time support
  • Special "moon mode" operation reduces gain when the moon is out.
• File upload support
• Automatic image debayering

 

Let me know what you think.

[martastro]

Hi, thank you. I was trying to install the script *not* on a raspi, but rather on a mini fanless pc running ubuntu on it.

at the launch of the script ./setup.sh, I got the error message : Unknown distribution Ubuntu 18.04 (x86_64)..

It should work as the architechture is x86_64

Any idea what I can do?

 

Whatever if it work on my system or not, thank you for the amount of time youve put in this project, its really cool. But for the moment I am stuck, can't test it

 

here an image if that can help

Attached Thumbnails

• 

Edited by martastro, 25 October 2021 - 07:36 PM.

[decep]

I have updated the setup script to properly configure Ubuntu 18.04.  Everything seems to run on my Ubuntu 18.04 virtual machine running the CCD Simulator.

[decep]

Just a further update...

 

Some additional camera vendors are now supported:

• QHY
• Canon DSLRs
• CCD Simulator (for testing)

[decep]

I now have a couple more camera vendors now supported, although, the drivers for both seem to be closely related.

• Altair
• ToupTek

I also have some fairly decent star (blob) detection working to help measure sky quality/cloudiness.

[Raginar]

Is there a way to take in a video feed and use it?  Something with a video capture card?

[decep]

Capturing video feeds is not really the purpose of this project, although its something I might explore for a different project.

[SimVU]

 

• • SV305 has been extensively tested.

Greetings,

 

Seeking clarification. The original post says that "SV305 has been extensively tested", but when I read the Github page it says "40% of frames require double the configured exposure time to complete. Likely a firmware bug."  Is the SV305 a viable camera to use for an allsky build as of December 2021?

 

Thanks,

Edited by SimVU, 11 December 2021 - 09:06 AM.

[decep]

Greetings,

 

Seeking clarification. The original post says that "SV305 has been extensively tested", but when I read the Github page it says "40% of frames require double the configured exposure time to complete. Likely a firmware bug."  Is the SV305 a viable camera to use for an allsky build as of December 2021?

 

Thanks,

I have not quite found the root cause of the issue, but I have made some progress to minimize it.  I reviewed the last clear night I had and found that with my updated code only 17% of the frames were doubled.

 

If money is not an issue, or if you absolutely do not want to miss any frames, I would definitely go with a different vendor.  The issue is really not as bad as it sounds.  I actually went a couple of months before I even noticed the problem.

 

If you already have an sv305 or you can get one cheap, then I still think it is a good option.  Especially considering the conditions the camera has to endure if you build a permanent enclosure.  During the summer, 60-70c is not an unusual temperature inside my enclosure.

[decep]

Seeking clarification. The original post says that "SV305 has been extensively tested", but when I read the Github page it says "40% of frames require double the configured exposure time to complete. Likely a firmware bug."  Is the SV305 a viable camera to use for an allsky build as of December 2021?

 

I will let you be the judge of how the camera performs.  I uploaded the timelapse from both my color (Svbony sv305) and monochrome (ZWO asi290mm) cameras from the night of 12.02.2021.

 

Per my last message, you can see the color version is ~17% shorter than the mono version.  Both cameras have a similar field of view, albeit the monochrome is a bit wider (2.1mm vs 2.5mm lens).  The mono video is a bit better quality, but that is more due to the fact that it is a mono camera and has no visible pattern noise due to the hot pixels being subtracted and the bayer matrix.

 

Color

https://youtu.be/izlUewgaGAM

 

Monochrome

https://youtu.be/5eY_O0fBCkM
 

Edited by decep, 12 December 2021 - 11:27 PM.

[decep]

Is there a way to take in a video feed and use it?  Something with a video capture card?

I was just reviewing the All Sky camera link in your signature, and I think I understand better what you are asking.

 

I still have a lot of work to do on my web interface, but I have a page that loads the last ~40 images (I take 15 second subs, so 10 minutes) and displays the images like a gif.  This uses the HTML canvas functions, so the animation is pretty smooth.  It is like getting an instant replay of the last 10 minutes of sky activity.  The page also loads new images every 15 seconds, so the replay is always up to date.

 

I also have a page that just loads the latest image at a regular interval (no page refresh) to show the latest view.  You could potentially also use the binning modes available in most cameras these days.  You could use a 2x2 bin mode to potentially get down to a 1-5 second sub and have a near real-time view of the sky.

[telfish]

Any chance of supporting the PI HQ camera?

[decep]

Any chance of supporting the PI HQ camera?

I actually just recently purchased a PI HQ camera for this purpose.  The camera is detected and is able to take exposures via INDI.  You have to scale the image down a little to generate videos as the max resolution for x264 is lower than the resolution of the camera.  You also have to run a Raspberry Pi 4 with 4GB of RAM if you want higher resolution video since it requires 2GB+ of memory to build 4K video.

 

That is the good news....

 

The bad news... the PI HQ camera support is a bit wonky in INDI.  If you want to take long exposures, you have take an initial throw-away exposure of 2 seconds or longer (this is already coded in my project).  If you don't, exposures will be limited to 1s even if you tell it to take a 5 second exposure.  However, certain conditions throw the camera off and it starts taking exposures in odd intervals.

 

I do not think this is really an INDI problem.  Even the command line tools for taking exposures exhibit some strange behaviors with exposure times... like requesting a 15 second exposure, but only getting a 12 second exposure.

 

I still have some testing to perform in order to figure out how to keep the exposures stable.  It seems to be fine if you keep the exposures above 2s and do not change any settings like gain during the run.

Edited by decep, 27 December 2021 - 10:28 PM.

[telfish]

Thanks. Will look forward to trying it.

[decep]

Thanks. Will look forward to trying it.

The PI HQ camera support is probably as good as it is going to get for now.  I have done everything I can make the camera take long exposures.  I have limited the camera to minimum 6s exposures in the config example, but you can change this if you want.

 

I have also updated my setup script to disable the Defective Pixel Correction "Star Eater" algorithm and keep it disabled upon reboot.  This also means you will have to take darks to subtract hot pixels.

 

There is also a wiki page I setup to detail some of the issues around the PI HQ camera

https://github.com/a...ry-PI-HQ-Camera

[decep]

Support update...

 

As described in the previous updates, the Raspberry PI HQ camera is now [mostly] working.

 

I have also integrated a feature to generate star trails at the end of the night.  Here is an example:

https://github.com/a...sky#star-trails

Edited by decep, 29 December 2021 - 08:49 PM.

[decep]

I just tagged v1.0 in GitHub.  Included in the v1.0 release is a unified web interface to show the latest images from the camera, as well as basic configuration management support.  There is still much work to be done here, like viewing historical images and videos, but the new interface is much better than the random PHP pages I built.  The web interface is built on the Flask MVC framework, so camera interface and web interface are actually a unified code base built on Python.

 

I have also added Player One Astronomy camera support.  This was the final camera vendor I really wanted to integrate.  The INDI support is actually quite good for a new driver.

 

I do not expect to have many more camera types to integrate support.  I do not think I will have anyone try to use an Atik or SBIG camera for an all sky project. 

[HxPI]

Can images be saved to usb thumb drive during capture? Will ASi294MC work?

[decep]

Can images be saved to usb thumb drive during capture? Will ASi294MC work?

Sure, you can save the a thumb drive by changing the save location in the configuration.  You may have to manually change permissions for the thumbdrive since indi runs as a non-privileged user.

 

The ASI294MC should work great.  The ZWO ASI camera support is fantastic in indi.

[HxPI]

Sure, you can save the a thumb drive by changing the save location in the configuration.  You may have to manually change permissions for the thumbdrive since indi runs as a non-privileged user.

 

The ASI294MC should work great.  The ZWO ASI camera support is fantastic in indi.

Cool I may try it out then. Thanks for sharing

[HxPI]

Sure, you can save the a thumb drive by changing the save location in the configuration.  You may have to manually change permissions for the thumbdrive since indi runs as a non-privileged user.

 

The ASI294MC should work great.  The ZWO ASI camera support is fantastic in indi.

The note about Raspbian 11 not supported by Astroberry is confusing. Can this be installed on RPi with Astroberry and what version is supported? Also, does this work with Raspberry Pi OS (aka Raspbian 11) 64bit? Which is better to install 32bit or 64bit for a RPi3B?

Edited by HxPI, 08 February 2022 - 06:45 AM.

[decep]

For RPi, I would suggest using vanilla Raspbian 10 (Legacy) 32-bit.  My setup script sets up the Astroberry repository for the binary INDI packages.  As far as I know, the Astroberry repo does not support Raspbian 11.

 

If you want to use Raspbian 11 or 64bit, you would have to build INDI from source or find another repository that has pre-built packages.

 

I have plans on adding a script to my project to build indi from source.

[HxPI]

For RPi, I would suggest using vanilla Raspbian 10 (Legacy) 32-bit.  My setup script sets up the Astroberry repository for the binary INDI packages.  As far as I know, the Astroberry repo does not support Raspbian 11.

 

If you want to use Raspbian 11 or 64bit, you would have to build INDI from source or find another repository that has pre-built packages.

 

I have plans on adding a script to my project to build indi from source.

So your script will setup a RPi with Rasbian 10 for Astroberry, including Web VNC interface, and also install the allsky suite? Can I also just run your script on a RPi with Astroberry already installed to get the allsky suite? I’m not a Linux expert hence all the questions. I like the allsky web interface but also really like the Astroberry Web VNC interface for full desktop access.

Edited by HxPI, 09 February 2022 - 08:58 PM.

[decep]

So your script will setup a RPi with Rasbian 10 for Astroberry, including Web VNC interface, and also install the allsky suite? Can I also just run your script on a RPi with Astroberry already installed to get the allsky suite? I’m not a Linux expert hence all the questions. I like the allsky web interface but also really like the Astroberry Web VNC interface for full desktop access.

Unfortunately, the script only uses the Astroberry repository for the indi packages necessary to run indi-allsky.

 

I think some others have run indi-allsky on Astroberry.  I think they had to disable lighttpd as it conflicted with the Apache installation.  The conflict could easily be remedied by using alternative port numbers in Apache.

 

If I have some time soon, I will install Astroberry on my test camera and see what I can do about any conflicts.

[HxPI]

Unfortunately, the script only uses the Astroberry repository for the indi packages necessary to run indi-allsky.

 

I think some others have run indi-allsky on Astroberry.  I think they had to disable lighttpd as it conflicted with the Apache installation.  The conflict could easily be remedied by using alternative port numbers in Apache.

 

If I have some time soon, I will install Astroberry on my test camera and see what I can do about any conflicts.

Excellent. Thank you.