×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Scheduling Locally...

INDI drivers were not designed to meet real-time constraints. I think even before discussing a local scheduler, find if you can truly develop an INDI driver that could meet such demands.
The following user(s) said Thank You: Ilia
6 years 6 months ago #19095

Please Log in or Create an account to join the conversation.

  • Posts: 57
  • Thank you received: 28

Replied by Ilia on topic Re:Scheduling Locally...

Hmm.. Actually I have not the need to schedule by itself, but to know if I can get accurate timing informations about captures in detectors and exposures in CCDs.
I have to take a capture from different detectors "almost" at the same time, so scheduling with a precise timestamp seemed to be my solution.
Fortunately the captures may be one- seconds or more, and got the initial timestamp I can re-align the frames after.

I realize that it's not common and not much constructive the argument of this thread.
By the way, Thank you all.

Best Regards,
Ilias.
Last edit: 6 years 6 months ago by Ilia.
6 years 6 months ago #19097

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Scheduling Locally...

It seems syncing an exposure to a specific timestamp could be a good feature though. So perhaps you should reformat your wish with this intent if you have a need for it.

-Eric
6 years 6 months ago #19128

Please Log in or Create an account to join the conversation.

  • Posts: 57
  • Thank you received: 28

Replied by Ilia on topic Re:Scheduling Locally...

I'm reading your description, and found maybe something closer to your idea:
Basically in IsNewNumber there's maybe the need of a usleep() before StartExposure().
Is this what you meant?

Best Regards,
Ilia.
6 years 6 months ago #19129

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Scheduling Locally...

I suppose so: the feature would actually be a regular exposure, except longer because of a UTC timestamp at which to start.

That timestamp would be set as a property by the client, sanitized by the driver and eventually reset once the exposure starts.

The driver would calculate the incurred delay before the actual exposure, and poll with adequate precision until the exposure has to be started.

Aborting would still cancel the exposure be it waiting to start or running the hardware capture.

Only future timestamps would be considered as valid start times. This would allow simple initialization to the start of epoch, and avoids the reset requirement.

I believe this should only impact INDI::CCD. An extension to this change would be for that high-level interface to be able to determine the delay between the start request it makes and the actual start of the hardware process. But this could be thought about in a more generic way: some sort of hardware backlash.

Implementation is restricted to one driver. Side-effects are relatively small as the concept of exposure was not modified. If a client doesn't use the delayed exposure feature, then the driver works exactly the same as before. The driver is however probably more sensitive to signals and system configuration.

@knro does that idea make sense?
-Eric
6 years 6 months ago #19212

Please Log in or Create an account to join the conversation.

I don't think INDI::CCD should change to cater to this. Maybe child classes of INDI::CCD or INDI::Detector can define properties for real-time capture and synchronization, and then you need clients to understand these properties and manage them accordingly.
6 years 6 months ago #19215

Please Log in or Create an account to join the conversation.

Time to create page: 0.292 seconds