How about just pausing everything for 30s once the flip has been initiated? I.e. let the mount do it's thing on its own and then end pause? Just tell EKOS to sleep for 30s or so?

After 30s the mount should have finished flipping and settled.

Could that solve the problem?

There may be a new problem: Since the indi driver update (installed via github), my QHY cameras, i.e. Polemaster and a QHY5 are no longer detected.

The QHY_CCD driver is also not listed in the /user/share/indi/drivers.xml file. QSI_CCD driver is also missing.

Could this be the problem?

Jo

PS: ZWO ASI and Nikon DSLR are detected just fine.

Trying to solve things by adding pauses is seldom useful, at the most it hides the problem, however the problem is still there.

From what I am understanding, it looks like every mount has a different firmware that checks on the mount status. This results in a cacophony of different signals Ekos has to deal with. The solution then is to fix each one separately in the respective driver and keep them up to date as the firmware may be updated, i.e. play whack-a-mole, or find a solution that addresses that fundamental problem.

Nothing is going on during the flip anyway, that is being executed by the mount, and not controlled by Ekos. So why not give the mount the time it needs to flip and then restart the sequence? Most mounts will need 30s to flip and settle. At that point, Ekos could just check on the mount status: If it still slewing, then wait another 10s. Once the mount stops reporting that it is slewing restart the alignment routine. Looks like that is what the program is supposed to be doing anyway, but because of the short times involved the signals seem to get crossed.

Am I fundamentally misunderstanding this?

Jo

Looks like it will be clear tonight and I am ready to check the iOptron driver update. Installed the drivers from indi git, but now I have a different problem. My QHY guide cam is no longer recognized. The driver is started, but the camera is not seen. Neither the guide cam, nor the Polemaster, which uses the same driver (QHY-CCD). They are not connected simultaneously, I tried them separately, both previously worked with that same driver, both now will not connect. This is what I am seeing in the device manager.

What is going on and how can I fix this?

2019-11-08T14:04:27: startup: /usr/bin/indiserver -v -p 7624 -r 0 -f /tmp/indififo736b316c
2019-11-08T14:04:27: listening to port 7624 on fd 3
FIFO: start indi_qhy_ccd
FIFO: Starting driver indi_qhy_ccd
2019-11-08T14:04:27: Driver indi_qhy_ccd: pid=6673 rfd=4 wfd=7 efd=8
2019-11-08T14:04:27: Client 5: new arrival from 127.0.0.1:47458 - welcome!
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResource| START
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResourceInside|InitQHYCCDResourceInside START
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResourceInside| InitQHYCCDResourceInside END
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|ScanQHYCCD|START
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|ScanQHYCCD|ScanQHYCCD numdev=0
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|ScanQHYCCD|Scan finished. Return nid=0
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|ScanQHYCCD|numdev = 0
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResource| END
2019-11-08T14:04:27: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResource| Already started


If anyone wants to reproduce the problem, you can download the compiled Driver package here:

www.dropbox.com/s/qfbuvj46n8elh0r/indi_11_8_2019_arm64.deb?dl=0

The flip seems to work now with the new drivers and the polling interval set at 1000 ms, which was the default before, but as I wrote above, I now have the problem that my QHY cameras are no longer detected.

I am not sure why. I tried Han.k's suggestion of using 'sudo apt-get install fxload' , but that did not fix it.

Any other bright ideas anybody?

Except putting my Orion Starshoot AND my PoleMaster up for sale?

Cheers
Jo

PS: Sorry, forgot the Dropbox Link to the screen recording of the successful flip tonight.

www.dropbox.com/s/pzu3cinggu3f1o3/Flip%20Test.mkv?dl=0


2h 10' later, second flip of the night worked without a hitch, too.
Thanks, Jasem and Wolfgang!

Regarding your QHY problem same procedure: log files? And maybe a new thread.

Fully agreed! It doesn't help, we (or at least myself) need to understand what happens. Let my try to explain what I understood so far, how this is working.

We have on the one side a polling period in each INDI driver. For a telescope (unless specifically implemented from a driver), once per polling period the function ReadScopeStatus() is called which updates the status of equatorial coordinates vector EQUATORIAL_EOD_COORD. If this is set to IPS_BUSY, this (in most cases) means, that the telescope is slewing.

On the other side, we have a timer inside of the mount module that updates once per second the mount coordinates and mount status etc. It gets this information from inditelescope.cpp, a class wrapping the INDI driver . It reads the status from EQUATORIAL_EOD_COORD from the INDI driver.

But unfortunately, if this request from the mount module comes too early - i.e. before ReadScopeStatus() has been called updating the status, it takes the old status IPS_OK and thinks the mount is tracking, while the mount is already slewing.

That's why a higher polling frequency reduces the probability that this happens, but does not completely eliminate it.

Resolving is not that easy, but I think this is at least the explanation for what we observe.

Any thoughts?
Wolfgang

I am no C++ expert but I do know Java. In Java there are ReadWriteLocks that prevent threads from reading values when another thread is writing to them. Perhaps such a mechanism exists in C++ such that this race condition can be solved?

Wouter

This is a possible problem in the iOptron firmware, not in INDI or Ekos. If you check the logs, you will see that after the slew command is accepted by the mount, the next status read indicate that the mount is tracking. Now I say it is possible because the mount didn't have time yet to start slewing, it is preparing to slew. But the driver already thinks it started slewing and so to get tracking now can only mean that slewing is complete.

So I added an additional check in the driver in this commit that waits until the mount status changes to SLEWING before the slew functions returns. This, I believe, fixed this issue at the core level in the driver.

This indeed looks like the same thing that is affecting PHD2 calibration. Are you in contact with ioptron support? Might be worth sending them a report about this firmware bug...