Thanks for the explanation Wolfgang. Yes I understand about not adding features until refactoring. Makes sense.

Derek.

Read More...

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.

Read More...

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

  



Read More...

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

File Attachment:

File Name: AAVSO-Schedule.zip
File Size: 1 KB


Read More...

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

Read More...

What baud-rate have you selected in the INDI connection settings? Could be worth changing it to test it out

Read More...

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)

  



Screen shot 2:
This screenshot shows the exact same schedule except I deleted the first job which had a score <0 (also deleted other <0 jobs) and clicked the reschedule button above the grid.
All the good jobs immediately change date to the 16th (now) and can be ran.


I'm not sure how to further debug this but I think when there is a score of <0 it messes up the next jobs in the list.
 

Read More...

Very interesting. I'll be following with interest :-)

What is that material called? The struts you used to build the frame? No welding required?

Derek

Read More...

Solved:

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.

Derek

Read More...

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?
Thanks,
Derek
 



Read More...