Outta replied to the topic 'Internal Solver stopped working' in the forum. 2 weeks ago

Hi, Me again

I have bought new scope, skymax 127 mak, and it is not solving once again. Everything is default but as i can see it is simply bot selecting real stars, and it is selecting rabdom noise as stars... Any tips?


Hi Jason,

As I read, it is a mixed bag in astronomy usecase. Main highpoint of libcamera is enhanced post processing of the image, and we do not need that in astronomy. It impacts performance a bit bit it could ease up adding new support for cameras, and steaming could be easily implemented. But there comes new issue as libcam-raw can handle max FPS of 40, while raspiraw goes up to 130FPS

Best option for astronomy should be V4L2, but it does not work best with Hi Quality Camera, as controls are bad.

Libcam is future but has some impact on highspeed imaging while legacy driver has good performance but implementation is not the best.

Another benefit of libcam is support for additional chips form likes of arducam like IMX290, and others.
I was looking into it a bit but did but did not get far. Indi-libcam could be named.
Maybe if someone experienced could make architecture/design/simple prototype us amateurs could work on implementation.


Unfortunately not. I can only do PR for 1s fix. That is just one > to >=.

Regarding binning, that is just plain hardcoded as I have no Idea how UI communicates with driver, and for it to be switchable we would need to expand functionality and method signatures to accept additional parameters, and I do not have time to do that at this moment but all my code is in zip, if someone has knowledge, time, and is willing to do it, feel free, I can even explain something if needed.


Outta replied to the topic 'Raspberry Pi HQ Autoguiding?' in the forum. 3 weeks ago

Hi Dash,

First of all please use EDIT button :) you do not have to post a new post for every update if you are latest poster. It will be easier for other people to find helpful advice if there is not too much clump.

I know my guide is not the best in details but I wrote it on mobile phone not on PC so it is a bit harder to do it properly :)
For this either mkdir and upload my code to that folder, or change path in script to location where code is. If you are familiar with GIT github.com/indilib/indi-3rdparty there is guide how to clone it in repository, and then you can overwrite ~/Projects/indi-3rdparty/indi-rpicam with code you have in other thread. i linked above, or manually do changes from this thread.

That is good, from moment it started working for me it did not crash not once, except it lags for 15 seconds when downloading Full Res image from DSLR. I solved that by extending connection timeout in PHD2 to 30s but that is not related to driver it is due to DSLR, RPI bus and processing power.

You can confirm that edit of the driver is working if default resolution is 2028x1520 and not 4056x3040. Also pixel size should be 3.1x3.1


Outta replied to the topic 'Raspberry Pi HQ Autoguiding?' in the forum. 3 weeks ago


I am using astroberry not StellarMate but it is all linux it should be the same or similar enough.

Follow this post, you can download zip of thr file there:


For the first attempt you can maybe try to just unpack zip and type in terminal:
sudo make install
it might work if not follow full guide how to build it.


Hi Craig,

If you want longer exposures you have to fo workaround.

Simon above said you have to tame 7s exposure, but for some reasoj that does not work for me.

For me to enable long exposure mode you have to take two images, first one has to be 10s and second one 15s.

10s will fail at around 6s mark, but seccond 15s will be finished completely and from now on long exposure is activated, untill you restart INDI.

Mind you that enabling long exposure mode will result in much slower download, not recommended for guding. Fine for capturing.


I actually never used. scheduler, but I can try to see will it help, but this should definitely be an option not the rule.



Anyone :) I really like dithering but I do not want guiding to stop :(


Indeed I did play a bit more with that version I sent. I updated pixel size to get accurate SNR, because of "false" hard coded binning I implemented i would get incorrect SNR.

Also I started playing with streaming, for future planetary capture, but did not get very far :) so if you click stream everything crashes, or you can comment out that line so you do not accidently click it.

You do not need to reinstall OS for this, you can easily reset it to default. Keep me updated I am interested how it works for other people as well.


Here is my custom edit of this driver, it is compiled so you can just go to that folder and run
sudo make install

If it does not work go through whole procedure:

Then open Terminal and type this only first time(prerequisite):
sudo apt-get install libnova-dev libcfitsio-dev libusb-1.0-0-dev zlib1g-dev libgsl-dev build-essential cmake git libjpeg-dev libcurl4-gnutls-dev libtiff-dev libftdi-dev libgps-dev libraw-dev libdc1394-22-dev libgphoto2-dev libboost-dev libboost-regex-dev librtlsdr-dev liblimesuite-dev libftdi1-dev libgps-dev libavcodec-dev libavdevice-dev
sudo apt-get -y install libindi-dev
And then type this in
mkdir -p ~/Projects/build/indi-rpicam
cd ~/Projects/build/indi-rpicam
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ~/Projects/indi-3rdparty/indi-rpicam
make -j4
sudo make install


Hi Craig,

Issue is not in fact in resolution issue is in exposure time of 1s. There is indeed a bug in driver with 1s. I have fixed that locally but did not make pull request as I did not test it with regular setup as my configuration is heavily modified so I cannot do true test without returning everything to default, that I am lazy to do.

But to help people out here I will upload my Source Code from RPI right here so other people can build if needed my custom version.

Regarding guiding, I have typed everything I did in other thread, there is still one small thing I am trying to discover, but I have accidently burdened my mounts brain (shorted something on STM32 BluePilll :) ) and now I am waiting for new ones to come.
So uf you start ekos driver, and take 10s then 15s exposure you will "enable" long exposure mode, in that mode download slows down to ~3-4s, but you will be able to take exposures longer than 5 sec, what is important for imaging. As I was doing this by default every time I start ekos I noticed if i do not do that, download is much faster, but I did not find out what impact does ti have on quality of image for guding, due to problem above. If image quality is degraded and SNR is bad I prefer old mode.

Also not to forget, I turned off "noise reduction" in RPI camera using commands:

sudo vcdbg set imx477_dpc <value>
where <value> can be one of:
0 - All DPC disabled.
1 - Enable mapped on-sensor DPC.
2 - Enable dynamic on-sensor DPC.
3 - Enable mapped and dynamic on-sensor DPC.