I’ve now had an issue in my last three imaging sessions. SGP performs the flip and auto center just fine, but in evaluating the images later, the flipped image is off by more than my tolerance (30 pixels ~ 36 arcsec). Everything works just fine in the flip, and the auto center throws no errors, but it isn’t centering with the precision it has in the past. This has occurred on both the 126.96.36.199 beta as well as the latest 188.8.131.52 release. Attached are my log file, .SGF file, a screenshot of the PI images overlaid on one another (image 5 was pre-flip, image 6 was post-flip, rotated in PI), and a screenshot of the image FITS headers (image 5 is pre-flip, image 6 is post-flip). Any help anyone can provide as to what is going on here would be most appreciated! Thanks!
sg_logfile_20170224203807_flipfail.txt.zip (237.2 KB)
Leo Trio.sgf.zip (431.2 KB)
Something similar happened to me. However, I had a problem with the plate solve pre-meridian flip. The plate solve became less and less accurate with successive frames until it (and meridian flip) was aborted. Unfortunately, my log files form that session are long gone.
As an added note, I’ll add that I am still running on ASCOM 6.2. Not sure if an upgrade to 6.3 would resolve this at all, but thought I would make mention of it.
I also keep having this issue. After the flip the log files say it is less than the tolerance but when stacking, the images are off by up to 20x the tolerance
Same problem here. I upgraded to 184.108.40.206 from 220.127.116.11 and started to use the new MountWizzard software for 10u mounts. Now the centering is way off for the first plate solve. Sometimes over 600px. I’ve described this problem on the 10 u forum last night. The problem is clearly illustrated in the second video that Broke Astronomer did. Here is the links:
- YouTube. There are two videos. In the second one, he shows a 300px+ error 59 seconds into the video.
With my model, my PA is showing 1’23". With the older version of SGP I could slew to an object, center within 1px or less, and then focus on the first centering try. Now it might take 2-3 tries before it centers . I always do this before I hit run sequence. I’ll post this thread on the 10u site also.
I am having the same problem, aprox 100 pixels off after meridian flip although platesolve says I am centered.
Using ASCOM 6.3 and astro-physics Mach 1.
I had a similar issue last night. I was imaging two objects in the same sequence. The first object slewed and centered after the flip well within the desired error and the image files do show it was in fact centered. Later in the evening with the second object did not centered well after the flip. The error looked like it was around 400-600px even thought the reported error was within 50px.
Was previously running version 18.104.22.168 and had the Telescope option set to to “Sync”, but not sure if it should be set differently running 22.214.171.124.
Could you post the FIT of your image prior to the flip and the image after the flip?
Absolutely! Please find them attached. Frame5 is before the flip, Frame6 is after the flip.
Frame5: Dropbox - File Deleted
Frame6: Dropbox - File Deleted
What are you using to solve the image? ANSVR?
@rockstarbill, I use PlateSolve2 as my primary solver, with ANSVR as my blind failover. The log seems to indicate the solve on the flip did not require the blind failover and solved with PS2, but the initial solve for the evening did failover the ANSVR. I usually start my AP900 at park 3 and then solve to my target. However, I’m not exact about how I place the mount for park 3, so it isn’t unusual that PS2 will failover to ANSVR for the initial solve of the night. It is an interesting point, however, that the initial solve was with ANSVR and the flip solve was with PS2. Is it possible that the two solvers are solving the field differently?
Of course it is. They use two different sets of data entirely to perform the solves. While the PlateSolve2 catalogs may contain the same data that ANSVR does, there is no way that the process of achieving the end result is the same. I believe this is why you have two images with different fields of view.
If you could reproduce this failure, using the same solver, then I would question not SGP but the solver itself. Knowing now that you had 2 different solvers in this equation I think it is fairly safe to say that the solvers conflict caused this.
By the way, I knew you had two different solves in this.
Scale is different.
Use ANSVR for all solves. IMO way better solution is to use Astrometry, which ANSVR is a nice solution that gives Windows users access to the industry standard for plate solving. (Astrometry.net).
I run my imaging on Linux with INDI and KStars. I use SGP on Windows as a backup in the event that I get a bogus INDI build. All of my plate solving is done via a local copy of Astrometry and my flips are flawless.
Sure thing, here they are. Links for the plate solve images are below too. The two for the start of the object and two for the flip.
@rockstarbill - interesting. I hadn’t considered it before (mainly, as I haven’t had this issue before). I’ve been using PS2 with ANSVR as the blind failover for some time and this issue only recently started occurring (since the 126.96.36.199 beta). I’ve definitely used the failover process before and ended up with the same FOV before and after the flip (Of course, those log files don’t exist anymore ). My flips generally are flawless…this is a new phenomenon. I’m not saying this isn’t the cause, but I do find it strange that it just started happening. Perhaps I just got lucky beforehand?
I have noticed this behavior as well. When I was imaging the horsehead, images on one side of the meridian did not have Alnitak visible (it was just outside of the frame), but it was fully in the frame on the other side. It has created significant stacking artifacts that require a fair amount of cropping.
just piling on that i have seen this as well in the newer betas. post meridian-flip centering is off sometimes, but not always.
Given the number of people here who seem to be experiencing this issue combined with my past successes of using two different solvers in the same sequence (PS2 and ANSVR), I’m disinclined to name the use of that functionality as the culprit just yet.
Last night experienced bad autocenter my self using 188.8.131.52.
Last week imaged same target, same version SGPro and autocenter after meridian was good.
Actually saw how autocentering was way off the target, but resumed on guiding and continued to imaging. Paused the sequence, right clicked on target, issued “center on target”. PlateSolve run smoothly and in a minute I was back again dead on target and resumed the sequence.
Flip and centering happend around 23:05, here is the log:
sg_logfile_20170304024329.txt (455.2 KB)
I don’t know if this is being looked into or not from Ken’s reply where he hints at the problem being possibly caused by “other” software. There appear to be quite a lot of others that are having the same problem, and I’m sure that most haven’t change anything other than going to a latest revision of SGP. Here are my logs and screen shots:
Usually, the plate solve works after the second or third try. Before upgrading, plate solves with centering worked the first time. Guess it’s up to you guys to decide if this is something that needs work. I’m just reporting what’s going on. In the meanwhile, I’ll go back to 184.108.40.206 and see what happens there.