Jo,
I took a closer look what happened. The scheduler itself is agnostic about DEC signals and its directions. It seems to be a problem of the internal guider and its calculations.

When I understand the calibration algorithm right it obtains DEC swapping out of the direct calibration behaviour, so it might be the case that simply your calibration went wrong.

Please check how many calibration steps are set. Maybe increasing this values gives more accuracy.

HTH
Wolfgang

Hi Wolfgang,

I am doubtful that that is the explanation. The internal guider works flawlessly with my Orion Atlas Pro mount, but that has pier side recognition. It is with my lightweight little iOptron Smart EQ Pro+ mount where the problem comes in.

Perhaps I am interpreting the log the wrong way, but this is what I see is happening:

I started out imaging IC1848 on the ascending side of the meridian:

[2019-11-23T19:46:17.222 CST DEBG ][ org.kde.kstars.ekos.guide] - Iteration 9 Direction: DEC_DEC_DIR Duration: 2000 ms.
[2019-11-23T19:46:17.222 CST DEBG ][ org.kde.kstars.ekos.guide] - start Pos X 0.991834 from original point.
[2019-11-23T19:46:17.222 CST DEBG ][ org.kde.kstars.ekos.guide] - Tracking Square QRect(127,756 32x32)
[2019-11-23T19:46:17.223 CST DEBG ][ org.kde.kstars.ekos.guide] - Dither RA Rate 1267.71 ms/Pixel
[2019-11-23T19:46:17.223 CST DEBG ][ org.kde.kstars.ekos.guide] - Dither DEC Rate 1524.28 ms/Pixel
[2019-11-23T19:46:17.223 CST INFO ][ org.kde.kstars.ekos.guide] - "DEC swap disabled."
[2019-11-23T19:46:17.225 CST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Calibrating" to "Calibrated"
[2019-11-23T19:46:17.226 CST INFO ][ org.kde.kstars.ekos.guide] - "Calibration completed."
[2019-11-23T19:46:17.228 CST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Calibrated" to "Guiding"
[2019-11-23T19:46:17.229 CST INFO ][ org.kde.kstars.ekos.guide] - "Autoguiding started."

Calibration worked as intended and note that DEC swap is disabled. I manually adjusted the image center a couple more times until about 21:39, so calibration was necessarily repeated then. Each time DEC swap was properly disabled.

At 23:25 post flip alignment and calibration had completed successfully. DEC swap was now enabled.

[2019-11-23T23:25:15.406 CST DEBG ][ org.kde.kstars.ekos.guide] - ################## FINISH PROCESSING ##################
[2019-11-23T23:25:15.407 CST DEBG ][ org.kde.kstars.ekos.guide] - Dither RA Rate 1634.63 ms/Pixel
[2019-11-23T23:25:15.407 CST DEBG ][ org.kde.kstars.ekos.guide] - Dither DEC Rate 1677.65 ms/Pixel
[2019-11-23T23:25:15.407 CST INFO ][ org.kde.kstars.ekos.guide] - "DEC swap enabled."
[2019-11-23T23:25:15.409 CST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Calibrating" to "Calibrated"
[2019-11-23T23:25:15.409 CST INFO ][ org.kde.kstars.ekos.guide] - "Calibration completed."
[2019-11-23T23:25:15.412 CST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Calibrated" to "Guiding"
[2019-11-23T23:25:15.412 CST INFO ][ org.kde.kstars.ekos.guide] - "Autoguiding started."

Calibration was marked as completed successfully.

[2019-11-23T23:25:18.104 CST DEBG ][ org.kde.kstars.ekos.guide] - Capturing frame...
[2019-11-23T23:25:18.123 CST INFO ][ org.kde.kstars.ekos.capture] - "Post meridian flip calibration completed successfully."
[2019-11-23T23:25:18.171 CST INFO ][ org.kde.kstars.ekos.capture] - "Capturing 60.000-second image..."
[2019-11-23T23:25:18.184 CST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Capturing"

Around 00:05 the IC1848 sequence was finished and the scheduler switched to the second target for the night, NGC2023. The mount slewed BACK across the meridian to ascending side of the sky.
The guide calibration was propery initiated and finished, but then DEC swap was reenabled, see below. IMO that indicates that now the guide pulses are being INVERTED and going in the wrong direction, resulting in the star trails and the continuous loss of the guide star.

[2019-11-24T00:07:47.401 CST DEBG ][ org.kde.kstars.ekos.guide] - Dither RA Rate 605.402 ms/Pixel
[2019-11-24T00:07:47.402 CST DEBG ][ org.kde.kstars.ekos.guide] - Dither DEC Rate 1527.43 ms/Pixel
[2019-11-24T00:07:47.402 CST INFO ][ org.kde.kstars.ekos.guide] - "DEC swap enabled."
[2019-11-24T00:07:47.404 CST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Calibrating" to "Calibrated"
[2019-11-24T00:07:47.404 CST INFO ][ org.kde.kstars.ekos.guide] - "Calibration completed."
[2019-11-24T00:07:47.407 CST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Calibrated" to "Guiding"
[2019-11-24T00:07:47.407 CST INFO ][ org.kde.kstars.ekos.guide] - "Autoguiding started."
[2019-11-24T00:07:47.428 CST DEBG ][ org.kde.kstars.ekos.guide] - Capturing frame...


Please let me know where I am misinterpreting this chain of events. During the first sequence, DEC swap was properly DISABLED on the ascending side of the meridian. It was properly ENABLED post-flip. After the mount flipped back it was IMPROPERLY enabled again.

I then stopped the schedule manually, restarted it and let calibration complete. Now DEC swap was correctly DISABLED.

[2019-11-24T01:23:53.887 CST DEBG ][ org.kde.kstars.ekos.guide] - Dither RA Rate 757.743 ms/Pixel
[2019-11-24T01:23:53.888 CST DEBG ][ org.kde.kstars.ekos.guide] - Dither DEC Rate 3867.13 ms/Pixel
[2019-11-24T01:23:53.888 CST INFO ][ org.kde.kstars.ekos.guide] - "DEC swap disabled."
[2019-11-24T01:23:53.892 CST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Calibrating" to "Calibrated"
[2019-11-24T01:23:53.892 CST INFO ][ org.kde.kstars.ekos.guide] - "Calibration completed."
[2019-11-24T01:23:53.897 CST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Calibrated" to "Guiding"
[2019-11-24T01:23:53.897 CST INFO ][ org.kde.kstars.ekos.guide] - "Autoguiding started."

This problem only appears if the scheduler is active AND then proceeds from the finished first sequence to the second one. If the scheduler is stopped and thus reset in between, the first target deleted from the schedule and then the scheduler restarted, the problem does not occur.

The question is, can this be fixed or is the scheduler irreversibly compromised and only semifunctional for mounts that do not transmit pierside information?

What are your thoughts?

Jo

I've spent some time checking the log and experimenting with a mount and the simulators.

It could be an effect of changing the declination from 65 degrees to -2 degrees. At the high declination the drift for dithering has high values while at the low declination this is reduced considerably in the RA direction. The result is that the corrections at low declinations are too large and this cause oscillations, the mount continually overshoots the correct position. Try halving the Proportional part of the guide corrections at low declinations.

It can't be the correction direction because if it was a correction would amplify the error and the mount would very rapidly wander off the correct position.

Unfortunately the Phi part of the calibration doesn't seem to be reported in the log but I wonder if a negative declination makes a difference. Perhaps Phi is rotated or mirrored and the dec swap corrects for this.

I don't think pierside reporting can make a difference because there's no mention of it in the guiding code. It is used to cancel the guide calibration but the slew seems to do that anyway.

Incidentally I noticed in the log a meridian flip slew that finished in a few seconds, far too short for the long slew involved in a meridian flip, then the first slew to the alignment position - the same position - took a long time It looks as if that was when the flip was done. This could be an indication that the meridian flip needs to be delayed slightly. It didn't matter in this case because the first plate solve failed but a retry was fine.

Anyway I'd try checking how sensitive guiding is at low declinations. A small offset should be damped fairly quickly, if it oscillated the gain is too high.

Chris

Hi Jo,
the log names the module that writes the log:
[2019-11-23T23:25:15.407 CST INFO ][ org.kde.kstars.ekos.guide] - "DEC swap enabled."
That means it is a log entry from the guider.

I agree with you that setting "DEC swap enabled" is wrong - the log shows clearly that as soon as the guider tries to correct in DEC direction, the scope drifts away. My only explanation is that this is simply due to a failed (but not detected) calibration. Why:

1. In the guiding module the calculation for DEC swap yes/no is based on deltas measured during calibration
2. This calculation is the only place that sets the DEC swap checkbox, which controls the DEC corrections while guiding
3. There is no code in the scheduler module that addresses DEC swapping.

Taking all this into account, the only explanation that I have is that this measurement during calibration had problems - e.g. with seeing problems.

-- Wolfgang

Thanks, Chris and Wolfgang,

I'll check those parameters. It is true that the iOptron SmartEQPro+ mount has a pretty bad periodic error, which unfortunately makes large correction pulses necessary, but I believe that should only come into play in the RA axis. Since I am using a wide-field scope (250mm focal length) and short exposures (60s), drift in the DEC axis should be minimal. So I will try next time to just guide only in RA and turn off guiding in the DEC axis in the guide module. That should still result in round stars and make little difference to the framing as long as my polar alignment is adequate.
The argument against Chris reasoning that the declination of the second target (NGC2023) plays a role is that I had no problem collecting about 150 well-guided frames AFTER I just turned off the scheduler and restarted it, this time with DEC swap disabled. The target was still the same, nothing in the mount setup had changed, the only difference was that I stopped and restarted the scheduler. Calibration steps and all other parameters remained the same. Therefore, the mount and the default guiding parameters were perfectly adequate to guide well at the low declination levels.

And, Chris, the mount DID wander very rapidly off position. By the time I caught it, it had migrated almost all the way down to M42, so almost 3 degrees off its original position.

Missed that, the bit of log I looked at had both axes showing the corrections alternating between increasing and decreasing.

It's very difficult to work out exactly what is happening, especially as the Phi paramater isn't reported.

One thing I'm uneasy about is that the start X1 and Y1 values are always integers. I'm not tat convinced that is correct and with changes of only a few pixels it could be significant.

Jo, the point is that during the scheduler run, calibration returned "DEC swap enabled" and when you started it manually for the same target, calibration returned "DEC swap disabled". I fully agree that calibration steps and all other parameters were exactly the same. Nevertheless the calibration significantly differs concerning the fact whether DEC swap should be enabled.

I still am quite sure that this is due to weather conditions or mount physics (backlash etc) and it is not the result of a software bug.

Jo, I would warmly recommend trying PHD2 at least for your iOptron mount. And I am not convinced that you will be happy with only RA guiding enabled. As you rightfully stated, there are several sequences where the guiding runs very smoothly.



Cheers
Wolfgang

Maybe some chime-in with flip-experience on the CEM60 with PHD2: Just went through one, and it didn't work. EKOS didn't inform PHD2 to flip the calibration. So while everything else had worked beautifully (re-point, align the target, in PHD2 select star and guide) the guiding was driving the star off. I had to stop, manually flip the calibration, and restart....

Exactly my experience with the iOptron SmartEQPro+, which is also using the CEM60 driver, and the internal guider, not PhD2.

I was prepared to accept that I was the only one who was seeing ghosts. I am glad to see that there is another Vampire Slayer joining the team now!



PS: I bet that if you had set "Always recalibrate" the flip would have worked just fine, but if you had another target programmed in the scheduler, that second target would have failed on initial guiding.
If you have a chance, try that and let us know what you find.

I cannot see right now how there would be a difference between the internal guider and PhD2 when it comes to resetting DEC swap.

Best

Jo

Well, from my experience with the previous mount (GP-DX, eqmod driver) I know flip works perfectly when the mount/driver reports pier side.

So I wonder if one solution could be to check (in EKOS) if the mount does support pier side info, and if not send a separate flip command to PHD2 before telling it to guide.

I'm afraid though that this wouldn't help at all for a second target which is in the other hemisphere. There a lot more logic would have to be involved to decide if a flip is needed or not.

For a final solution I think EKOS would have to keep track where it is, starting from the very first slew. And if one crosses(*) the meridian, set it accordingly. As long as EKOS is the only one commanding movements (no HC, and no auto-flip from the mount) that could replace the pier side info for those that don't have it. But that sounds like a quite invasive, with changes in many places...

(*) rather, the target coordinates are in the respective hemisphere. For meridian flip, the slew happens after you are already on the other side, so technically you don't cross. Still, if the internal pier side tracker says you had been on the other side it would toggle the variable...

Yes, that is what I proposed, essentially.

Just program the scheduler and the guide module to IGNORE the DEC swap command when "Always Recalibrate" is selected. Then the problem would not occur with those mounts that do not detect pier side. With the ones that do, just don't select "Always recalibrate" and all should be fine.

All we need then is a list of those mounts, one way or the other.

PS: Flip and reacquisition and guiding of second target works perfectly for me, too, with my Orion Atlas Pro, which uses the EqMod driver and which detects pier side (AND using the internal guider!). Again, perfectly matches what you are seeing.

I just don't see how this would be a problem with the internal guider. That has always worked for me with my EQMod mount.

It doesn't need to; there is a setting in PHD2, 'Reverse Dec output after meridian flip'.

** For details of mounts which report side of pier, see here:
github.com/OpenPHDGuiding/phd2/wiki/Reve...-after-meridian-flip
It seems the latest ioptron ASCOM driver does report pier side, so it must be the driver's responsibility to report rather than the firmware...
Cheers.