Well not enough interest to get any replies I see. I have set up my DSLR with an Elgato Cam Link 4 and made some progress on this.
First I spent some time getting ffmpeg to capture via the command line from an HDMI cable connected to the camera. The USB cable connection will only output 640x320.
The Elgato device is software agnostic. I used VideoLan's VLC Media Player to find which /dev/video? device to use. For me that is /dev/video4. This is all done on a linux machine, although a Mac would be similar. The ffmpeg command line I used is:

ffmpeg -video_size 3840x2160 -input_format rawvideo -framerate 30 -i /dev/video4 -an output2.avi

I tried to encode straight to output.ser as SER files are the default for Siril to spit out fits files. That would not work so I tried the above. Siril will ask to convert the .avi to .ser.
This worked like a charm in testing. I then opened up Siril, converted to fit image files and verified the 3840x2160 image size.
Next I tried doing this in Ekos and only had success with 1920x1080. >>>This is when I had both the Nikon DSLR driver and the indi webcam_ccd driver loaded. In other words, a cable to the USB port of the camera and another HDMI cable. This was with the Nikon camera as the main camera and the HDMI video driver as the auxillary driver to it.

However, when I used the webcam ccd driver alone as the main camera, I successfully controlled capture from within Ekos.
Still more testing to do such as using the Disconnect button for the Nikon driver before attempting capture over HDMI.

Anybody else doing this?


DSLR HDMI output capture with Ekos (to increase capture size)

Is there a way to interact with a USB video capture device in Ekos? The resolution available over the camera USB connection is too low. (640x320)
Anyone doing this?


Bill created a new topic ' AM5 Parking' in the forum. 1 year ago

A request about the AM5 Parking function.
I have noticed that if you park the AM5 via the mount control, you cannot unpark it. However, if you go into the indi tab you can select Home, which will unpark the mount. Could this be incorporated for the AM5 mount to just unpark it? Otherwise, I have been using the hand controller to move the mount out of the park posiition.

Just a thought, thanks


I keep getting this error after reaching the physical Alt/AZ adjustment phase of the Alignment tool.
I am not sure I have had tracking on or not. Cound that be the cause?

org.kde.kstars.ekos.align] - "Refresh solver success 0.3s: ra 319.380 dec -0.894 scale 9.59362"
[2022-11-06T21:36:58.870 HST INFO ][ org.kde.kstars.ekos.align] - "PAA refresh: failed to estimate rotation angle (residual 157.875'"
[2022-11-06T21:36:58.870 HST INFO ][ org.kde.kstars.ekos.align] - "Could not estimate mount rotation"

Anyone else running into this?


Thank you for the replies! I don't know if I ever mentioned this was on linux.
I went ahead and re-downloaded the files after I first posted this.

However, today again I was copying the Astrometry files to a usb disk and came across the reason I was having trouble.
It seems the cp command, or at least how I did it, copied incomplete files. Therefore, they were not recognized by Ekos.

I tried rsync -qr src/ dest/ which picked up the missing pieces and properly copied the files over. Rsync is a much better tool!


Thanks for the reply,
I did plate solve almost all the way through the process. I did play around and use 2x2 binning and various exposure times.
I was at the point with the arrows to adjust the Alt and AZ, and past it with a few adjustments made when the error came up.

I will have to try again when the clouds cooperate. I have enabled the logs to provide more information.
I am afraid this may just be terrible seeing but have never seen the error I mentioned before.


The other night I was trying to Polar Align with my guide camera, an ASI290mini at F4. It went well, plate solving and determing a solution for me to work with. Then after several "Refresh" images that resovled, some that didn't, the error came up. {bug?}

"Could not determine mount position."

This was the end of it, the process stopped. I tried several more times and the same failure. Then I switched from the guidescope to my 8" EdgeHD at F10
You may think, as it was pointed out to me later, that I went from easy plate solving to hard. (I was thinking more light, more stars.)

The exact same thing happened with the longer focal length. I got very close to finishing the overall process,only needing to adjust the mount. I did 2 or3 adjustments only to end up with the same error.
I would say the seeing was poor. Transparency is something I am working on understanding in relation to my location. I will say this night was a better one in terms of how many stars I could see nearer to the horizons, but the sky STILL did seem washed out. In other words you could see the bright stars but little besides that. {seeing/transparency?}

Question is: would unchecking "Use Position" have let me continue? {setting?}



The files I am having trouble with are the
These are both 13.6GB

So these were directly downloaded from Astrometry.net but are not accepted by Kstars.
They are also executable, although I don't know what to do with that.
This makes me think there must be some kind of processing done by Kstars when it does the downloading.
I have had success with files downloaded in Kstars and moved to other installations, but not the directly downloaded.
The reason to download directly is because I got an error when trying to download from within Kstars.
I am not sure this particular feature would be in the logs but I will look.

Thanks for the help so far!


So after downloading the huge amount of data from Astrometry.net, I have archived those files to put on other machines.
I have had some success just pointing Ekos to those files in the Options > Configure Kstars > Index Files window.
However, this isn't working for all of them.

Is there a way to force Ekos to see the files are already there?



Bill replied to the topic 'Autofocusing the moon' in the forum. 1 year ago

So to be clear, since this thread is a year old, the Gradient (focus) Process will not work for the Moon?


Bill replied to the topic 'Pi HQ Camera' in the forum. 1 year ago

It may be helpful to read about the PI HQ in the indi-allsky posts on this forum.


I guess this is confusing since Raspbian 11 already has libcamera support.

Would it be safe to say for Raspbian 11 arm64:

Compile indi with build_indi.sh for indilib supported cameras
Use libcamera for Raspberry PI HQ camera


So according to the github page the rpi HQ is supported on Bullseye 64 bit when compiled on device.

Is there a downside to this or is it fully supported by indi-allsky when done this way?