I'd assume it is for that driver, but the only mount supported by that driver (AFAIK) is the CEM120. Other mounts still use the v2.5 protocol (supported by the ieqpro driver) that does not have the needed :GEP# command

I had already mentioned to ioptron support that it would be highly appreciated if the CEM60 would support pier side reporting, but I won't hold my breath fro this to happen.

Indeed, for mounts that support pier side info PHD2 just works.

Please do! This email address is being protected from spambots. You need JavaScript enabled to view it. I did already....
I agree that it is a quite crucial part for mounts like the CEM60 that is almost perfectly suited to be run in a fully automated observatory. The lack of pier side info is a real nuisance.

Thanks, Chris! That is very helpful.

My iOptron mount uses HC8408, not HC8406. If you have the chance, could you also look whether that can detect pier side? Unfortunately, I don't know how to do that, but if you can send me instructions on where and what to look for, I would be more than happy to learn.

Thanks so much and best wishes,

Jo

Hi
It's:
indi_getprop
an example with eqmod:
indi_getprop 'EQMod Mount.EQUATORIAL_EOD_COORD.DEC'

indi_getprop error
gives a list of options

indi_getprop
lists all current values
HTH and clear skies

I don't have any iOptron mount, all I'm doing is reading the code for what I think are the iOptron drivers. The code I looked at is ioptronHC8406.cpp.

The ieqpro code doesn't mention pier side at all.

The thing to look for in the code is 'pier', all the functions and properties will have that in it somewhere.

Chris

That's correct, iOptronv3 only works for CEM120 at the moment. If iOptron adds PierSide via a firmware update then it could be incorporated into the driver.

Also, one note about the internal guider. This originally came from lin_guider. At the time when it was forked, it didn't have any methods to account for changing meridian side. The calibration determines a few things:

1. Guide rate required for dithering.
2. Phi, the angle used to create the Z-rotational matrix that transfers the differential image coordinates to the differential changes in the equatorial plane.
3. Declination swap used to switch N/S pulses depending on the meridian side.

On changing pier side, both #2 and #3 need to be updated if you do not want to recalibrate again. In principle, both #2 and #3 can be updated after a pier-side change, but it was never done in the guide module. The re-calibration is always guaranteed to recalculate these variables correctly, albeit at the expense of time. Maybe someone can try to go the math route? If it is working in PHD2, there is no reason why it shouldn't work in Ekos.

[/quote]

The re-calibration is always guaranteed to recalculate these variables correctly, albeit at the expense of time. Maybe someone can try to go the math route? If it is working in PHD2, there is no reason why it shouldn't work in Ekos.[/quote]


I think I may just have found an exception to that rule - or at least a bug that negates the effects of the recalibration.

I implemented Wolfgang's fix and recompiled Kstars from the latest git.

The fix does what it is supposed to do: Everytime the mount slewed and the guiding module was active, it recalibrated.

So far so good.

However, when I ran my schedule for 1. sequence IC1848, after completion 2. sequence NGC2023 again, which had produced star trails the last time, I ended up with star trails again!



From the logs it looks to me that Declination Swap was first enabled at 2019-11-23T23:25:15.407 CST when IC1848 had passed the meridian and the mount had flipped, then that sequence ended at 2019-11-24T00:05:17.304 CST and NGC2023 was started as planned, mount slewed back across the meridian and guiding was recalibrated, but at 2019-11-24T00:07:47.402 CST Declination swap was enabled again resulting in star trails for the consecutive images until around 1.23 AM I manually stopped the scheduler and restarted it. Only that led to the Swap being disabled again, until 2019-11-24T02:09:41.406 CST at which point it was reenabled after NGC2023 had crossed the meridian and the flip had occurred.

So it looks to me the problem lies in the scheduler, where Declination Swap is not reset between targets. Is there a command that can just reset the Declination Swap once one sequence is finished and before the next one is started?

Complete log is here: www.dropbox.com/s/bgvi2dmb5vg9ry4/log_19-43-09.txt?dl=0

I hope this helps with fixing the problem.

Jo

PS: Perhaps the simplest way to fix this is to instruct the scheduler to just recalibrate after a Declination swap has occurred? Of course, only when "Always recalibrate" has been selected.

Jasem,

based on how the code is structured, what would be the simplest solution and what would be the limitations of any potential fix to this?

I assume that this will affect all mounts that do not transmit pier side information. It seems to me this has nothing to do with the internal guider vs. PhD2 guider, but that this is an exclusive concern of how the scheduler handles the sequence of flipping and realigning.

Do the solutions I have proposed make any sense?

Also, is there a list of mounts that transmit pier side information to Ekos and especially mounts that do not? It would make sense to let potential buyers know of these limitations beforehand, it could save a lot of grief later.

From what I am gathering from this experience so far is that, unless a solution can be found, I am limited to one target per night using automated imaging with the iOptron SmartEQPro+ mount. I assume that limitation would affect all iOptron mounts using the same driver, so also the CEM60?

What is the experience of CEM60 users? Can you schedule more than one target using the scheduler, or will the second target suffer from the same guiding problems?

Thanks for your thoughts on this.

Jo

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.