Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Telescope aperture vignetting caused by 1 degree dome azimuth command resolution #20

Closed
dolphinzilla opened this issue Nov 30, 2019 · 4 comments · Fixed by #23
Closed
Assignees
Labels
enhancement New feature or request experimental Features that may not make it into a release

Comments

@dolphinzilla
Copy link

Due to the 1 degree default azimuth command resolution, telescopes with large apertures can experience vignetting of the aperture by the edge of the dome slit as the telescope/mount moves continuously but the dome only moves on 1 degree changes. For astronomers doing non-differential photometry this issue creates discontinuities in the light curves that are difficult to correct for. Problem observed with a Celestron C14 EdgeHD with a 0.7 reducer.

TA.Nexdome.Server-2019-11-30-MSI_dolphinzilla-MSI.log
TA.Nexdome.Server-2019-11-29-MSI_dolphinzilla-MSI.log

@dolphinzilla
Copy link
Author

PHD Log exhibits steps in the star SNR curve on the 1 degree dome moves

image

@NameOfTheDragon NameOfTheDragon self-assigned this Nov 30, 2019
@NameOfTheDragon NameOfTheDragon added the enhancement New feature or request label Nov 30, 2019
@NameOfTheDragon
Copy link
Collaborator

Proposal

  • The existing @GAR "Goto azimuth degrees" command remains unchanged for backward compatibility.
  • Introduce a new firmware command, @GSR,sssss "Goto step position". This allows the rotator to be moved to an exact whole step position. The firmware protocol was not designed to include floating point numbers so the proposal is to accept a step position and not an azimuth. The target whole step position must be computed by the driver or application plug-in.
  • There are 55,080 whole steps per revolution, so this gives a theoretical positioning resolution of 360/55080 = 0.00654 degrees.
  • Driver or application can compute the step position for a given azimuth as circumference / 360 * target azimuth
  • Driver or application can obtain circumference using the @RRR command, which returns the circumference in whole steps.
  • Dead zone still applies. Moves smaller than the dead zone will be ignored. Dead zone is settable using the @DWR command.

This will then require a new version of the ASCOM driver that uses the new command. Optionally, other drivers and plugins would also have to be updated.

Feasibility

Initial investigation suggests that this could be added to the firmware reasonably quickly and with low risk. The firmware would remain backward compatible with all existing drivers and plugins.

Recommendation

I recommend that this feature should be added to the firmware and a subsequent version of the ASCOM driver.

@nexdome Are you happy for me to go ahead and add this feature?

@NameOfTheDragon NameOfTheDragon added the experimental Features that may not make it into a release label Dec 1, 2019
@dolphinzilla
Copy link
Author

The experimental firmware version seems to work perfectly - I checked backwards compatibility with ASCOM driver 3.0.1 and ran it through its paces across the 0 point as well (left and right of zero azimuth)

@NameOfTheDragon
Copy link
Collaborator

NameOfTheDragon commented Dec 1, 2019 via email

NameOfTheDragon added a commit that referenced this issue Dec 2, 2019
Issue #20 add @gsr command to rotate to a step position.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request experimental Features that may not make it into a release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants