I have Astrometry.net set up to plate solve, which works great. Most of my attempts to do a Center caused the mount to move perfectly in RA, but move in exactly the wrong direction in DEC.
I thought perhaps it was because I had the scoped aimed too close to the meridian and it did not know which way to flip. So I tried it again on something very far from the meridian, and it did the same problem. On each iteration of the Center it moved exactly the right number of degrees… in the wrong direction for DEC.
I am new, so I will assume I did something completely wrong. How does SGP know which side of the meridian the mount is aimed at? I thought maybe it just assumes the operator has aimed the scope properly before the first plate solve, but now I am not so sure.
Definitely check location settings in the mount. But in short, SGP doesn’t need to know side of meridian. It grabs a picture, solves it, syncs to the mount to correct the pointing, and then issues a goto if the pointing is off by whatever margin.
Where are you located? Might need to post some logs…
I had the terrible thought this morning that I had somehow had the DEC axis and saddle spun backwards, as it does go all the way around. But on my AVX, the clutch levers were positioned such that it can only go on one way, otherwise the levers hit the motor housing. (probably need to fix that, anyhow)
However I like your thinking that the mount itself might be confused. I can set it up inside and run some checks on the settings and test it out. I had go through some settings to find out if I am jNow or j2000, and could have messed something up. (its the newest Celestron firmware, so its jNow.)
Also, I manually moved the mount to point in the vicinity of m42 before plate solving the first time. As I am up in the northern hemisphere, this means the thing was pointed almost dead south with the DEC axis spun 180 degrees from Polaris. Could this have caused some confusion? When I start a session, should I have the scope pointed northwards near the home position and pole?
When I get home and set up a test scenario, I will collect some logs to analyze.
There is a known issue with using “Center Here” (right clicking on an image and having it center at that location) with Astrometry.net. It works fine with the other solvers.
Jared, actually I was using Frame and Mosaic wizard to generate a target list, and right clicking on the resulting target that to do Center Here. Would that still be a problem?
By “right clicking on the resulting target” do you mean in the target list of SGP? Or do you mean on the saved image?
If you’re using the target list then things should be working just fine. The issue is specifically with “Center Here” when you right click on an image. All other centering means should be working fine.
Yes, I mean the target list. I figured that would be fine since it knows the exact coordinates of the thing it will be seeking to. A single platesolve without moving will display the exact correct results. I made sure to aim manually at something I could easily reckoning (such as m42 or m45), to confirm.
Once I get a chance to test these suggestions out tonight, I will have some logs to see what is going on better.
I notice that when I tried to run the sequence, during each iteration of centering it would further and further away in DEC by exactly the amount it was off by. So if after the first platesolve DEC was off by 2 degrees, the mount would move exactly 2 degrees in the wrong direction. I am pretty sure it has to be something wrong with the mount or ASCOM settings not knowing which way to go.
Maybe wrong hemisphere? That’s what it sounds like at least. SGP just tells the mount to go to a set of coordinate. How the mount gets there is up to it. Might be good to pass those logs along and we can verify that SGP is at least sending the mount to the right place. After that it’s out of our hands.
So, the ASCOM camera simulator isn’t quite as easy to work with as I hoped. I will have to figure out some way to test using it.
I checked the Lat/Long on both the mount and ASCOM driver, and they are correct. The mount itself will seek to objects correctly when using the hand controller. I checked that the date was correct on both the computer and mount as well.
Attached is the log file from last night that shows my situation. At 10:15 or so I started a centering sequence. The RA/DEC change is:
Syncing to RA: 6.71497636165765 Dec: -3.0860120311937
Slewing to RA: 5.58605568358078 Dec: -5.34306960459257
Syncing to RA: 5.58804642010913 Dec: -0.483638292038889
Slewing to RA: 5.58605568358078 Dec: -5.34306960459257
Syncing to RA: 5.59065236335395 Dec: 4.37601314307114
Slewing to RA: 5.58605568358078 Dec: -5.34306960459257
Syncing to RA: 5.59699736385776 Dec: 14.0597714324896
As you can see it moved exactly the right number of degrees, but in the wrong direction.
I am really not sure what else to try at this point.
My best guess is that if I power up the mount with the scope pointed at an odd angle, the Celestron hand controller gets confused as to which way the dec axis is actually pointing, so when SGP tells it to go to some coordinates, goes the opposite way I expected. The scope hand controller says “set to index marks” when it powers up, but I always skip that since I don’t plan on doing alignment anyhow.
I am going to test this theory out once I get some images to test the camera simulator with.
Yep, I think I got it. The Celestron mount must be at the home position, or at least facing northish, when you power it on. This time when it did the centering slew it went the right direction. Now for some clear skies to test it outside.
If anyone else with a Celestron mount has found this is not necessary, let me know.
The AVX mount requires that the alignment is started with the mount at the index marks. This defines the zero position for the axes. If you don’t do this you might get some sort of alignment but I wouldn’t trust it.
The only exception is Hibernate/Wake up. You can hibernate where you like, the mount then remembers the axis positions when it wakes up.
It may be worth describing your start and align process in some detail.
The ASCOM driver logs as well as the sgp logs are essential for more help. They tell us what is going on from the driver’s perspective. Click on the Help button in the driver setup dialog to get more information.
Are you trying to get the camera simulator to provide an image of what the mount reports it is looking at? That’s a bit more than it was intended to so - more of a sky simulator. Perhaps a DSS image could be downloaded and used.
Thanks, Chris, I think that was the piece I was missing. I did not realize that the mount did something with the index position when it starts up.
You are also right that I had occasionally had plate solving and centering work just fine, so when I recently tried to use it, I was quite perplexed when it did not work. This happened because I manually moved the mount to point at something southwards before powering it up. Now I know to leave the thing alone before switching it on.
As far as my simulator test goes, I just needed to trick SGP into doing a platesolve so I could see which way the mount seeked. My procedure last night was.
Test 1: The way I was using it wrong.
Set up mount indoors and manually point it “south”. Pretending I am actually pointing at m42.
Tell hand controller date and time and do Celestron’s “quick align”, which just fakes the mount into thinking you actually alligned it.
Connect to mount with SGP.
Configure ASCOM camera simulator with a picture of something known near m42 (and that I know will pass the plate solver).
Use SGP Framing and Mosaic wizard to seek to m42.
Watch SGP logs to see which way it tried to turn the mount.
This showed the mount did move in the opposite direction as before.
Test 2: How you are supposed to use it.
Set up mount indoors and point it on the hash marks north. Pretending I am pointed at Polaris.
Tell hand controller date and time and do Celestron’s “quick align”, which just fakes the mount into thinking you actually alligned it.
Use hand controller to seek to m42.
Connect to mount with SGP.
Configure ASCOM camera simulator with a picture of something known near m42.
Use SGP Framing and Mosaic wizard to seek to m42.
Watch SGP logs to see which way it tried to turn the mount.
This time the mount moved in the correct direction for DEC.
It isn’t conclusive until I can run it outside, but with Chris’ note about the index position, I feel confident that everything is working as desired now.
Also, thank for the tip on Hibernate, I had always wondered what that function did. Seems like I will be using if I need to power cycle the mount in the middle of the session.
