Ron DeBry created a new topic ' Scheduler priorities' in the forum. 2 weeks ago

I'm still having trouble sorting out exactly how the scheduler works.
If I have 2 jobs for the night, and I want to have one start only once the target reaches a certain altitude, it seemed logical to set up:

Job 1 Higher priority number (say 10), only constraint is twilight. Job takes about an hour, have it repeat until terminated.
Job 2 Lower priority number (5), constraint twilight + Alt > 37°, repeat as desired

When I do that, the scheduler marks Job 1 as Invalid
What should I do differently? Thanks

Read More...

This is new to me in just the last couple of sessions. In the INDI control panel at the start of the evening the Rigelsys NStep reported 12°, the capture sequence was set to refocus on temp delta > 1°, and by 4:00am (when I woke up to check on things) the reported temp was 9°. No autofocus run happened during the session, aside from the one at the start of the sequence. I can test in the next few nights if setting a refocus time will serve as a workaround.

Is there a different log setting to see if the temp sensor is getting polled? At the end of the initial autofocus run there is a line in the log that says "Temperature = -10.1°" - which is the QHY183C's sensor setting.
 

File Attachment:

File Name: log_20-08-34.txt
File Size: 1,491 KB

 

Read More...

So back to this, with particular questions about PHD2.

Since starting to use the scheduler with repeated ~1-hour jobs set to re-try on failure, I have had a few partly cloudy nights but never yet had PHD2 act in a way that triggered the sequence job to abort/restart. Instead, capture aborts (because guiding is out of limits), PHD2 continues to "guide" even though it can see only a few, if any, stars. When the cloud passes by and guiding gets back within limits, capture restarts. That is fine, except I think the point of abort/restart is to allow a re-alignment to deal with the mount drifting off target during the cloudy break.
Is there a PHD2 setting I should be looking for to help trigger the scheduler to abort the job?

Last night I had a particularly vexing PHD2 behavior with clouds. The early part of the night had several episodes of cloudy crummy guiding, but I was getting enough successful 4-minute exposures to keep going. Tried to get some sleep. Woke up to discover this:
 


The guide camera view showed that there were not currently clouds, but the guide star had a huge HFR. I guess it latched onto a really bright star when that was what was visible, and never let go. I stopped and restarted guiding, and it turned into this:
 

If I had not woken up and checked, I assume it would have continued trying to guide on that same bright star.

Read More...

Thanks. I'm definitely the "only update a working system if you know the new version has something you need" type. Unfortunately, the astroberry forum here has several reports of problems with KStars 3.5.4 that I'm not sure would affect me or if they have been fixed (failure to connect the mount to PHD2, for one). Maybe it's time to graduate from astroberry and start building my own - but it's the beginning of my Fall term (teaching), so that's not something I will have the mental energy for right away.

Cheers,
Ron

Read More...

Hi Wolfgang - sorry to confuse you by being another Ron :)

I have been using your settings for a while, having seen them in another thread. I have yet to encounter clouds sufficient to trigger a job abort / restart, just lots of capture aborts due to guide deviation. Including last night.

Last night I ran into another issue - when I woke up to check on things, the scheduler was stopped, no guiding was going on and the last note in the scheduler was that the meridian flip was successful. Looking at the part of the log just prior to the flip, it turns out that capture was already suspended due to guide deviation, so (apparently) once the flip completed the scheduler simply suspended itself(?). Is this the expected behavior? Is there any way around it, other than being awake at the right time?

In the part of the log below, the entries starting at 02:23 are from when I woke up and manually stopped then restarted the scheduler.

[2021-08-22T01:34:05.190 EDT INFO ][   org.kde.kstars.ekos.capture] - "Guiding deviation 3.110 exceeded limit value of 2.5 arcsecs, suspending exposure and waiting for guider up to 60.000 seconds."
[2021-08-22T01:34:05.220 EDT INFO ][   org.kde.kstars.ekos.capture] - "CCD capture suspended"
[2021-08-22T01:34:05.259 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Suspended"
[2021-08-22T01:34:05.505 EDT DEBG ][     org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "21h 59m 28s"  scope RA= "21h 51m 28s"  ha= 0.133496 , meridian diff= 0.133333 , hrstoFlip= -0.000162427 , flipDelayHrs= 0 ,  "Pier Side: West (pointing East)"
[2021-08-22T01:34:05.505 EDT DEBG ][     org.kde.kstars.ekos.mount] - Setting meridian flip status to  "FLIP_PLANNED"
[2021-08-22T01:34:05.505 EDT DEBG ][     org.kde.kstars.ekos.mount] - meridianFlipStatusChanged  "FLIP_PLANNED"
[2021-08-22T01:34:05.506 EDT DEBG ][     org.kde.kstars.ekos.mount] - Received capture meridianFlipStatusChange  "FLIP_WAITING"
[2021-08-22T01:34:05.506 EDT DEBG ][     org.kde.kstars.ekos.mount] - meridianFlipStatusChanged  "FLIP_WAITING"
[2021-08-22T01:34:05.506 EDT INFO ][     org.kde.kstars.ekos.mount] - "Meridian flip waiting."
[2021-08-22T01:34:05.766 EDT INFO ][           org.kde.kstars.indi] - QHY CCD QHY183C-89efd84 :  "[INFO] Exposure aborted. "
[2021-08-22T01:34:08.361 EDT DEBG ][     org.kde.kstars.ekos.mount] - Received capture meridianFlipStatusChange  "FLIP_ACCEPTED"
[2021-08-22T01:34:08.361 EDT DEBG ][     org.kde.kstars.ekos.mount] - meridianFlipStatusChanged  "FLIP_ACCEPTED"
[2021-08-22T01:34:08.529 EDT INFO ][     org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "21h 51m 21s" DEC= " 47° 26' 49\""  Hour Angle  "00h 00m 33s"
[2021-08-22T01:34:08.529 EDT DEBG ][     org.kde.kstars.ekos.mount] - Setting meridian flip status to  "FLIP_RUNNING"
[2021-08-22T01:34:08.529 EDT DEBG ][     org.kde.kstars.ekos.mount] - meridianFlipStatusChanged  "FLIP_RUNNING"
[2021-08-22T01:34:08.530 EDT INFO ][     org.kde.kstars.ekos.mount] - "Meridian flip started."
[2021-08-22T01:34:08.564 EDT DEBG ][     org.kde.kstars.ekos.mount] - Slewing to RA= "21h 51m 21s" DEC= " 47° 26' 49\""
[2021-08-22T01:34:08.564 EDT DEBG ][     org.kde.kstars.ekos.mount] - Initial HA  0.136151 , flipDelayHrs  0 MFStatus  "FLIP_RUNNING"
[2021-08-22T01:34:08.585 EDT INFO ][     org.kde.kstars.ekos.guide] - "Mount is slewing. Aborting guide..."
[2021-08-22T01:34:08.592 EDT INFO ][     org.kde.kstars.ekos.mount] - "Meridian flip slew started..."
[2021-08-22T01:34:08.600 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2021-08-22T01:34:08.600 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2021-08-22T01:34:08.736 EDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Guiding Stopped."
[2021-08-22T01:34:08.759 EDT INFO ][     org.kde.kstars.ekos.guide] - "Autoguiding aborted."
[2021-08-22T01:34:08.766 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Aborted"
[2021-08-22T01:34:09.471 EDT INFO ][           org.kde.kstars.indi] - iOptron CEM25 :  "[INFO] Slewing to RA: 21:51:21 - DEC: 47:26:49 "
[2021-08-22T01:34:09.535 EDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Guiding started."
[2021-08-22T01:34:09.571 EDT INFO ][     org.kde.kstars.ekos.guide] - "Autoguiding started."
[2021-08-22T01:34:09.624 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Guiding"
[2021-08-22T01:34:11.667 EDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Guiding Stopped."
[2021-08-22T01:34:11.690 EDT INFO ][     org.kde.kstars.ekos.guide] - "Autoguiding aborted."
[2021-08-22T01:34:11.696 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Aborted"
[2021-08-22T01:34:11.729 EDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Lock Position Lost."
[2021-08-22T01:34:12.526 EDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Guiding Stopped."
[2021-08-22T01:34:12.533 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Aborted"
[2021-08-22T01:34:40.565 EDT INFO ][           org.kde.kstars.indi] - iOptron CEM25 :  "[INFO] Slew complete, tracking... "
[2021-08-22T01:34:41.529 EDT DEBG ][     org.kde.kstars.ekos.mount] - Mount status changed from  "Slewing"  to  "Tracking"
[2021-08-22T01:34:41.529 EDT DEBG ][     org.kde.kstars.ekos.mount] - Slew finished, MFStatus  "FLIP_RUNNING"
[2021-08-22T01:34:41.557 EDT INFO ][     org.kde.kstars.ekos.mount] - "Meridian flip completed OK."
[2021-08-22T01:34:41.569 EDT DEBG ][     org.kde.kstars.ekos.mount] - Setting meridian flip status to  "FLIP_COMPLETED"
[2021-08-22T01:34:41.569 EDT DEBG ][     org.kde.kstars.ekos.mount] - meridianFlipStatusChanged  "FLIP_COMPLETED"
[2021-08-22T01:34:41.570 EDT INFO ][     org.kde.kstars.ekos.mount] - "Meridian flip completed."
[2021-08-22T01:34:41.581 EDT INFO ][   org.kde.kstars.ekos.capture] - "Telescope completed the meridian flip."
[2021-08-22T01:34:41.612 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3
[2021-08-22T01:34:41.612 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Idle"
[2021-08-22T01:34:42.501 EDT DEBG ][     org.kde.kstars.ekos.mount] - Setting meridian flip status to  "FLIP_NONE"
[2021-08-22T01:34:42.501 EDT DEBG ][     org.kde.kstars.ekos.mount] - meridianFlipStatusChanged  "FLIP_NONE"
[2021-08-22T02:23:13.552 EDT INFO ][ org.kde.kstars.ekos.scheduler] - Scheduler is stopping...
[2021-08-22T02:23:13.553 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Job ' "Cocoon_Lx_240" ' is stopping current action... 13
[2021-08-22T02:23:13.556 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'Cocoon_Lx_240' is stopping guiding..."
[2021-08-22T02:23:13.557 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'Cocoon_Lx_240' has not been processed upon scheduler stop, marking aborted."
[2021-08-22T02:23:17.283 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - "Searching in path '/mnt/usb/Cocoon_Lx_240/Light', files 'Cocoon_Lx_240s_Light*' for prefix 'Cocoon_Lx_240s_Light'..."
[2021-08-22T02:23:17.283 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'Cocoon_Lx_240s_Light_001'"
[2021-08-22T02:23:17.283 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'Cocoon_Lx_240s_Light_002'"
[2021-08-22T02:23:17.284 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'Cocoon_Lx_240s_Light_003'"

Attached are a screenshot of my settings and the full log from last night 

 

File Attachment:

File Name: log_20-02-24.txt
File Size: 1,011 KB


 

Read More...

Thanks. That is very "Ekos" - a parameter housed in the Focus module, set in the Capture module, and has a sort-of equivalent in the Scheduler module :)

I did set Align in the 'Steps' section, as losing guiding would result in the target wandering a bit. In the end last night guiding never failed completely - I woke up at 3:00 and PHD2 was hanging on to one last star, trying its best to maintain some semblance of guiding. It looked like clouds from then on, rather than just some passing, so I shut down.

Read More...

Thanks, Wolfgang. That makes sense (assuming the "focus-after" timer does not get reset to 0 when the scheduler restarts the job).

Read More...

ss3.jpg

So far, the Capture module has satisfied my needs, so I'm a total noob with the scheduler. We are apparently in store for a few passing bands of clouds tonight, so I'd like to give this a go.

Let's say I want to capture a single target for the whole night. I set a capture sequence of 45x60", and put it on "Repeat until terminated" or "until time" and set time for a bit after dawn twilight. In order to get recovery if guiding is lost from clouds, does it make sense to use "Re-schedule errors" with a wait of something like 5 minutes?
When it tries to restart, will it re-focus, then align, then restart guiding or does that full process only happen if it has completed the full 45 exposures?

Read More...

Good luck! If you end up needing to tune the mount's guiding performance there are informative threads here (in Mounts) and on CN. Let me know if you ever need any of the iOptron adjustment pdfs.

In your testing, have you set KStars or the mount as the source for date and location?

The issue with DST is (was?) that the driver/mount combination does not correctly adjust to DST. The workaround is to set DST=No in the hand controller and manually change the UTC offset by 1 hour at DST / regular time changeovers.

Read More...

Last night I went out to my club's dark sky site for my first try at imaging away from the comfort of home. Mount is a CEM25P, which has GPS built in. I have always used "Mount updates KStars" for time and location at home, but apparently the mount's GPS is not a fan of the remote location and could not obtain a GPS lock. I did not worry at first, because the HC does a pretty good job of keeping time without the GPS, and the location was only about 30 miles off.

Questions, before I lose everyone with the long version:

1) When I have set "Mount updates KStars", does KStar know there is no GPS info? (or does the mount refuse to send any data without GPS lock?) Is that why the perfectly reasonable time from the HC was ignored by KStars?
2) Does the CEM25P still need to have DST=No set in the hand controller? (along with manually changing the UTC offset to function correctly with the INDI driver?)

I think I have figured out how to deal with the problems I had with KStars last night, but I would be greatly appreciative if someone could read the long version of the story below and let me know if I'm missing something.

I got everything up and running, but the first time I checked what time KStars thought it was was when I went to select a star to do a guide calibration. It seemed odd that Jupiter and Saturn would be up at 10pm last night :)  KStars had some random mid-morning time. I found the screen to reset KStars time and set it to the correct local time. Told it to slew to Regulus, which it did correctly. Calibrated and focused, all so far so good. Slewed to M101, plate solved, all good.

Started guiding and the RA axis just zoomed off the chart and stayed there. Tried a few things (reboot, readjust RA tension bolt even though that has never been a problem before). Each time I restarted Ekos I did my usual routine of clearing Park and setting/saving Park to home position - but every time I parked it went to a spot a bit counter-clockwise from Home (looking from behind). This did raise a few thoughts about DST (and I have DST=Off in the mount handset), but out there in the dark field with no internet I was more focused on the guiding weirdness. Just about the last thing I noticed as I was resigned to packing up and heading home was that Ekos reported the mount as being on the east side pointing west, when I could clearly see it was on the west side (M101 was just about to cross the meridian), and the Mount tab said the meridian flip was coming up in just over 14 hours (kind of rang more DST bells, but 14 hours didn't seem to make any sense at all). Of course, it was the clarity of driving home that finally suggested that PHD2 was trying to move RA in one direction, but was actually pushing it farther away with each correction because the system did not know which side of the pier it was on. At least that is my current theory about why RA zoomed right off the graph every time I started guiding.

Tested at home this morning. Everything worked as it normally works at home when I was outside with a GPS lock. Came inside to prevent GPS getting a lock (and I realized that the pi gets time/date from the wifi network, so I disabled that interface and ran with just the astroberry hotspot, like out in the field). The pi and KStars booted up with some random time and date (Thursday, mid-morning). So I found the correct command to manually reset the pi date/time, which got KStars into the right place. Set time back to last night, slewed to M101 and it appeared to choose the correct pier side and reported a rational time to the next flip.

Is there anything I haven't thought of yet that would be a 'gotcha' the next time I go out to the dark site? Will anything weird happen if the mount decides to get a GPS lock in the middle of imaging, with 'KStars updates all devices' set?

Read More...

Run two separate commands. Mine does not like using the && either.

Read More...