×

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: 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.

  • Posts: 969
  • Thank you received: 94
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
4 years 4 months ago #46173

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

  • Posts: 554
  • Thank you received: 138
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
4 years 4 months ago #46189

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


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

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

Time to create page: 0.696 seconds