hi Gunter,
I guess that in the meantime you figured it out.
Anyway, yes running servers of different ports should do the job.
To start the server you just need the indiserver command, something like:
indiserver -p 7634 -v <add list of drivers and chain them>
systemctl is then needed to start them at boot.
Read More...
hi Gunter,
did you compile and install the drivers on the local machine (RPI4) too?
I never tried driver forwarding but the list of drivers is build locally.
ferrante
Read More...
Rick wrote a nice tutorial for this purpose, maybe could help:
github.com/rickbassham/indi-dev-tutorials
Read More...
ok it's more clear now and it's quite an odd behavior that I didn't experienced when I was using sky flats.
But increasing the tolerance should lower the chance of hitting the threshold during a entire session of flats (at least for each of the filters).
I mean, if you set 16000 +/- 4000 the chance that all the 40 (maybe better to lower to 20) flats ADUs are in the 12000-20000 range is greater. So no need for 'cycling'.
And having flats with a wide range of ADUs is ok as long as they are normalized during integration.
I see that this is not a solution to your issue but more a workaround to avoid it.
Ferrante
Read More...
about the first issue, the 'Tolerance' allows to adjust the valid ADUs range. Have you tried to increase it?
Sky flat ADU values change rapidly so having an higher tolerance should help preventing the issue.
The log that you attached seems to show a correct behavior, it captured 3 out of 40 images and it's not in a infinite loop.
To me the double image in the log seems to be caused by a double logging of the same image but to be sure it should be looked into the source code.
Do you get 80 images instead of 40?
The log shows an interval of about 12s between a capture and the next, while the exposure is only 1s.
Did you set a 'delay' of 10s? if this is the case, I would decrease it, it will help to have ADUs in the correct range.
Ferrante
Read More...
hi Gunter,
in my case (it's a roll off roof, not a dome) abort.py is meant to immediately stop the roof motion.
About the state, what kind of communication you have from/to the device? I mean it's over http, local serial/usb port?
If it's http for example, status.py could be used to poll the device status as the protocol is asynchronous and to update the /tmp/indi-status file.
As these template scripts are executed outside of Ekos, any return value like the parking status (roof open or roof close) must be send to Ekos in some way.
In park.py, if parking is successful, the file 'indi-status' stores the value '1 0 0' ( '0 0 0' if roof open) then Ekos reads this value and so is aware of the parking status.
Btw if the protocol is http I found more efficient that status.py periodically read/write the /tmp/status-indi while park/unpark/abort just manage to issue commands to the device.
If you want a more stable integration of your device (roof or dome) with Ekos consider writing a new INDI driver and not to rely on these scripts only*. My approach (it's the third time so far) is to use the scripts at first and in the meantime write and test the INDI driver.
* one big issue with the scripts (in the roof case) is that only parked / unparked states are sent to Ekos. There's no way as far as I know to tell Ekos that the roof is moving opening or closing etc.
Ferrante
Read More...
it seems that Jasem already fixed this issue as part of another one.
github.com/indilib/indi/issues/1582
I will test and report here if it works fine with the scheduler as well. thanks again for your support.
ferrante
Read More...
Looking at the code seems that the park() method is not managing lights.
I will open an issue on github providing these informations. Probably Jasem should look into it because the bug could also be in the parent lx200 and I immediately got lost in the class hierachy.
Thanks a lot for your help.
Ferrante
Read More...