Hi folks.
I recently came across this issue while trying an automation scenario.
The focuser simulator was not able to change the focus of the Guide Simulator camera, even if there was focuser simulator in the list of snoop device.

I was wondering if it was possible either to instanciate a guide simulator that would have a proper focusing curve, or to instanciate two ccd simulator on the same server.

Thank you in advance for your help

Read More...

Nice, thank you very much for your answer, I didn't know the command "indi_setprop" existed, this is quite handy for debugging !
I am using a custom python implementation of indi client (not the official pyindi, that I stopped using a while ago because of poor maintenance status).
Actually I realized what was the issue, and it was not related to the lx200 mount driver implementation.

I was sending 2 TARGET_EOD_COORD set in a row, without waiting for the end of the goto.
What happened is that I was received a TELESCOPE_ABORT_MOTION switch, and the TARGET_EOD_COORD was set to IDLE value (instead of the BUSY I expected).

I fixed my script and now everything is working as expected

Read More...

Dear all,
I used to go check the following documentation to undersand basic propoerties of cameras/telescope and write scripts for my equipments
indilib.org/developers/deveioper-manual/...s.html#h3-telescopes

Recently, I found myself in trouble while someone tried to used a piece of software I used, that contained a simple "goto".
In practice the goto amounts to do that:
set number 'EQUATORIAL_EOD_COORD' to specified value
wait until EQUATORIAL_EOD_COORD light goes from IPS_BUSY to something else (either IPS_ALERT or IPS_OK)

Usually, for instance in the simulator, the light goes to IPS_OK when the slew is over, and the telescope is at the desired psition.

Relevant code for this behaviour can be found there:
github.com/indilib/indi/blob/6bae059fd24...ditelescope.cpp#L877

However, for lx 200 based driver, it looks like the behaviour might be different, but this is not 100% clear to me:
github.com/indilib/indi/blob/22718d728fa...00telescope.cpp#L402

It looks like the IPS_BUSY has been commented out, and instead, the TrackState (from enum TelescopeStatus) is updated. Unfortunately, from what I know, the TelescopeStatus is not exposed as either a read-only switch or something else, making it impossible to synchronize properly on the end of the slew.

Am I understanding the issue correctly or not ?
Thank you in advance for your help.

Best regards

Read More...

Client is on a x86 laptop and server/driver on a 4GB SBC ~30% more powerful than a rasbperrypi4 (rock64pro from pine64).  I tried with 8bit and lowest resolution but didn't get better results unfortunately. But the outcome seems more or less random, I will try to reduce the potential source of errors in my next attempt, IE, much better network, changing usb cable, etc...

Read More...

I tried changing the auto-exposure (enabled by default ?) in the controls tab.
 

Dear all,

I have an Altair AA 183MM Pro, that I bought specifically to use with indi. Unfortunately, I haven't been able to use it properly, as I often need to reboot something (either the driver or the indiserver or the ekos indi client crash or become unusable).
Anyway, let start with a bug I can easily reproduce.
Whenever I launch indiserver with indi_altair_ccd driver alone:I get a very weird behaviour after I have launched an acquisition, on the client side, I basically end-up with a completely blank client (and of course never manage to get the nice image pop-up as it works with the asi driver for zwo ccd):
FYMqP8V 

Sorry I don't have the 269 c, However I have the Altair AA183M Pro and I must say I am pretty disappointed by the driver. It keeps crashing, making ekos indi client completely buggy or unreliable. To me it is a pretty bad product/driver pair, and I will never invest again in Altair hardware.

Read More...

Thank you for the feedback. It is an option indeed. I power the camera with a powerful source (upbv2 from pegasus astro), but I might have a weak cable, will do some tests later one. For now, it seems more like a software issue.

Read More...

Did you eventually managed to fix that issue ?
It is quite annoying, as I cannot reliably get this camera to work, and for now I didn't managed to find out what parameter was influencing this behaviour....
I get:
[WARNING] Failed to snap exposure. Error: Unexpected failure. Switching to regular exposure...

Read More...

Even if the swig build itself is not failing, I guess we ended up more or less back to the same state: github.com/indilib/pyindi-client/issues/2
Anyone with good knowledge about swig able to help ?

If I have time this week, I'll check what I can do with pybind11, see if the methods/attributes can be retrieved from python, or if it is not swig related.

Read More...

Ok thank you for the feedback, and I apologize for mentionning the wrong problem. I was simply not able to determine what was the issue by myself.
I just realized that the macro I suspected to be the initial source of the problem was more or less an equivalent of Q_DECLARE_PRIVATE one can also find in QT source code that is apparently meant to bypass some compiler limitation with RTTI and dynamic_cast.

In my humble opinion it would be a good idea to have pyindi client tested at least as part of indi releases, as I think this project really makes indi extremely powerful, and some opensource projects with growing popularity are relying on it (hinking here at the fantastic work done by Gulinux). However it is definitely not my call, as I am not doing any significant maintenance of either indi or pyindi-client.

Thank you pawel-soja for your work on the project !

Read More...

There seems to be already some work made in that direction:
github.com/geehalel/npindi
github.com/MMTObservatory/indiclient/tree/master/indiclient

Read More...