Good day!
We are currently using kstars version 3.6.3 with our 10micron mount. Since we are not guiding but still want to employ dithering we are using the "Non-Guide Dither Pulse" option with a setting of 1000ms.
After the update to version 3.6.3 (unfortunately I don't know from which version we updated) the exposures get stuck after rouhgly 30s each. They do finish when this dither option is disabled.
With getting stuck I really mean that the countdown for the exposure just stops counting down and nothing happens anymore.
Is anyone else using this option and has the same problem?
Or does maybe someone have a suggestion what I should change for this to work again?
Thank you in advance

Read More...

Hello!

we are having a bit of an issue with the PlaneWave EFA when performing autofocus. The focuser has a rather large number of steps of several tens of millions. Sometimes the algorithm in the focusing module wants the focuser to move something like 20 to 25 steps, which is of course tiny. The focuser then doesn't move at all, but the focus module keeps waiting for the focuser to reach it's final position. Everything then just stays this way indefinitely, until someone aborts the autofocus procedure. The motion doesn't even time out, even though a timeout of 30 seconds has been set.

Maybe someone can help me with this issue.

Read More...

Thank you very much for your response.
I had a look at the current issues and it seems that the one here represents the exact problem we have: github.com/indilib/indi-3rdparty/issues/522

Thank you for pointing that out.

Read More...

Hello!

For half a year now we are using our new camera at the observatory, the Moravian C4-16000 which has four specific non-numeric gain settings (HDR, 12 bit high, 12 bit low, 16 bit low) and settings for a near infrared preflash to fill the charge traps in the sensor in order to correct for the RBI effect. Changing these settings through the indi control panel works very well.
However, these settings are currently not saved as fits keywords in the image files. Is there any way this could somehow be added?
I had a look at the CCD class and it seems that there is no easy way for the driver to just add arbitrary fits header keywords next to the default ones, is this correct?

Thank you in advance,
Philipp

Read More...

Okay, we aren't using a Raspberry Pi at all but a desktop computer wirh an Intel Core i7-9700 and 32GB of Memory.
Do you think that this might be an issue?
Yesterday when doing observations we didn't think abour it and forgot to deactivate dome slaving before the HA went above zero and the same happened again. With your real equipment this behavior is completely reproducible.
I'm wondering, is there any way I can supply you with better diagnostics?

Read More...

Thank you very much for your effort!
In case it is useful, I can always perform a "dry run" under the closed dome, even during the day.

Read More...

Hi Jasem and Ferran,
thank you very much for your quick replies.
if you are referring to
<code>DEBUG 902.539768 sec : OTA_SIDE: 1</code>
and
<code>DEBUG 903.696959 sec : OTA_SIDE: -1</code>
I can see it myself know, thank you for pointing this out.

I just checked the log from the lx200 10micron driver to see what the mount reports. It always reports 'E' in the #Ginfo# for pier side so this is apparently correct. You can also check that yourself, it's in the logs attached in the first post. And the single line updating the telescopes pier side in the driver is also pretty clear I think:
<code>setPierSide((toupper(Ginfo.SideOfPier) == 'E') ? INDI::Telescope::PIER_EAST : INDI::Telescope::PIER_WEST);</code>
So actually there is no possiblity that the pier side is set incorrectly from the mount driver, correct?
I just remembered something additional: This odd behavior only occured when "doing" something with the mount, particularly guiding. When we just let it sit there, with guiding deactivated and no exposure active, everything was fine. But as soon as we activated guiding or told the mount to slew a bit higher because we couldn't find a star due to the bad transparency the pier side was reported as "-1". Having a look at the piece of code in INDI::Dome I can see that the pier side is only taken from the mount if
<code>OTASideSP.s == IPS_OK</code>
If this is not the case it simply takes this information from the hour angle which is calculated from the time, the observers longitude and the right ascension of the mount which in this case would imply that the flip is already done.
So, is it possible that when guiding or slewing is happening then <code>OTASideSP.s</code> is not <code>IPS_OK</code> and therefore the calculated pier side is taken which is on the other side?

Philipp

Read More...

Dear all,
before I continue let me please state that I am incredibly impressed and very grateful for the developement of the INDI Framework.
Over last couple of weeks I developed a driver for the dome of our observator which drives the (very old and constant speed) motors of the dome with a Raspberry Pi. I also wrote the appropriate INDI driver which turned out to be comparatively easy when looking at other drivers for reference.
Now dome motion control is working fine. I also configured slaving with the proper parameters and this is also working fine (the shutter of the dome is very large and forgiving, although the fact that the guide scope is on the outer edge of the OTA makes things a bit more difficult).
We are only experiencing a single issue when it comes to completely autonomous operation of the entire thing with the 10micron GM4000 HPS mount: When the mount has hour angles just before the meridian flip the dome starts going back and forth between the currently required position and, evidently, the position it should be in after the meridian flip.
I immediately suspected that my own driver is the problem so we tested the same procedure with the dome simulator and the behavior is indeed the same. Having a look at the log of the dome simulator driver these interesting lines show up:

DEBUG   872.603872 sec  : JD: 2.45927e+06 - MSD: 10.3856
DEBUG   872.603930 sec  : MC.x: 0 - MC.y: 0 MC.z: 0.45
DEBUG   872.603951 sec  : HA: -10.8922  Lng: 10.8328 RA: 330
DEBUG   872.603965 sec  : Active Snoop, driver: LX200 10micron, property: TELESCOPE_PIER_SIDE
DEBUG   872.603982 sec  : OTA_SIDE: 1
DEBUG   872.603996 sec  : OTA_OFFSET: 1  Lat: 49.8328
DEBUG   872.604009 sec  : OC.x: 0.958235 - OC.y: -0.218538 OC.z: 0.265535
DEBUG   872.604026 sec  : Mount Az: 2.74314  Alt: 43.0684
DEBUG   872.604040 sec  : OV.x: 0.0349626 - OV.y: 0.729702 OV.z: 0.68287
DEBUG   872.604060 sec  : Calculated target azimuth is 29.88. MinAz: 4.78, MaxAz: 54.98
INFO    872.604073 sec  : Dome is moving to position 29.88 degrees azimuth...
DEBUG   872.604109 sec  : Dome is syncing to position 29.88 degrees...
and half a minute later
INFO    902.046243 sec  : Dome reached requested azimuth angle.
DEBUG   902.539657 sec  : JD: 2.45927e+06 - MSD: 10.394
DEBUG   902.539715 sec  : MC.x: 0 - MC.y: 0 MC.z: 0.45
DEBUG   902.539738 sec  : HA: -10.8837  Lng: 10.8328 RA: 329.999
DEBUG   902.539751 sec  : Active Snoop, driver: LX200 10micron, property: TELESCOPE_PIER_SIDE
DEBUG   902.539768 sec  : OTA_SIDE: 1
DEBUG   902.539782 sec  : OTA_OFFSET: 1  Lat: 49.8328
DEBUG   902.539795 sec  : OC.x: 0.957603 - OC.y: -0.22015 OC.z: 0.264175
DEBUG   902.539812 sec  : Mount Az: 2.76338  Alt: 43.0728
DEBUG   902.539826 sec  : OV.x: 0.0352179 - OV.y: 0.729638 OV.z: 0.682927
DEBUG   902.539845 sec  : Calculated target azimuth is 29.89. MinAz: 4.78, MaxAz: 54.99
DEBUG   903.696934 sec  : JD: 2.45927e+06 - MSD: 10.3943
DEBUG   903.696951 sec  : MC.x: 0 - MC.y: 0 MC.z: 0.45
DEBUG   903.696956 sec  : HA: -10.8834  Lng: 10.8328 RA: 329.999
DEBUG   903.696959 sec  : OTA_SIDE: -1
DEBUG   903.696962 sec  : OTA_OFFSET: 1  Lat: 49.8328
DEBUG   903.696965 sec  : OC.x: -0.957578 - OC.y: 0.220212 OC.z: 0.635877
DEBUG   903.696969 sec  : Mount Az: 2.76413  Alt: 43.073
DEBUG   903.696972 sec  : OV.x: 0.0352272 - OV.y: 0.729634 OV.z: 0.68293
DEBUG   903.696977 sec  : Calculated target azimuth is 335.31. MinAz: 309.91, MaxAz: 0.72
INFO    903.696980 sec  : Dome is moving to position 335.31 degrees azimuth...
DEBUG   903.696988 sec  : Dome is syncing to position 335.31 degrees...

These 30 odd degrees roughly is the position where the dome should be after the meridian flip (we confirmed that by performing it) and these 335 odd degrees is where it is supposed to be before the flip (when the log was taken).

Since this is happening with the dome simulator driver I think I can rule out my own driver as the problem, the only difference is that it is actually in reality starting to go crazy.

The version we used are, from ppa:mutlaqja/ppa:
INDI Library: 1.8.8
Code 1.8.8-tgz. Protocol 1.7.
kstars 3.5.1 Stable

One note here: We didn't have INDI 1.8.8 installed from source but only 1.8.6, so I used this to link my own driver against. But as I said, in the above testing procedure, this wasn't used, the dome simulator was.

All the other logs are attached.

I would be very grateful for any help.

Ciao,
Philipp

Read More...