Hi all,

It has been a while. I got an asi2600mm recently and am trying to get it running. Hooked up all the cables, started kstars / ekos on my laptop (worked fine),
connected to my pi and started indiserver with :indiserver indi_asi_ccd indi_ieq_telescope indi_asi_focuser
and that worked fine too. I tried to look at / set the camera module in ekos to an asi 2600 and it did not want to respond like it knew about it.
So I thought I would upgrade software. Got kstars up to 3.6.1 from 3.5.6 and that appears to be fine.
I have indi-full version 1.83 on the pi and I am trying to update it, but I get this when I run apt-get update :

Err:4 www.astroberry.io/repo buster Release
Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 443]
Reading package lists... Done
E: Repository 'raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: The repository 'www.astroberry.io/repo buster Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: Repository 'archive.raspberrypi.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

So I can see that the certificate has expired. But I wonder if I can even get the current indi-full since the repository is "oldstable".
Can this be updated to current? I realize raspberrypi's are hard to get these days, but some of us are still using them.
It is nice to leave the pi on the telescope out in the cold.

Thanks for your help,


I am currently using Linux Kstars 3.4.1 and ekos indi controls panel tells me the indi_asi_ccd driver is 1.6.
I am working with an ASI290mc, but I don't think that is so important.

I have looked at many ZWO camera manuals and I know that a number of these cameras can be set to run in different ADC bit depths.
I am just going to assume USB 3.0 here, because that is what I use, I know there are USB 2.0 slow down penalities.
I also know that these cameras also support Regions of Interest (ROI), when set in these cameras, it will increase the possible fps or shorten the possible allowed exposure of the camera.
I know that all of these items: ADC bit depth, USB 3.0, ROI all affect fps or exposure speed, and they map this out in tables in the ZWO manuals.

I know that ekos capture module has frame size and frame offset (X and Y) so one can literally take a smaller than full camera frame size pic and center (or not) the item of interest.
I think these settings / abilities are unrelated to ZWO's ROI and will not give the higher fps they mention. True?
I know that the indi controls panel shows ADC depth under the image info tab when the camera is connected. But it seems like there is no way change that.

I have downloaded ZWO's asiStudio software recently and can see that they can change all this stuff easily. I realize you may not be using the same ZWO library that they are.
I have done a search of this forum and have not seen much about any of this, but I have seen somebody mention an SDK and some custom property like HighSpeedMode and 0
representing the highest ADC bit depth. Perhaps there is another one for ROI? If there is a way to set these properties in Ekos, please tell me how? I have seen custom properties in the capture module but I don't know if it adding new properties would work and what their values would be to make this happen???

I don't know if new releases have addressed any of this?
I still love this platform and want to use it as much as possible!


Thanks for your attention. I did not mention that I have been doing visual astronomy for ~ 20 years at this point, but astrophotography is relatively quite new (~ 1 year +).
So I am still learning many things. I have had many issues with setting up the scope and photography platform and learning to operate it. So I have not spent much time at all on the
results end and the post picture processing side of this. So I am really not familiar with all the abilities of the FITS viewer and stumbled into them very recently, like I said. My opinion of
the FITS format has gone up considerably in the last week or so and I really appreciate that kstars / ekos seems to be doing a serious job filling out the header information. And I do appreciate
the histogram functions, but I still need some more explanation of that. So when I saw the single channel output and noted it was red only, I thought there was a problem. After looking at it and
working with it more, I understand now and it makes sense that the capture process would create a single channel picture with all the data in that one array. The debayer pattern is there and shows
rggb and I can now see that when I invoke debayering in the view (one way or another) the viewer then shows me all 3 channels like I would expect. So I think everything works, and I understand more now. So I won't post a picture, because I do think everything is normal and expected now. I am still confused about the histogram. This may be partly because I have seen and worked with the asi-air product (my astro friend has and uses several of them) and their histogram, in which you can stretch and restrict the color frequency range of the preview picture before you save it. He manages to take relatively great pictures, preview only, and frequently skips the whole stacking / picture post processing stuff. And yes, He has spent a lot of money on his platform to be able to do that. I prefer your approach because it really supports Linux, supports many vendors cameras, and I very much like having full access to the raspberry pi, which asi-air does not allow. I believe that your FITS viewer histogram shows intensity along the bottom of the graph and since my camera is doing 14 bit a2d conversion (0-15k) I can see essentially how much signal I captured in the picture, allowing me to decide if I could capture longer or if I am reaching saturation. The frequency on the left side is the one I don't really understand. I generally see (after debayering) all three channels spanning the frequency range to similar but differing amounts. I know that r g and b have specific and separated frequency ranges and the bayer filter inside my color camera restricts the specific pixels to those ranges. So I think the frequency scale you show on the left side is some other kind frequency and since its units are not really disclosed, I'm not sure what we are trying to tell me about frequency.
Please let me know what you think about the histogram and frequency.
Thanks VERY much!


I would say that I am an ardent Linux user (5+ years), I have also been a raspberry pi user off and on for as long.
I wanted to find a way to do astro photography a year ago and was VERY HAPPY to find kstars / ekos / indilib as a way of doing that.
THANKS VERY MUCH for creating this platform, REALLY, SERIOUSLY. I have watched many of Jason's UTube videos, THANKS
VERY MUCH for those.
Apologies if this is the wrong place to post or this question has been asked and or answered, I am brand new to this forum.
I set up my own raspberry pi about a year ago with indilib 1.8.3, indi-bin reports as 1.8.4. I have been running an asi294MC color camera
and an ioptron CEM60EC connected to it. My laptop runs linuxmint 18 (cinnamon, not kde) and I have kstars/ekos installed there.
I have astrometry.net installed and working on the laptop, I can connect everything up AND IT ALL WORKS! I can capture images.
It has been an uphill climb. I only recently found out that the icons in the menu bar do not show up in kstars or the fits viewer and when I
corrected that to show text, I found out that the fits viewer had a histogram feature I did not know about, and when I looked at that, I
found that it only shows me red channel data, green and blue are zero. I have only shot about 20 or so pictures over the last year and
they all looked sort of black and white and I did not know why. The histogram seems to confirm this in showing only a red channel.
I have looked at many of the pictures I have taken, and they all show red channel only histograms, the header info does show a
bayer pattern of rggb, so something might think it was a color shot at some point.
I do not have a filter wheel, that is set to nothing. I do not know see any way in the ekos capture module to identify the capture as being
from a color camera, so I assumed this was inherently done somehow. I have turned off debayering in the preview fit configuration info.
I am confused now. I am will to do any logging if that is desired. Is there any place else to set something? HELP !!!
Thanks for your attention.