Where does PlateSolve2 take the location settings from?
- From the site settings in SGPRO?
- or do I have to put them manually in PlateSolve2 settings?
Thanks!
Martin
There is nothing for you to do in this window. SGPro will handle all of this during sequence execution.
ok, and where does Platesolve2 take this data from? I am not able to plate solve with Platesolve2. Blind solve with astrometry.net works with no problems. I have checked SGP settings and the only incorrect value I found was the default location in the Platesolve2 settings. I had to change it manually but still not able to plate solve. Could you please check the attached log file?
https://1drv.ms/u/s!AuflUIwNAnYhj6Ja1D6eFJTcRbCudw?e=vZ3ohh
For location, from the mount itself and for scale, it takes a user defined value in the Camera tab of the control panel.
ok, my settings were fine, but somehow there was a wrong location value there which I only managed to change manually.
Could you take a look a the log file? I am not able to platesolve anymore. It always worked flawlessly with older SGP versions until I installed a new SGP version it stopped working, dont remember when cause I dont image often
Thanks
Not sure what this means. A wrong location value where? Are you talking about a solve of the scope’s current position or a solve of an image off disk?
Unfortunately they won’t mean much to me as I am unable to verify if the data fed to the solver is correct. There is a 99.9% chance the issue here is one or more of these:
- Scale in the camera tab is not for 1x1 (no binning)
- The mount’s position is not synced to the sky (or is, but there is too much error)
- Insufficient data ← this seems the most likely candidate as your exposures are only 4 seconds.
a wrong location value at the Platesolve2 settings which I only managed to modify manually
that´s not the cause, I use PS2 with Modelcreator and a 10micron mount to build the sky model with the same settings as in SGP with no problems.
Strange is that PS2 with SGP does not have a “search center” value. That seems to interrupt the search start. Also the catalog value is missing.
On the contrary PS2 with MC has a search center value and the search begins
Those location values you are referring to do not mean anything to SGPro… when SGPro starts up the PS2 solver it overrides those values with values from your mount (or the FITS header). As a note, you may have better luck with ASTAP.
thanks for your suggestion, I have installed and tested ASTAP, it works flawlessly with SGP
IMHO there is some problem with the SGP-Platesolve2 interface because it use to work perfect in the past
Not that I’m aware of… haven’t seen any other reports like this. As a note, ASTAP was written to “look” like PS2 so SGPro literally uses the same code to communicate with both PS2 and ASTAP. That said, reaction to ASTAP has been extremely positive.
Apologies if my attempt at asking a question is in the wrong place.
I recently changed my mount, and port 8080 was taken over by the new mount. I was forced to change my astrometry.net port to 7900. I chose that number based on another forum participants post. Also based on his post, I made sure that the plate solving endpoint specifies the new port. When I actually try to use the new endpoint in SGP, the plate solve fails immediately, and the SGP log shows the endpoint as using port 8080. I have restarted my computer hoping some cache would clear, but no matter what I have done the problem persists. Can anyone offer and advice on where I go from here?
It doesn’t matter where you post really, but it is best to start a new post.
How did you go about changing the ANSVR port?
I changed the port in astrometry.net by uninstalling astrometry.net, then reinstalled it completely.
I found that I had to restart my computer to clear the caches, then when I ran the astrometry.net config, it came up, and the log showed the new port of 7900.
In SGP, I changed the setting as shown in the earlier image, then clicked OK and SAVE. The port 7900 now comes up every time I revisit the Other Plate Solve Options window, but when I try to actually use it, the SGP log still shows 8080.