×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

What means always for resetting guiding calibration

  • Posts: 1119
  • Thank you received: 182
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.
4 years 4 months ago #46276

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138

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.
4 years 4 months ago #46280

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
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
4 years 4 months ago #46301
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133

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....
The following user(s) said Thank You: Jose Corazon
4 years 4 months ago #46304

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
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!

:) :evil:

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
Last edit: 4 years 4 months ago by Jose Corazon.
4 years 4 months ago #46305

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
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...
4 years 4 months ago #46308

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
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.
Last edit: 4 years 4 months ago by Jose Corazon.
4 years 4 months ago #46311

Please Log in or Create an account to join the conversation.

  • Posts: 969
  • Thank you received: 94
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.
Last edit: 4 years 4 months ago by alacant.
4 years 4 months ago #46318

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
What is really needed is for more mounts to report the pier side.

Here is a suggestion - when a slew command is issued use the hour angle of the slew destination to determine pier side. if the hour angle is less than 0 the pier side is West (pointing East) and if the Ha is > 0 then the pier side is East (Pointing West). There's a zone close to the meridian where the pier side might be wrong if the mount model doesn't change pier side exactly at the meridian but most of the time it wil be correct. Pier side can only change when a slew is done, not when tracking, not even across the meridian.

This needs changes to drivers but could help.

Chris
4 years 4 months ago #46322

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
That's a good way to simulate the pier side. Nevertheless I'm not a fan to drag this inside of EKOS but leave this inside of the INDI driver. Maybe we could add this function in a foundation class like inditelescope.cpp so that we do not rely on all single manufacturers to implement it.

Nevertheless, it's a workaround and does not cover all edge cases and pier side strategies of all mounts. The ultimate point of truth is the mount and it's firmware, since it ultimately decides wich way to turn the axis.
4 years 4 months ago #46325

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133

Oh, I indeed overlooked that. I was (only) looking for EKOS options to tell PHD2....
The question then is, how does PHD2 detect a Meridian flip? Maybe they already have the code that we are looking for?

Hmm, not too informative that table. Just to say ASCOM supports it so not needed to set is a bit Windows-centric :(
I still wonder how that driver is doing it. Unless you have access to the raw coordinates of the motors you can only guess and/or derive it from the command history, or am I missing something here?
4 years 4 months ago #46326

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138

Sorry, it seemed so obviously a mount function that it didn't seem worth saying so explicitly.

I'll have a look, initially for individual drivers but as you say it could go into the base telescope class. It needs thinking about because not all mounts need pier side, fork mounts for example don't usually use this.

Chris
4 years 4 months ago #46327

Please Log in or Create an account to join the conversation.

Time to create page: 2.288 seconds