×

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

The mount may not send that signal, but wouldn't Ekos detect that it is sending commands to the mount to move across the meridian and that recalibration or calibration swap is required?

At least during the imaging of the first scheduled target that works, but when the second target it initiated, calibration does not seem to get swapped back. Ekos definitely has that information, since it accurately calculates the time until the next meridian flip.
4 years 4 months ago #46145

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

  • Posts: 1009
  • Thank you received: 133

Yes, that it does know. But it has no way of checking if that switch had actually taken place. Only the mount knows which side it is on, not based on coordinates, but based on the steps/position of the motors.

Usually you can give a good guess which side you're on (like, when the position is more than 10-15 degrees away from the meridian). But inbetween always both pointings would be possible, and where you are depends on the history.
4 years 4 months ago #46146

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

  • Posts: 554
  • Thank you received: 138
You need to read the declination axis position. If the declination axis position is in the range -90 to 0 t0 +90 you are on the 'normal' side of the pier. If the declination axis position is in the range -90/270 to 180 to 90 then you are on the 'alternate' side of the pier.

Maybe the mount has functions to read the axis positions, if that's the case then the driver can deterine the pier side.

All this only applies to GEMs a fork mount usually stays in the same pointing state everywhere.
4 years 4 months ago #46148

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

  • Posts: 1185
  • Thank you received: 370
@ Wouter: no, it does not affect dithering. I checked it both with the internal guider and PHD. After each slew the calibration is cleared. But when the guider dithers, it is not recognised as slewing. Hence for dithering the calibration is kept.

@alakant: this change applies to all guiders. If the option "Always Reset Guide Calibration" is selected, both internal and external guiders receive a "clear calibration" command for each slew detected. If the option is NOT set, all decisions about calibration are left to the selected guider.

Regarding mounts that do not report the pier side, I cannot answer it, since my mounts and the simulator support it. Needs to be tested, but worst case simply set the option.

HTH
-- Wolfgang
4 years 4 months ago #46154

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

  • Posts: 1309
  • Thank you received: 226
*Unpopular opinion alert. But I do not think recalibrating after ever slew is particularly elegant. There are occasions when calibrating in a different region of the sky is necessary. For instance calibrating near the celestial pole is not recommended, and may fail. It would generally add time to perform especially if repeated, such as occasionally going to a star to manually re-focus.
Narrowing the trigger criteria may help, such as if slews in Dec are substantial, as RA only impacts calibration when pier-side changes. But IMHO implementing declination compensation with recalibrations only after pier-side change and guiding failure is ideal.

Food for thought. Thank you
- Andrew.
4 years 4 months ago #46156

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

  • Posts: 1957
  • Thank you received: 420
@Wolfgang Thanks for the confirmation!
4 years 4 months ago #46158

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

  • Posts: 1119
  • Thank you received: 182

Hi Andrew:

The original reason for the recalibration after slewing is that some mounts, such as the iOptron mounts, do not recognize when they are slewing across the meridian. Which means that when using the scheduler, the second sequence is ruined as the previous calibration swap is not reversed. The only way to fix that is to recalibrate.

Not elegant, perhaps. But the problem in that case is with iOptron and other mount manufacturers that cannot get their firmware act together, not with Ekos. If there is another more elegant workaround to solve the problem, please let us know.

Jo
4 years 4 months ago #46159

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

  • Posts: 969
  • Thank you received: 94

Phew, I can once again sleep easy!
Thanks for the confirmation.
4 years 4 months ago #46162

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

  • Posts: 1185
  • Thank you received: 370
Sure, this was the last bug in EKOS - promised :)
4 years 4 months ago #46163

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

  • Posts: 554
  • Thank you received: 138
I've had a look at the iOptron driver code.
  • The iOptronV3 code has pier side implemented and it is read from the mount. No obvious reason why it isn't available.
  • The iOptronHC8406 code can read pier side from the mount but the INDI pier side capability is not set in the driver. This looks like a fairly simple change, but there could be a good reason why it isn't.
  • The lx200zeq25 code doesn't know anything about pier side. It's probably not possible but those may be fork mounts which don't need it.

from what I can see the InternalGuider takes no account of declination or pier side and so recalibration will be required if a slew makes a significant change to the delination or changes the pier side. Simplest is to always recalibrate after a slew. Changing pier side is only done when the mount slews so there's no need to check for a pier side change.

PHD2 allows for declination and pier side so once the compensation for changing pier side has been sorted there should, in theory be no need to recalibrate.

Manuacturers are becoming more aware of the need for good control firmware so if something like pier side isn't available it is worth asking them for it. Don't expect an independent driver developer to do it - his asking for a feature counts as one request, no matter how many people have asked him. If they all ask the manufacturer directly that's many requests.

Chris
The following user(s) said Thank You: Jose Corazon
4 years 4 months ago #46169

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

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

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

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

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

Time to create page: 0.887 seconds