@Bart: I just submitted invent.kde.org/education/kstars/-/merge_requests/365 which uses the artificial horizon constraints in scheduling.
If activated, it would delay a job until the target is above the horizon, and stop a job once it falls below the artificial horizon.
To use it you both need to check a new checkbox and include that with your scheduler job, similar to the way you'd include an altitude constraint,
BTW, I agree that this is not the most intuitive UI.
I'm not sure what would be more intuitive, though.
If you stop the scheduler and double click on the job (i.e. the line that starts "NGC 7000 Scheduled 1/45 ..."), is the twilight restriction checkbox checked again?
If that is the case, then it is "working as intended" and here's what's happening:
The twilight restriction is stored as part of each scheduler job. Once a job is setup and added to the scheduler's job list, unchecking the twilight box below would have no effect. To make that change you would need to double click on the job to signal you want to edit it, then uncheck the twilight box, then click the "Apply Job Changes" check box (the plus sign to the right of the magnifying glass becomes a checkbox when you are editing the job). If you are storing that job for re-use, then you'd also want to save it at that point. This same UI is used in the capture tab.
When that happened to me recently, the issue was that the file system I was saving to (a fast usb stick) was mounted read-only for some reason (and the previews were being stored in a different place, a temp directory on my main SSD which was correctly mounted read-write). To check if this is the case for you, test to see if you can create a file in the same directory that capture is saving its images. The fix for me was to reboot, and the stick drive was mounted read-write the next time.
I placed the stored calibration in a string in the same storage mechanism used for all the options you can set (e.g. the same place as the binary flag that says to reuse the calibration).
Its key is SerializedCalibration: invent.kde.org/education/kstars/-/blob/m...rs/kstars.kcfg#L2515
Honestly, I don't know where all those options wind up being stored. Perhaps one of the other developers can comment.
If you want to know the calibration values, they are shown in the calibration tab of the internal guider's options menu.
You can see the entire serialized calibration string if you enable the debug log for guiding, and then look at the .guide entries when your calibration succeeds.
The format of that string is shown here:
I never did implement a calibration "library" or a way to manually edit the calibration.
Check out this thread: indilib.org/forum/general/8994-headless-...pberry-pi.html#68256
I was using a raspberry pi, but running Ubuntu not Raspbian, so hoping the solution there is the same for you, whether RPi4 or mini PC.
Please report back on your choice of mini pc and your review of its performance relative to a RPi (and hopefully relative to an RPi with SSD).
I agree, but not 100%. I guess it depends on the reverse RA pulses, and how they compare to the tracking ones. I believe you can get that info directly from the debug logs if you have the indi mount logs enabled, and perhaps that depends on the particular mount driver.
Also note that you can configure the strength of the calibration pulses in the calibrations options menu.
My guess, but not confirmed, is that you can overwhelm the tracking with e.g. 1000ms calibration pulses. I don't know how you set yours.
If you can get the logs to show, let us know what you find out.
Alfred, Sorry about your back. Hope you get better soon. Let me try my theory one more time. I agree with you that for RA going outward/westward, there would be no backlash. I was talking about RA going the opposite direction as normal sidereal tracking. With RA+ you'd get the full push, but with RA- you'd always have backlash since you are going opposite to tracking. That seems to be what you experienced. Does that make sense?
I’ve done both successfully. Found that if you connect the SSD to the RPi4 directly, it boots a little faster.
@Alfred re asymmetric RA motion:
No expert here, but here's a theory.
The mount is tracking in RA, so, RA has no backlash (it's constantly pushing against the gears).
When you give it RA+ pulses, you get the full push.
When you give it RA- pulses, you will go against the normal RA motion and so reverse motion and realize some backlash.
This backlash will cause the system to lose some "push" as compared to the other direction.
The DEC calibration (assuming you have the DEC backlash box checked) removes backlash on the way out, but not on the way back in (where no measurements are made). Dec isn't constantly pushing the way RA is, though, so DEC will eventually overcome the backlash on the way in, but because of the constant tracking RA motion you may always fight backlash in the RA- direction.
Haven't thought deeply about this, does that make sense?
I could take a guess, but also not experienced with DSLRs on Ekos.
DSLR drivers used by Ekos are almost always the gphoto library.
If we look at the cameras supported by gphoto: www.gphoto.org/proj/libgphoto2/support.php
you can see that the D600 is listed. The D5100 is listed as "PTP mode" and there is a Nikon J4 listed, but is that the same as Nikon 1 J4?
As far as PTP (which apparently is en.wikipedia.org/wiki/Picture_Transfer_Protocol), I'm not familiar with that. Is there something you need to set in your camera to make it respond to the PTP protocol?
Probably the simplest way you can debug this, if you were interested in pursuing it, and you were comfortable with running linux command-line programs, would be to run the gphoto client as a stand-along program outside of Ekos. If that can't manipulate your cameras, then for sure Ekos won't either.
Hope that points you in the right direction.
Please explain (I have never actually seen that application-style menu).
Does Analyze work better with one style than the other?
Which is good/bad?