Just a little bit about my imaging system because it might be contributing to the problem. I have a dual imaging system. Two FSQ’s with reducers and two QHY cameras. one is a QHY367C and the other is a QHY600M. I had the system running perfectly with my QHY367 and Nikon D810a. These cameras have the same chip and as a result the same arc sec/pixel values. I sold the Nikon and upgraded to the QHY600M. Last night was the perfect night for testing but was extremely frustrating for me because I could not get the 600 to plate solve. Got it to work a couple of times but could never repeat things. Solves easily with TSX. No problems plate solving with the QHY367. I double checked all the scale factors in both The Sky X and SGP. I pulled the arc sec/pixel numbers straight from the plate solve in TSX. So I developed a couple of theories, not sure if any of them are correct.
For some reason the arc sec/pixel values that I think are being imputed are not being used correctly. Maybe it is defaulting to the 367C values? I do switch back and forth and open two instances. By the end of the night I turned off the 367 but still had the same issue.
When I plate solve I notice the RA/DEC will be filled in but may be off. The angle is 0 and so is the scale. I tried inputing them manually. Maybe SGP is not pulling this data from TSX correctly? I am assuming SGP and TSX talk to each other but I could be wrong. The zeros in the angle and scale when plate solving bothered me. Thie plate solves are attempted by doing a “TAKE ONE” then right mouse clicking and “PLATE SOLVE”
In the ascom driver there is a box to allow you to crop the chip. Maybe that has something to do with changing the arc sec/ pixel values which affects the plate solve. Sorry I don’t know the exact name of that check box but I tried it checked and unchecked and nothing.
Gremlins?
That’s all I got… Hoping to give it another shot tonight. Maybe the gremlins have a star party to attend?
I was plate solving perfectly until last night. Did an SGP update and now I can’t plate solve two nights in a row. Even weirder I was able to blind solve and sync tonight but then when I slewed to targets I can’t platecsolve or blind so,be. I’m wondering if it’s the update. I haven’t changed any settings otherwise.
I plates solved the QHY600M from the TSX. Took all the data and tightened up the pixel array size. Used the plate solve numbers instead of the published numbers. Plate solve worked. I wasn’t happy because it was taking a long time. Now that I am looking at the log I noticed it solved from Astrometry.Net. Things got worse from there. I switched over to my QHY367C which was powered off just to make sure there was no mix-up. Everything worked as it should. Fast and effortless. I switched back over to the QHY600M and the first thing I noticed was the ANGLE field was populated. I new it was going to work and sure enough it did. Took a few seconds, solved with UCAC3. Then the clouds rolled in. Still not feeling confident. I am attaching logs. I did my best to document as I was going along but the success I had made me put my guard down.
Log 2: QHY367C successful plate solve and Back to the 600 with success. OHHH!!! I did re-direct plate solve app to the directories again even though they were green and showing OK Status. Not sure if that is what fixed things. Not sure if the log will show that. Dropbox - sg_logfile_20200806232122_Success_367Cand600M.txt - Simplify your life
OMG. I SAW that last night and thought “how cool it knows the camera angle now”. Should have been thinking “it shouldn’t know the camera angle!”.
Have wasted 2 clear nights because I couldn’t plate solve. Will try this tonight! Fingers crossed.
Well, I happened to notice astrometry.net website seemed to be nonresponsive around that same time. I tried to get it to blind solve and gave up when it sat there for 15 minutes or so. Had the issue all-night. Tried again the next night and was working fine. I noticed it does that now and then.
Hi, if I recall correctly, when you plate solve with many solvers, it can update the file, so a subsequent solve has a free ride.
Could you perhaps put an un-solved FITS file in a dropbox?
I would like to try and solve it with my array of solvers in SGP (PinPoint, ASTAP, PS2 etc). I know I sometimes have issues with ultra-wide fields and I sometimes have to reduce the magnitude limit to stop it being overwhelmed by stars.
Yes an image is worth a thousand words in this case. I have never tested ASTAP with 60 Megapixels. In any case it will be good to bin the image prior to solving.
I checked some flat image images of the QHY600 found on CloudyNights forum. Loading and processing worked fine, so the 60 mbytes is not problem.
The question now is if this binning x4 is correct. Normally ASTAP goes in auto binning not further then binning x2. The stars should not become too small otherwise they are seen as hot pixels. You should check the HFD value of one of your QHY600 images with the ASTAP CCD inspector. Start ASTAP directly, load an image in ASTAP and go to the tools menu, CCD inspector. In binning x4 the HFD value of the stars should be around 2 or larger. So in binning x2 the HFD >4 and in binning x1 HFD>=8. If not set binning at x2.
Alternatively take one of your images, bin it to x2 and x4 and try to solve these images in the ASTAP and see how many matching stars it finds in the log. How more matching stars it find, how better the reliability of solving. Use the binning with most matches.
Using the Zwo Asi 6200 (same CMOS sensor), bining 2X2 in Astap works perfectly. I build a model for my 10 Micron mount and platesolve 75 points in 20 minutes with no issues.
