I forget to say if the telescope is at west of the mount, then you need to put OTA negative.

Hello all,

First, to fcasarra: Thanks for the spreadsheet! That I could do easily, and the results were interesting.

Here are the new tests from last night. The high level summary: The values calculated in the spreadsheet are different than those from INDI (Server, ICP, AT, etc), and appear to be even less correct than INDI.

Here is a detailed description:

1) I polar aligned the scope as an absolute positional reference.

2) I shown a flashlight through the polar scope port of my CGEM DX. It's wide illumination filled the port, and illuminated a point on the dome that is presumably within 1 degree of north. No amount of flashlight tipping would move the spot (it isn't a laser, it is a broad; see the attached picture named DefiningNorth). I defined the positioning of the dome to be at 0 degrees when the spot was centered on the shutter.

Continued from above:

3) Next, I decided to test the dome positioning at two positions that I think simplify the issues. I first put the scope on the East side of the mount dead flat, looking due north (see figure and picture). I believe this will remove any issues of offsets in pier position in the N-S direction. Thus, the only measurement problems I can have are E-W offsets, Up-Down offsets, and OTA length offsets.

In this position, the spreadsheet says the dome should be at 0.2°, INDI places the dome should be at 11°, and I estimate the dome actually needs to be at about 18° to be centered. Though it is hard to see in the picture, about 1/3 of my scope view is occluded by the dome in this position.

The software settings are shown in the attached image. Sorry for the crazy moire patterns. I also include the spreadsheet showing the 0.2° recommended position. Note that I have gzipped the file to allow it to be included here. I added .tar to the name also, to allow it to be uploaded, but it is NOT tar'd. Just rename it to DomeSlitEast.xlsx.gz, then gunzip it, and it should be a regular excel file.

4) Next, I repeated this test in the west. Note I changed the meridian setting in ICP to West. In this position, the scope was not occluded, but only just barely. The spreadsheet thought the angle should be -2.6°, INDI called for 341.8°, and I would estimate that it actually needed to be ~339°. Pictures, and spreadsheet below.

I interpret this to suggest that the the length of the OTA offset needs to be bigger, and the pier offset E-W larger as well.

5) As measurement 4 made me suspicious of my OTA offset, I include a picture of measuring it. It looks close to 14.5 to 15 inches, or 0.38 m, accounting for the parallax in the image and being on the hypotenuse instead of the desired quantity. See picture below. However, INDI seems to work better if I use 0.5 m. Then the dome rotates far enough in the E and W positions to not occlude the scope. Unfortunately, I have not been able to find and E-W offset that will center it. It seems to want a very big number, like 1m, that makes no sense, and only works on one side of the dome.

So what am I doing wrong?

As always, my sincere thanks,

Scott

Scott, Do you have a debug log?

It can be useful, because many partial calculations are logged.

Sorry for not been more supportive but I have not many free time this days.

Though I promised to record one, I forgot. Fortunately, this behavior is highly repeatable, so I will redo the measurements this weekend, and record a log.

Thanks for your support,

Scott

Hello Scott

it took me a while to get Obs. Vermes up and running. I checked the dome slit / mount synchronization and it worked reasonable.

regards, ciao, wildi

Finally I had time to take a deep look to Dome Sync and found some bugs in dome position calculation.

I corrected and a new version is available. Also I corrected google Spreadsheed son you can check the results there also.

Regards,
Ferran

Hi Ferran,

I am sorry for not getting you more information sooner. I think my will-power to fight these battles has sagged, but I will do my best to get fired up again. I will redo my test with the new update, and will be sure to record a log.

Thanks for looking at it,

Scott

Hello Scott and all

I got hold of P.T. Wallace paper about dome slit synchronization
(www.tpointsw.uk/edome.pdf) and implemented it as a Python
script and as a C library:

github.com/RTS2/rts2/blob/master/scripts/dome_target_az.py
github.com/RTS2/rts2/blob/master/lib/rts2/slitazimuth.c

Wallace's solution has the advantage being simpler and supporting
the cupola center versus HA/Dec axis intersection offset in x,y,z.

I tested it at Obs. Vermes (radius 1.26 meter) and the optical axis
pointed within 1...2 deg to the slit center with dec axis being set
to HA +/- pi/2 ("East", "West").

Before using it, read Wallace's paper and have a look at the
C library version. The script has an option: --test-wallace
which reproduces the values from the paper.

ciao, wildi

example values from the paper:
longitude: 0.00, latitude: 36.18, h: 2.50, dec:37.90
WALLACE : x_m: -35.0, y_m: 370.0, z_m: 1250.0, r: 0.0, p: 0.0, q: 505.0, rdome: 1900.0
WALLACE : lat: 36.182, h: 149.886 arcmin, dec: 37.901, dome az: 50.369/50.3694111 deg, el: 72.052/72.051742 deg
WALLACE_LB: dome az: 50.369/50.3694111 deg

WALLACE : x_m: -35.0 m, y_m: 370.0 m, z_m: 1250.0 m, r: 0.0, p: 0.0, q: 505.0, rdome: 1900.0 m
WALLACE : dome az: 305.595/305.595067 deg, el: 68.824/68.824495 deg
WALLACE_LB: dome az: 305.595/305.595067 deg

over the last few days, I found some time and got my dome set up properly for testing this stuff. In the process, I found an initial small error in the indi calcs as compared to the spreadsheet ferran has posted earlier, pull request on github now with a correction. But it's not completely right now either.

I did a bit of a write up on our blog, with photos and a description of the setup. What I have done is mount a webcam under the telescope at the mount, then put some alligator clips on the telescope to provide a target aligned with the scope. Then I re-did my optical offset measurements to line up with the aligator clip rather than the center of the telescope. I have also marked the center of the slit on our dome, so now I have a setup in place where i can slew the telescope anywhere during the day, and just look at the webcam to see how it lines up with the dome slit.

My write-up with photos is here:- astro.rozehaven.ca/astro/?p=197

As you can see, it's better than it was, but, not yet perfect.

Our dome has pointing accuracy of about 1 degree, tested over many slews in various directions. It's an NexDome, driven by a stepper motor system for which I wrote the firmware. I've done a lot of testing using various slews all over, then back to the home sensor to see how much slippage there is in the system, and it's not much. Rarely is the calcuated position off by more than a degree when it comes back to the home sensor.

In doing my initial testing with this, one thing I did learn, measurements of the offsets inside the dome are very important to be very accurate. Changes of just a couple cm can go from 'telescope lands in slit every time' to 'telescope often looking at the dome panels'. In our case, I'm using a 13cm telescope and pointing at a 60cm slit with a dome radius of 1.18m. The setup now is essentially 'good enough' that it seems to get the telescope into the slit every time, but, the second dome is going up next week, has the same geometry, but it's going to have a 30cm telescope pointing at that 60cm slit. For that one, I'll have to find the issues in the math and get pointing dead accurate, it has little extra room for error.