I ran a sequence that I had successfully used a couple of weeks ago. I finally had to increase the center accuracy to 200 pixels to get the centering to work. In every case the plate solve using Platesolve 2 was solving within a few seconds. I looked through the log file but could not figure out what was preventing the slew to center from working. I have attached a link to log file. I am using version 2.4.3.25.
Fred K
I am having the same problem after a flip. Are you using EQMOD ??
I looked through your logs. Since you are not seeing plate solve failures and SGPro is asking your mount to slew to the proper location during the centering process, it is usually one (or more) of a few things:
This is not related to the issue you are experiencing.
Dennis,
I am not using EQMOD. I am using a CEM60 with the iOptron ASCOM 5
drivers. In my case a meridian flip was not involved. I was surprised
because the same sequence had worked perfectly a couple of weeks ago.
Obviously, something must have changed, but I don’t know what it might have
been.
Fred K
Ken,
I forgot to mention that my setup is permanently installed in my
observatory. I know my polar alignment is not perfect. PHDLab reported
the polar alignment error around 10 arc-minutes during my previous session,
which was two weeks ago. I will check the clutch settings on my mount…
The CEM60 clutches are a bit tricky to adjust. I’ll readjust them and give
it another try. I also plan to use PHD to refine my polar alignment next
session. I am running the latest iOptron firmware and ASCOM driver.
Are most of SGPs settings captured in the Log file? I may go back to the
prior log and see if I inadvertently changed some settings.
Fred K
Yes, but the way in which they are logged may not be immediately obvious…
Please don’t forget that in my case and no doubt others the problem is that the mount does not exactly land where it was told to slew to. As a result repeated syncs and slews will not improve. I have provided a number of suggestions to make this work in sgp.
Frank
I retried the sequence last night. I started out the evening by doing a
Drift Alignment using PHD. I was able to get a very good polar alignment.
I then restarted the sequence that I was having trouble with. I adjusted
the centering parameters to allow a 200 px error and 10 iterations. The
initial slew was plate solved as the following errors: RA=35px, DEC=659px.
I looked at each iteration and the error values were barely changing. In
fact it seemed that the mount was not slewing at all. After letting the
centering run until it failed, I was concerned the SQP was not
communicating with my mount. I went to the slew keys on the iOptron ASCOM
driver and was easily able to bump the mount into the right location.
This is all very confusing because the only problems I have had centering
in the past were caused by failed plate solves. Prior to the start of the
session I also made sure the clutches were properly adjusted. I have
attached a link to the log from last nights session.
SGP Log File
https://dl.dropboxusercontent.com/u/19284862/sg_logfile_20160329220449.txt
Fred K
There are two main possibilities. Either the mount thinks it went exactly where it was told to go, but backlash or something introduces a consistent error for that target. Or, the mount tried to hit the target but didn’t do it exactly and its encoders are aware it slightly missed.
In either case I would expect the error to be different in different parts of the sky. Your issue sounds like dec backlash and maybe you can rebalance it or something.
But the fact that the plate solve does correctly measure the error from the target and a slight nudge will center it suggests the sync/slew won’t work here. I have provided two ways around this problem as feature requests.
Frank
I think I may have figured out the source of this problem. Yesterday, while confirming I had the latest firmware on my CEM60. I spent some time reading the iOptron firmware update history and discovered the following comment for the latest firmware release (V20151018):
Alignment model will roam between the hand controller, RS-232 port connection and Wi-Fi connection now. If you want to use any pointing enhancement software, such as T-Point, make sure there is no alignment model in the system!
Just prior to starting the failed sequence I had done a one star alignment of the mount. I thought this was good standard practice. However, it appears I may have shot myself in the foot. I am not sure what commands SGP sends to the mount to do the centering, but based on the statement in the latest CEM60 firmware update, it may be that the CEM60/ASCOM driver is continually over-writing the SGP corrections? If this is the case, it would explain why the RA and DEC errors hardly changed during the 10 iterations of my “centering” sequence. I have to assume that the successful session I had a few weeks ago must have occurred because I did not have an alignment model in the hand controller; however, I am not sure.
Are there any other CEM60 users out there that can comment on my theory?
It is going to be a few days before I can test my theory because our clear skies have departed for a few days in Indiana.
Thanks,
Fred K
Some mounts handle sync in different ways and yours may have a setting to make it work. Sgp wants sync to mean “tell the mount this is exactly where I’m pointing.” But some mounts use sync to mean “add this point to the pointing model and refine the model.” The latter would not work well for centering and it would mess up the sky model. So I would look to see if you can change how sync behaves.
Frank
I wanted to report that this issue has been solved.
Here is some background in case anyone else is experiencing “Centering” failures with their iOptron CEM60.
I am using the latest iOptron firmware: V20151018
Starting with this version of the firmware:
The Alignment model will roam between the hand controller, RS-232 port connection and Wi-Fi connection now. If you want to use any pointing enhancement software, such as T-Point, make sure there is no alignment model in the system!
When I tried centering SGP would make 10 attempts and the mount would only move one or two a few pixels in RA and DEC on each attempt. It had worked on a night a couple of weeks before on the first attempt (< 50 pixels). Therefore I could not figure out why it would not solve two weeks later. I finally concluded that I must not have had an alignment model in my CEM60 during the time where the centering worked.
**
**
I started off by using the CEM60 hand controller to clear the alignment data (MENU>ALIGN>CLEAR ALIGNMENT DATA)
Once it got dark I started my sequence and it slewed the mount close to the object. It did it’s plate solve and center operation. It was able to bring the object right to the correct location on the first try.
If you are using SGP and are doing plate solving and centering
be sure to clear the alignment model from the hand-controller before starting your sequence.
Fred
Fred,
I’m so glad I found this thread to help confirm what’s been going on with me the last several nights since I moved my iEQ45 Pro onto my patio (Summer Position) from my deck (Winter Position). I posted about this same issue with my iEQ45 Pro awhile back:
I ended up doing the same - clearing the Alignment Data back then and it appeared to resolve the Centering issue. Honestly, I think the best solution is to simply keep the HC disconnected as you can run the mount via the iOptron Commander when imaging and only connect the HC when you use it visually. Aka This way I can keep my alignment data when I want it.
I’m going to give this a whirl tonight.
Just to confirm that I had the same problem and resolve by disconnect HC.
Thank you for start this topic.