I just enter in the discussion with a simple question.
To focus would it be possible to use the live view of the DSLR instead of successive captures in the looping process ? Which could be less stressing for the material.
And keep the capability to make hardware zooming on live view, like on the DSLR itself ?

Read More...

You might have the unluckiness to obtain an image on two some time more, some time less. It looks like it is composed by the current capture plus the following one. As I understand the capture process for cmos sensors is continuous. So you get the capture you expected for the time you required shifted left and a trailer of the ongoing capture on the sensor. Both separated by a black vertical dark zone. Like the one I posted on qhy forum. I must remind that this happens on arm device with usb 2.0 (in my case the Tinkerboard).

When igo there github.com/qhyccd-lzr/QHYCCD_Linux_New/b...-Ubuntu-armv8.tar.gz I only see a qhyccdsdk-v2.0.11 SDK. I didn't tested it.

Read More...

The problem disappeared quite completely on x86_64 platforms. I have time to time some malformed images. But it still remain on arm platforms. Trying to warn Jan and Qiu on the problem looks to be useless. Nothing evolved since I raised the problem quite 1 year ago.

Read More...

First problem: can't qactivate logs
Second problem:
2018-09-15T08:50:54: [ERROR] StartExposure() failed. libapogee:/build/libapogee3-QRL7Lz/libapogee3-3.1+~201805251757~ubuntu16.04.1/libapogee/Alta.cpp(278):Invalid image status, 1, for starting an exposure:4.
Unable to take a picture.
Does somebody have tested the driver and found what parameters must be adjusted to make it work ?

Read More...

Hello, I am in an observatory at 3000m height. I tried to connect a Star Adventurer on Indi/Ekos.
The connection on Ekos works fine (usig batteries). But I was unable to unpark the mount and have control on it with virtual paddle.
Is there any way to have full control on it and do autoguiding using Ekos ?
Thanx for your answers.

Read More...

My thoughts are with you Jasem. I know how hard it is to lose dear friends. Take any time you need to recover from this sad event.

Read More...

hope the information is inside the joined files this time.

Read More...

I guess that the coordinates recorded in the fits image and the image used for astrometry are inconsistent and may produce those astrometry problems in some conditions. However what you mean with "flag in kstars" ?

Read More...

Hello,
Yesterday the night was clear, so this was my 4th night of imaging in a week.
As I was with some friends on the field doing shots and observing with our dobsons I did not try a complicated target.
So I imaged the double cluster of Perseus.
After polar alignment that was hard to do due to the problem I met with unsynchronised mount stop and capture I targeted to the bigger of the two clusters.
I shot an image and using the fitswiewer I clicked and moved the telescope to the middle of the two clusters.
For some unexpected reasons, the capture session stopped.
I decided to resume the session. So to clear the system, I stopped INDI and kstars and rerun them.
In between the target has moved. After and astrometry sync and pointing the telescope roughly to the place it was pointing previously I decided to make a load and slew to the target with a previous capture.
All the attempts failed. I decided to do it by myself entering the RA and Dec coordinates that I can find in the fit header.
I have done that with the virtual handpad. Follows a goto to the required place. To my surprise, on the map the telescope pointed close to the biggest cluster and not between the two ones.
I was thinking that it could be just a problem of display. I shot one image and... yes the telescope pointed in the wrong place.
I adjusted the place by iterating between captures and move of the scope to have an approximative equivalent framing as first session's part.
After a click and move on the fitsviewer, it looks like the new position is not written in the header of the image .
Joined the logs of the whole night.
Is it normal ?

Read More...

Here are the logs of my last night. I had some troubles at starting of the session: the telescopic leg of my tripod, the one which was pointing to the north has folded without I noticed it. I fixed it after noticing it. After that I have done some more polars alignments. Oddly, the polar alignment worked when rotating to west and failed when rotating to east. Always for the same reason the second rotation begins before the capture ended.

Read More...

Have you tested x11vnc which is the simplest way to access your SBC ?
Are you familiar with shell script ?
I might provide you some shell scripts that might help you to install x11vnc so it could start at boot.

Read More...

O I was sure to have checked it. Maybe the restart of kstars I have done erased the choices.

Read More...

Here are the logs of the last night for the ieq mount and qhy camera and kstars.
Hope you will find, Jasem, what the problem is in those logs.
Best regards

Read More...

The capture start with the rotation, not in the middle.
I mentioned that when I choose west rotation second capture start same time as the first rotation. When east is chosen capture start same time as the third rotation.
I will record logs tonight.

Read More...

I use an ioptron cem60 mount. After the first capture the following one start before the mount stop.

Read More...

Hello PK
You might survey the versions of armbian that works really fine on Rockship platforms as the Tinkerboard. There is no version available today but the nanp PC is a recent. SBC. I guess the specific version will come very soon.

www.armbian.com

Read More...