Hy Murveit replied to the topic 'Does Any of This Work At All' in the forum. yesterday

@astronerd: Solving, in general, should work near Polaris--people wouldn't be able to polar-align near the northern pole if this was not the case. 
I both just successfully tried with the simulator, and also polar aligned on my telescope the other night. In both cased I was able to solve repeatedly.
I tested with ASTAP and internal Solver on the simulator, and used ASTAP with my scope the other night. [All that said, yes, solving is one of those
magic technologies that also frequently causes headaches.]

Debugging with the simulator can be tricky, for sure, and there are many parameters.  I know I had issues when debugging my polar-alignment code with it.
In this case, make sure your focal lengths are consistent (simulator and align need to be using the same--simulator focal length is set in the
Indi Telescope Simulator --> Options tab) and that the gain is high enough (I set the gain to 100 in the align tab and exposure to 4s). 

Read More...

@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, 

 



and also, you'd need to have at least one activated artificial horizon constraint.

 

This doesn't completely solve your request, as the scheduler still is picky about changing the order of jobs, but I believe if you put the jobs in the 
right order you could get what you want. I also added a significant amount of testing to the scheduler, invent.kde.org/education/kstars/-/merge_requests/305 so I'm hoping this will open up the possibility for more scheduler changes in the future.

Let me know if you have have the chance to try it out (currently in the beta software--you know you're running it if you see the "Use Artificial Horizon" checkbox on the Scheduler Tab).

Hy

Read More...

BTW, I agree that this is not the most intuitive UI.
I'm not sure what would be more intuitive, though.

Read More...

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.

Hy
 

Read More...

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.

Read More...

Steve,

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: 
invent.kde.org/education/kstars/-/blob/m...calibration.cpp#L298
or here:
invent.kde.org/education/kstars/-/blob/m...calibration.cpp#L341

I never did implement a calibration "library" or a way to manually edit the calibration.

Hy
 

Read More...

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). 

 

Read More...

Hy Murveit replied to the topic 'Re:Re:Re:Weird guide calibration' in the forum. 3 weeks ago

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.

Read More...

Hy Murveit replied to the topic 'Re:Re:Re:Weird guide calibration' in the forum. 4 weeks ago

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?

Read More...