Thanks for the explanation Wolfgang. Yes I understand about not adding features until refactoring. Makes sense.
Thanks Wolfgang, that makes sense for the first target. But I think there is still a problem. All subsequent targets (which are far from the moon) get pushed out to the next night. Even though they can be observed this same night.
For example, above, KR_Aur is too close to the moon and is invalid. However the second entry (CH UMa) is actually in a good position (far from moon and 54 deg altitude). The problem is this target gets pushed to the next night.
I would expect the scheduler to skip the invalid entry for KR_Aur and start observing CH_Uma next but it will not.
If I delete KR_Aur, then then CH UMA will flip back to tonight and can be scheduled as expected.
I think I'm able to reproduce with that file
I manually set the time in Kstars to Jan 16th 22:15 and loaded it. (my location set to Cork, Munster, Ireland)
The first job is scheduled for the next day (17th) but if I delete the first row and click the 'reset and reevaluate' button they all get corrected to the 16th
Thanks, here's a zip of the schedule from screenshot 1 above. I just tried loading it now (5:20PM local time) and its actually fine..... Will try play with date-time settings to try to reproduce.
That is strange alright. The only other suggestion I have is to clean the USB cable connectors with contact cleaner. If you live in a humid climate. I have had some strange things happen USB cables. Its rare but does happen.
If you can open a terminal and run dmesg you might see some log messages relating to serial/USB cable problems
What baud-rate have you selected in the INDI connection settings? Could be worth changing it to test it out
I've seen this behaviour a few times. I think I've found a clue as to what causes it.
Probably affects me more than most people as I regularly load the scheduler with 30 or 40 short jobs for a single night.
The behaviour I see is that some 'valid' jobs get pushed out to the next night. Even though they could/should be scheduled right now.
I have 2 screenshots which explain the problem and also show how I work around it.
Screen shot 1:
This screenshot was taken on the night of Jan 16. However some jobs (example rows 2 & 3) are at a good elevation and moon distance right now but get pushed out to tomorrow (17th Jan)
NOTE: Take note of the first row with a <0 score. Deleting this job and clicking the refresh/reschedule button fixes it (see screenshot2)
Very interesting. I'll be following with interest
What is that material called? The struts you used to build the frame? No welding required?
I clicked on the fliter in EKOS capture tab. Changed the filter from 'Atik EFW' back to '--' then changed it back again to 'Atik EFW' and now the filter is set in the snoop devices in the INDI control panel for the CCD camera.
I found an old message in this forum where someone had the same problem a couple of years ago.
I updated kstars and INDI today (after many many months) and I noticed the filter is not being saved in the fits header anymore.
Looking at the INDI control panel I cant seem to set any device in the snoop devices for filter. Not sure what I'm doing wrong. I deleted all my local ~/.indi config... I also totally reinstalled indi and kstars but still the same result.
Anyone have any ideas?