Ilia created a new topic ' Bresser Exos Goto?' in the forum. yesterday

Hello,
A friend of mine has bought a Bresser GoTo mount, which is controlled by the Exos 2 handset.
Is it possible to control it using the PC? The manual says that there is an RS-232 connector, but in other forums they say it's not functional at all.
Thanks for any suggestion!

Read More...

Ilia replied to the topic 'Re:Scheduling Locally...' in the forum. 3 weeks ago

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.

Read More...

Ilia thanked Eric in topic Re:Scheduling Locally... 3 weeks ago
Ilia thanked Jasem Mutlaq in topic Re:Scheduling Locally... 3 weeks ago
Ilia replied to the topic 'Re:Scheduling Locally...' in the forum. 3 weeks ago

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 constructve the argument of this thread.
By the way, Thank you all.

Best Regards,
Ilias.

Read More...

Ilia replied to the topic 'Re:Scheduling Locally...' in the forum. 3 weeks ago

My personal opinion is that what you describe moves too much intelligence to the drivers. It's not up to a driver to choose when to do something

I perfecly agree on this. The driver does not manage scheduling, it's up to an external client to issue the Schedule() call. The driver actually only creates a timer that calls an internal function. There's even not much problem of making a FIFO where to store the scheduling timeline this way.
The client should issue an XML string (ex. fantasy "<newSched exec="SCHED_EXPOSURE" args="10.0"...") and the driver should call Schedule() upon reception of such command.

...even an INDI orchestrator driver.

This is the quickest solution, in fact would permit to skip initial Ekos coding.

Best Regards,
Ilias

Read More...

Ilia replied to the topic 'Re:Scheduling Locally...' in the forum. 3 weeks ago

The precision of the clock sync of a computer using NTP should be a few tens of milliseconds. If the CCD driver is updated to accept a timestamp at which to take a capture, does that sound like a beginning of your idea?

Yes, exactly. I meant this for basic member functions of each device interface, like in CCDs:
  • StartExposure ()
  • AbortExposure ()
  • StartGuideExposure ()
  • ...
  • GuideNorth ()
  • GuideSouth ()
  • ...and so on

There should be a function for adding targets called "AddScheduler(char* name)"
and scheduling calls like "Schedule(char *name, void* arg, timespec *tp)" where name is the same as AddScheduler and arg is the parameter to the callback, like exposure in case of CCD captures.
example (ccd driver base class)
typedef void* sched_arg[2];

Constructor() {
...
AddScheduler("SCHED_EXPOSURE");
...
}

(virtual)bool Schedule(char *name, void* args, timespec *tp)
{
    ...
    else if("SCHED_EXPOSURE"== name) {
        sched_arg arg;
        arg[0] = (void*)this;
        arg[1] = args;
        timer_t timerid; //should not stay here
        struct sigevent sevp;
        sevp.sigev_notify = SIGEV_THREAD;
        sevp.sigev_notify_function = sched_start_exposure;
        sevp.sigev_value = arg;
        if(timer_create(CLOCK_REALTIME, &sevp, &timerid) == 0)
            return true;
    }
    else return false;
}
...
void* sched_start_exposure(void* arg)
{
    sched_arg args = (sched_arg)arg;
    INDI::CCD *sender = (INDI::CCD *)args[0];
    sender->StartExposure((double)args[1]); //PROBLEM: protected member...just an example BTW
}


Read More...

Ilia replied to the topic 'Scheduling Locally...' in the forum. 3 weeks ago

Unfortunately the best method should be linking against an user space library that uses kernel's scheduling capabilities.
I think that this is too much however: 1us is really small as delay, and there is still the problem in hardware execution time, like the internal delays in USB or serial communications.
A practicable solution would be such extension to have controls of the default properties of the driver's base class, a client would activate it with a switch and schedule as the user requires. This will stay inside the driver's code, this way the delay will be acceptable and obviously will use driver's local clock, which is the most important thing.

Read More...

Ilia replied to the topic 'Scheduling Locally...' in the forum. 3 weeks ago

I would propose something different than a local install of Ekos, like a new driver called "scheduler", which creates an instance of the scheduler driver for each device connected to the server. This driver should implement an internal INDI client connected at localhost.

Read More...

Ilia replied to the topic 'Scheduling Locally...' in the forum. 3 weeks ago

I mean something with the less possible lag between the command and hardware execution time.
KStars stays at the client side. I mean something at server side or better driver side.
KStars should issue the scheduling command, after polling ping-like delays between the client and the device, then, based on this delay, the driver should issue the hardware command with the best precision possible (using GPS clock one can reach 1us).
This could be useful for time-logging features also, like precise high-speed photometry.

Read More...

Ilia created a new topic ' Scheduling Locally...' in the forum. 3 weeks ago

Is there any way to schedule an operation using the driver's system clock?
I mean a field where one sets a precise (or less) local date/time to do any kind of operation, like slew, track, start an exposure/capture, change filters...etc, and avoid network delays.
What do you think?

Read More...

Revellat thanked Ilia in topic Inova CCD 1 month ago
Ilia replied to the topic 'Inova CCD' in the forum. 1 month ago

Hello philippe,
this may be an usb bandwidth issue: the PLC-M/NBC-M have sync issues in libusb versions of the SDK also. I think it's not a problem of the driver itself, but of the SDK.
I'd like to get a feedback from a CCD or Aptina user of these cameras (PLA/PLB-C2/PLB-Mx and PLB-Cx/PLB-Mx2) and compare the various results.
The INDI driver reads always at 12bits, so high framerate is not to be expected right now. Short and very short exposures are available BTW.
Best Regards,
Ilia.

Read More...

Revellat thanked Ilia in topic Inova CCD 1 month ago
Olivier Masse thanked Ilia in topic Inova CCD 1 month ago
Ilia thanked Olivier Masse in topic Inova CCD 1 month ago
Ilia replied to the topic 'Inova CCD' in the forum. 1 month ago

Hi Olivier,
Yes, to be clear, the SDK version is 1.3.x , so the old driver was referring to this (inova-ccd)
indi-inova-ccd is now obsolete.
indi-inovaplx-ccd is the new driver and should be used from now on. Its version is set to 1.0 since the indi binary is at its first steps of integration, while inovaSDK continues its versioning from 1.3.0. i.Nova SDK can be used, according to its proprietary license, by programmers after prior explicit permission from i.Nova Technologies for its usage.
Best Regards,
Ilia.

Read More...

Ilia replied to the topic 'Inova CCD' in the forum. 1 month ago

Thank you,
I pulled your changes, and made a PR.
Best Regards,
Ilias.

Read More...

Ilia replied to the topic 'Inova CCD' in the forum. 1 month ago

Hello Philippe,
The inovaplx driver is simply the old driver, but released with open-source license. Many parts of its code refer to the old driver, so be patient, I'll do a pull request with the changes you suggest.
Thank you, BTW for your useful feedback.
Best Regards,
Ilia.

Read More...

Ilia thanked Olivier Masse in topic Inova CCD 1 month ago

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!