×

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

Bi-monthly release with minor bug fixes and improvements

Dome Slaving

  • Posts: 193
  • Thank you received: 46

Dome Slaving was created by Gerry Rozema

I spent some more time digging thru the dome slaving code ,and found another rather significant discrepancy in the math, which I corrected. The other detail, to correctly handle a gem mount requires side of pier information, but not all mounts report side of pier, and, those that do are not always consistent. I added code to 'figure it out' based on the hour angle, which works well here.

Dome slaving is now accurate. I just spent an evening with a telescope wandering all over the sky, and had no issues with slit alignment, after every slew the scope was pointed directly at the center of the slit.

I wrote up a bit of a blurb on how I initially tested these changes, with photos and a description of the test procedure, you can read that here:-
astro.rozehaven.ca/astro/?p=223

I think this change will put the issue of slit alignment to bed for good. My test setup now shows the dome is placing the slit directly in front of the telescope in all directions
The following user(s) said Thank You: Jasem Mutlaq
6 years 6 months ago #19058

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

  • Posts: 472
  • Thank you received: 165

Replied by Jarno Paananen on topic Dome Slaving

Thank you, this is very informative as I just received my ScopeDome 2m dome yesterday and am writing INDI driver for it. I think I'll have enough problems without these math issues too :)
6 years 6 months ago #19059

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

  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic Dome Slaving

I added a significant set of changes to the basedome code for dome slaving this morning.

- re-visited the azimuth calculations after ferran pointed out another error. The last set of changes, altho 'less wrong' were not completely correct.
- Added snooping for mount side of pier. The dome now correctly picks up side of pier from the mount.

The pier side changes do account for a mount that does not give side of pier information. The way it works, pier side is initially set to unknown. When doing calculations for dome pointing, if the pier side is unknown, the internal math based on hour angle is used to determine the side. If the mount has sent pier side messages, then that data will be used.

There are still a couple of obscure corner cases to be dealt with, but for normal operations, this update should make dome slaving work correctly.
The following user(s) said Thank You: Jasem Mutlaq, Ferran Casarramona
6 years 6 months ago #19270

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

  • Posts: 79
  • Thank you received: 25

Replied by Ferran Casarramona on topic Dome Slaving

Dome driver also has a property to specify pier side manually.

It would be nice, if pier side is not provided by the mount driver, use de dome property instead.

One possible implementation is when snooping for mount side of pier and a value is get, modify dome side of pier, and then use the last one for calculations.
6 years 6 months ago #19296

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

  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic Dome Slaving

The way I implemented it, is very close to what you are suggesting. The dome property is initialized to 'unknown' at startup. If you adjust it manually, then it'll stay there if no pier side messages come from the mount. The caveat case I was trying to prevent with a bit more smarts, is when the mount is sent thru a meridian flip, to try and correctly anticipate the side of pier after the flip, which I did by setting pier side property back to unknown state when the mount gets the goto command.

Maybe a better way would be to use another internal flag for this case, and not touch the actual pier side property except in the case of a pier side message from the mount. That would probably be better.
The following user(s) said Thank You: Ferran Casarramona
6 years 6 months ago #19300

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

  • Posts: 79
  • Thank you received: 25

Replied by Ferran Casarramona on topic Dome Slaving

I'm trying to slave the dome with the most recent version and I get this message:
2017-09-10T20:17:02: GetTargetAz failed 0
2017-09-10T20:17:02: Geographic coordinates are not yet defined, triggering snoop...
2017-09-10T20:17:02: Active Snoop, driver: Astro-Electronic FS-2, property: GEOGRAPHIC_COORD
2017-09-10T20:17:02: Dome will now be synced to mount azimuth position.
2017-09-10T20:16:54: Calling Update mount to anticipate goto target: 297.911 - DEC: 8.91504

So, for some reason, my mount driver don't return geographic coordinates. I think this issue appeared some time ago and Jaseem solved it.
6 years 6 months ago #19306

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

  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic Dome Slaving

hmm, nothing changed in the fetching of co-ordinates from the mount, it's got the changes Jasem put in to force the refresh of the snoop when the values aren't yet set.

Does the mount have co-ordinates set in the Site Management page of the mount panels ?
6 years 6 months ago #19308

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

Replied by Jasem Mutlaq on topic Dome Slaving


Sorry about that. FS2 does not support setting of location, so it wasn't reporting this. I just made it accept whatever location sent by clients without processing the data. Please compile or use tomorrow's PPA.
The following user(s) said Thank You: Ferran Casarramona
6 years 6 months ago #19310

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

Time to create page: 1.275 seconds