Hi knro:

How about using the exposure time, read out time and delay time settings to estimate the time to meridian, though this method still has its limitation as download time cannot be predicted.

Read More...

Hi knro, looks like many people came across with this problem, is there any plan to solve it ?

Read More...

Do you plan to implement the waiting feature in the next version ?

Read More...

I agree that the imaging data on meridian is quite important. I do photometric work and know that the data from meridian usually has the best quality due to a lower airmass.

However, I will still be grateful if you can add an option to flip immediately and pause the exposure if the duration is longer than the time to meridian. Since I am working with a remote telescope, I must keep the telescope in a safe position as much as possible.

In addition, shooting a target with a exposure duration longer than 600s is quite common for me as I use Strömgren u filter to measure the Balmer jump, where the light flux is quite low in near UV (due to the Balmer jump the stellar flux is significantly lower and the atmosphere absorb more light in NUV). It is necessary to get a longer exposure to achieve the same SNR with those broad band system.

Read More...

Sorry I not sure where to post a feature request. So I post another one here.

The original one: www.indilib.org/forum/development/3531-a...-greater-than-0.html

Last night, I tested the meridian flip in Ekos and found a problem.

I set up a series exposures with duration 900s and the auto meridian flip was enable, then I chose a target which was near the meridian. When the hour angle was greater than 0 (this is the default value) , the scope would not flip automatically until the current exposure was finished.

In my opinion, the current exposure should be abort and dropped when hour angle is greater than 0, then perform the meridian flip immediately and restart the exposure which has been abort before. The reason is that if an exposure is very long (For example 3600s or more, my CCD can do such a long time exposure), the scope cannot track accurately when hour angle is greater than 0. In addition, the scope is in dangerous position and it might hit the tripod.

Based on my view, I urge that to stop current exposure and perform meridian flip in Ekos when auto flip is enabled and telescope hour angle is greater than 0. Then restart the exposure which has stopped before.

Does anyone come across the same problem with me ?

Read More...

Last night, I tested the meridian flip in Ekos and found a problem.

I set up a series exposures with duration 900s and the auto meridian flip was enable, then I chose a target which was near the meridian. When the hour angle was greater than 0 (this is the default value) , the scope would not flip automatically until the current exposure was finished.

In my opinion, the current exposure should be abort and dropped when hour angle is greater than 0, then perform the meridian flip immediately and restart the exposure which has been abort before. The reason is that if an exposure is very long (For example 3600s or more, my CCD can do such a long time exposure), the scope cannot track accurately when hour angle is greater than 0. In addition, the scope is in dangerous position and it might hit the tripod.

Based on my view, I urge that to stop current exposure and perform meridian flip in Ekos when auto flip is enabled and telescope hour angle is greater than 0. Then restart the exposure which has stopped before.

Does anyone come across the same problem with me ?

Read More...

Some of the softwares such as SGP supports notification via email when auto guiding is failed. I think this feature is useful when you set up an automatic observation during the night. My way is much simple: just add a python script execution when auto guiding is failed. Then I can write my own script to notify me something went wrong.

Moreover, it will be nice if script execution can be added to other modules (focus, capture, alignment etc) when things go wrong. For an autonomous observation, anything goes wrong should be notified to the observer asap. This will help the observer to deal with the problem immediately without wasting the time.

For the script execution, I think it can be implemented in schedule module next to the "steps". For example, if guide module is activated and a script is applied, when auto guiding is failed, the script will be executed.

Any view on this feature?

Read More...

starrybird replied to the topic 'Re:Problem with PyIndi client' in the forum. 6 years ago

I overwritten the newMessage method and the problem solved

def newMessage(self, d, m):                                                                                            
    message = d.messageQueue(m)                                                                                        
    message.acquire()                                                                                                  
    message_string = ctypes.cast(message.__int__(), ctypes.POINTER(ctypes.c_char_p)).contents.value.decode('utf-8')    
    message.disown()                                                                                                   
    wx.PostEvent(self.__parent, CommonEvent(common.ID_EV_UPDATE_STATUS_BAR, message_string))


Read More...

starrybird created a new topic ' Problem with PyIndi client' in the forum. 6 years ago

I am writing a simple client to control my mount via pyindi-client and I just encountered 2 problem.

Problem 1 is I don't know how to obtain the info message generated by driver?

Problem 2: When I test my client with EqMod Mount and the limit is enabled (goto, track and slew), however, the mount will not stop event if it is out of limit and warning can be seen from EKOS's INDI menu. It seems that the TimerHit function is not called but I don't know the reason for that.

Hope someone can give some help with these 2 problems.

Read More...

I usually settle for 15s.

Read More...

I noticed that his settle time is the delay after dithering and before guide resuming. My expectation is the delay after guide resuming. I am not very sure that settle time is the delay after guide resuming.

Read More...