Not sure about the offset, but platesolving should work for your 6" SCT. I platesolve with a 10"RC (focal length 2000) plus a ZWO ASI1600 camera, very reliably.
Make sure (a) you are in focus, and (b) you have all the appropriate index files are installed.
You can also try ASTAP if the internal solver is not working?
Can you post an image from your SCT (with the platesolving exposure) and we can see if we can plate solve it?

Hy

Read More...

If you'd like to refocus every hour, you can use the Limits menu on the Capture tab, and make sure you save the change back to your sequence file (the file named L_1h_120s.esq in your picture). Something like the image below, but remember to edit the lines of the capture sequence and click the checkmark, then save the file, like any other change to the capture sequence.



Read More...

Hy Murveit replied to the topic 'Autofocusing the moon' in the forum. 11 hours 50 minutes ago

I honestly am not sure what's in the gradient autodocus scheme. The Linear and Linear 1-Pass schemes depend on star detection, so won't work on images without stars.

Read More...

Hy Murveit replied to the topic 'Artificial Horizon gone bonkers' in the forum. yesterday

Toni,
It is fixed in the latest code.
If you want to fix things in your self-compiled code, just comment out those 4 lines as described above.
Hy

Read More...

Hy Murveit replied to the topic 'Artificial Horizon gone bonkers' in the forum. 4 days ago

Pit,

Thanks for reporting this. I looked into it and tracked down the issue to the following.
I have submitted an MR which will hopefully be merged soon.

I believe you compile from code, can you make the following change and test?
(I'd have you just use the latest code but I don't necessarily recommend you using that right now.)

In the file kstars/kstars/skycomponents/artificialhorizoncomponent.cpp
find the function called appendGreatCirclePoints (starts on line 268)
and comment out these 4 lines which are not far from the top of the function (lines 274-277)
invent.kde.org/education/kstars/-/blob/m...oncomponent.cpp#L274

    // std::shared_ptr<SkyPoint> sp0(new SkyPoint());
    // sp0->setAz(az1);
    // sp0->setAlt(alt1);
    // region->append(sp0);

It is not perfect--it makes little jagged lines near the horizon (which is what those 4 lines fix in horizon mode and were supposed to fix in equatorial mode too), but that is far better than the current rendering mess. I need some consulting to get it totally right, if you have any clue how to fix, let me know!

Hy

Read More...

Ron,
Thanks for your feedback. I sent you a PM. Let's discuss and figure out an approach to improving things.
Hy

Read More...

@David As mentioned above, you should set the "reset pipeline ..." value to 1 or 2 arcminutes and use 1 or 2 frames. That should work as long as your plate solving is reasonably reliable. See below. Reset pipeline could be worded better, for sure, but what it means is re-align and then restart guiding as far as I know.



I'd also check the "dist" checkbox on your Analyze page, so you can see the drift plotted. You'll only see that plot if the alignment check ("reset pipleline...") has been checked for the session you're recording.



With those changes, you likely would have returned to reasonable imaging a few frames after the clouds passed.

I can't tell what version of KStars/Ekos you were using. There were some bugs a while back that caused the guider to incorrectly pulse the mount away from the target. I believe it was fixed in 3.5.8.

@Steve, thanks so much for answering questions. This is a collaborative project--it needs the help of knowledgeable folks like you! Please continue to post.

@Ron Wolfgang has fixed some bugs related to guiding not restarting, and is likely working on others. Message him and see if your issue has been addressed...and please be patient/kind. The best way to improve KStars is to volunteer your efforts. This is an open-source volunteer-based project. If you can code, try to fix the issues. If you can't code, perhaps you can organize the online documentation, do user surveys on improvements to the user experience, gather logs and other useful debugging information for issues that might exist, test proto-releases, ... We do appreciate your bug reports.

Read More...

I'm unfamiliar with that product, but I looked into this issue and did see an issue in the code.
I've sent in a fix for that, and we'll see if it fixes things.
invent.kde.org/education/kstars/-/merge_requests/739/diffs

Read More...

I tried your .esq and .esl files with your geography and times and things seemed to look OK with the schedule.
Is there an issue with the schedule that you are seeing (what I see is below).

You could (should) practice a day or week in advance and make sure things are OK.
I assume you are going to cover your telescope (so you don't wind up accidentally pointing at the sun).

Also, I didn't look closely, but are some of your targets below the horizon during the demo?
You should probably pick targets with positive altitudes.

If you've done any editing to the .esq/esl file, I'd highly recommend you read it in to the program, and then write it back out via the program the standard ways, instead of executing hand-edited files.

I'd also recommend you disable "remember job progress" as I assume you'll restart the job every time it completes (as we don't have a "repeat the entire schedule" feature.
See below



Here is what my screen looks like:



Read More...

Please attach the .esl and .esq files, your approximate location, and the time you want to run the demo.
Also remember that if you have constraints like twilight & altitude remember to set the time to the time you will be running if you are testing in advance.

Read More...

It is the solver itself that determines all these things (shape, SNR, HFR, etc)--at least the first half of the solver, which detects stars and then feeds the star detections to the plate solve code. All this is inside of the StellarSolver library. In any case, in my experience, even if we could do that, determining that the image has star trails etc wouldn't be that reliable and so occasionally waiting 10s for the solver to timeout is likely a better solution.

Hy

Read More...