Redefinition of Home Sensor Position Counter-intuitive

[ron crouch]

Home sensor azimuth previously defined as 0 degrees. To refine position was dedefined as 358 degrees in ASCOM setup. Then a slew to 350 followed by Home was done. Resulting position of course remains physically the same but recognized as 2 degrees rather than 358 degrees.

‌

I have updated bug to “blocker” because unless a user happens to have “home right at 0” the azimuth tracking can never be correct.

On complete exit of server followed by restart home definition now 359 rather than previous 2 so NAB rather a documentation issue. 2nd png included.

Getting confusing sorry:-). This really is an issue. Looking at dome slot centering with a redefination of home as 358 or as 2 (initially set as 0)…. same slight offset to same side of center observed. So with this initial observation it appears that home definition from 0 only goes in positive direction. Had to c;lose up and stop as highwinds and storms nearby. FYI “findhome” has worked perfectly now tonight 6 times more with the new closer home magnet location.

[Tim Long]

I’ve been thinking about this, and it doesn’t make sense to reference this to any part of the dome. The unknowns are:

• How is the dome structure installed with respect to true north? (this dictates the position of the sensor with respect to north)
• Where is the magnet installed around the dome circumference?

These can vary independently from one installation to the next and both must be taken into account to determine the correct “home” azimuth. Therefore, the measurement we need is:

Starting with your shutter opening facing true north, how far must you rotate the dome clockwise to reach the home sensor? That is your Home Azimuth.

This measurement only requires true north as a reference point and is independent of the dome and magnet orientations. Make sense? The action then is that I should delete the word “sensor” from the UI and amend the popup tooltip to read as above.

[ron crouch]

I agree with this definition because it cuts through a mess of variables. In my case the answer is -2 degrees more or less.. “0” is good enough for slaving for me.. You are thinking quite clearly.

[Tim Long]

OK so far so good. Now in your dome, the charging contacts appear to correspond with the home sensor quite nicely. Is this always the case, or can the user choose to install those anywhere around the dome?

[Tim Long]

Downgraded from Blocker to Major so that it no longer blocks beta release.

[ron crouch]

I do not know.  To me it seemed obvious to do so. I would consider it a reasonable practice but I do not recall any actual documentation or guidance about the matter. IMHO there should be some guidance from NexDome on the matter.

FYI.. If I set ACP Dome Az bias to +2 it utterly centers my OTA.  Now I can get a fatter scope I guess :-)..  Been outside with iPad slewing around..

Ron

[Ron Kramer]

I did the same - my home sensor was placed after I centered my dome to my scope at PARK3. So my home is “0” give or take… it’s not like splitting the atom… sometimes AZ is 1 sometimes 359 or 0. I almost always have to nudge it left or right 1-2 deg to connect to contacts. I’m trying about modding them to be wider. (span 2 degrees). by making the contact plates larger.

YES it can be installed with home anywhere. Which might be fine if there is a user selectable PARK dome position?

[ron crouch]

Look in NexDome driver setup dialogue!!  Park is indeed user definable and need not be same as "home".

[Tim Long]

Also, the ASCOM SetPark() method should work as you might expect

[George Silvis]

I’m looking for the feature to be able to set the azimuth of the home position. My home position is about 305. But the system won’t let me change it from 0.

The Ascom Dome Control Panel has a setting: Setup/Sync Home Azimuth to (check box and value edit). This doesn’t work with the Nexdome driver.

Maxim also has a setting: Observatory/Dome/Options/Setup Sync set a value to be set upon finding Home. This also is not working.

This is essential to making this driver work. The only fixed position of the dome is when it sees the magnetic sensor. You need to be able to assign an azimuth value to this position.

All other positions are relative to that fixed point. And with the rotator gear skipping and hopping over the join of the two ends of the tooth strip glued to the dome (my setup has a 1/4” gap which skips the rotator gear) I can see the need to frequently having to seek home and resync to the known value.

[George Silvis]

What version of the server is being run in the Home_Definition.png image above? I’m running TA.NexDome.Setup-x64-3.0.0-beta.1.msi and it does not have Dome Parameters section with the feature to set Home Azimuth.

Thx
George

[Ron Kramer]

I didn’t read much past the first paragraph but home is where you put the sensor? So place your dome where you want it to be when homed. (mine is N in line with the scope at park3 toward polaris). Then move your magnet home sensor to the spot in the dome where it aligns with your rotator control box. voila… home is been reset and will be 0 at your desired position? (or am I missing something?)

[Tim Long]

@George Silvis That would appear to be the correct version, but if you are not seeing the correct stuff in the setup dialog, then perhaps you are not running the version you think you are. Please check a recent log file that you will find in C:\Users\{your-username}\Logs. You should see this:

23:59:11.3373|INFO |Server          |Git Commit ID: "bd24855c6a265d72429e54dd7e94cbf926fb8747"
23:59:11.4903|INFO |Server          |Git Short ID: "bd24855"
23:59:11.4903|INFO |Server          |Commit Date: "2019-07-02"
23:59:11.4903|INFO |Server          |Semantic version: "3.0.0-beta.1"
23:59:11.4903|INFO |Server          |Full Semantic version: "3.0.0-beta.1+0"
23:59:11.4903|INFO |Server          |Build metadata: "0.Branch.release/3.0.0.Sha.bd24855c6a265d72429e54dd7e94cbf926fb8747"
23:59:11.4903|INFO |Server          |Informational Version: "3.0.0-beta.1+0.Branch.release/3.0.0.Sha.bd24855c6a265d72429e54dd7e94cbf926fb8747"

[Ron Kramer]

In other words - I think home is where ever you have it placed when you stick on the homing magnet on the dome.

[George Silvis]

There seems to be a fair amount of confusion over Home azimuth. Might as well chip in my 2 cents.

Azimuth values are all measures of where the shutter opening is relative to true north. Home azimuth is where the shutter is when the rotator is at the ‘home’ magnet. Similarly, ‘park’ azimuth is the shutter position when the shutter is positioned to connect to its battery charger. These values do not need to be the same.

So the software needs to let you set both the Home azimuth and the Park azimuth. The special wrinkle is that the Home azimuth setting is used to reset the current dome position upon completion of a “find home” operation. This is the only automatic sync option available.

I would like to put in a plug for giving the user access via the driver to re-sync the dome current position at anytime. For instance: If there has been a gear slip and the target azimuth is x deg and the scope is not aligned to the slit, then I would like to: 1) turn off scope sync, 2) move the dome by hand until the scope is looking out the slit 3) tell the controller that its current position is now x, 4) turn the scope sync back on.

The alternatives to that process are now 1) find home and let it resync there or 2) shut down the dome driver so you can get Putty terminal access to the rotator and use a cmd there to set the current position.

George

[Ron Kramer]

yes there always was a home and park position user definable. It would be nice.

[George Silvis]

In version Beta.9 I now see the Home and Park Azimuth setting widgets in the setup window, in the Rotator Parameters group box.

[Tim Long]

This appears to be resolved by beta 9 and later