what version of ASCOM and SGP you using ??
ASCOM 6 and SGP 3.2.0.0660
6.5 or 6.4 ???
I am trying to narrow down possible combinations that cause issues 
Can you provide a link to a couple of your images that are failing to solve? Always interesting to experiment.
Mike
Turns out that it’s ASCOM 6.3.0.2831. Does ASCOM actually play a role in platesolving?
Edit: just to be clear, the TSX ASCOM driver settings are all correct, so nothing has changed there.
mine seems to be related to ascom not passing SGP the right co-ords so the plate solve just spirals away looking for a solution it never finds
manual solves work fine - system generated fail
I’m at a complete loss now. My problem seems largely confined to one target - NGC 4236, at 69 north. It won’t solve after a slew to the target, but pretty much everywhere else will solve, at least via blindsolving. I’ve tried PS2, ASTAP, ANSVR local and astrometry.net. Nothing will solve it. BUT . . . if I open the platesolve frame and solve that, it solves just fine. I have to feed it a rotation angle and image scale for PS2 or ASTAP, since those both start out blank, but it will work. And I can also blindsolve in ANSVR or astrometry. net. What gives?
Also, SGP sometimes warns me that local ANSVR can’t be reached and won’t be used. Any idea what would cause that? It generally runs just fine.
Kevin
Kevin - I’m not seeing any of the issues on my MX with the latest V4 64-bit. Sounds like something got corrupted, or something changed.
In situations like these, I find myself going through the system, making sure I am using the latest versions of everything and clearing out dross. Check the mount first, level, polar aligned, NTP time, initial slew accuracy. I would then patiently go through the SGP settings to see if something changed along the way. I think I am still using the default values in ASTAP, it just works - but I have noticed it does not like short exposures (especially through NB filters).
Thanks Chris. I was using 1-second exposures with a lum filter for platesolving, but I’ve pushed that to 10 seconds. Maybe that will help.
In the meantime, can anyone solve this image?
Tha’s the platesolve image of the target that’s been giving me so much trouble. I can’t get it to solve in ASTAP or PS2, or by blindsolving with local or remote ANSVR. But it will solve when I upload it manually to astrometry.net:
https://nova.astrometry.net/user_images/4480604#annotated
which I can’t understand at all, since “remote ANSVR” = astrometry.net. (Right?)
Kevin
I have never got 1 second to work, unless I was imaging Pleaides !
Not a chance with that image. ASTAP (on a mac) would not solve it and I opened in PI and there are only 3 stars it could identify.
local astrometry is using Andy Galasso’s installer, does the same job as astrometry.net but the catalogs are stored on your computer.
I think the opportunity to solve an image incorrectly with 3 stars is high. So the online version may well need sanity checking too.
Yes-ish. They are similar but likely not the same. ANSVR has some configuration to it and this configuration can certainly be different from the online version of Astrometry.Net.
Also I tried that image and had the same luck with all the solvers … with the exception that PinPoint solved it after using the scale hit from your Astrometry.Net test.
I also tried additional indices with with ANSVR without any success.
Jared
Hi Kevin,
I agree with Buzz, increasing exposure duration should help you. The image you posted hardly has any bright stars, so there is little to work with. Default settings in ASTAP and PlateSovle2 didnt work on my computer. But by decreasing the “Detection Threshold” from 6 sigma to 4 sigma in PlateSolve2 I could solve it:
Mikael
Guys, thanks for patiently explaining this me. Insufficient stars certainly explains why the image can’t be solved. And that probably also explains why I’m only noticing this now, as I’m shooting spring galaxies in the starless void. I’ve just gotten lucky on this for years.
Is ten seconds enough? This is an ICX694 chip, so it’s pretty sensitive, but still not many photons: 22 x 28 arcmin FOV at 0.59 arcsecs/pixel with an 11" aperture.
Also, I tried MIkael’s suggestion to push PS2 to 4 sigma, and it solved. Is that setting likely to cause other problems, or is it okay to use that?
Kevin
Kevin - I usually use about 5 seconds, 2x2 binning. You do not usually need 1x1 binning for centering. Binning allows shorter exposures and quicker downloads etc. I have the same sensor - I typically use in 11MP mode but if you use 47MP mode (say, with shorter scopes that are not seeing limited) you may need to check your plate solve exposure assumptions first. (The ASCOM driver typically does not allow mode swaps while it is connected, direct drivers using the SDK in other apps manage it.)
Kevin,
I’m not sure it is a good idea to lower that threshold in general, you might pick up noise as stars, or strong nebulosity. It was more a means to show the problem is the low number of stars in the image, and that it is in principle solvable.
Do like Buzz suggests, try to increase exposure time and use 2x2 binning. In my setup I use 2x2 binning at 3 seconds (native 0.9"/pixel with a Atik 460ex), and it never fails to solve (permanent setup).
Mikael
Thanks Mikael and Buzz. I already shoot platesolves at 2x2, and I’ll try five seconds for exposure time. And I’ll switch back to 6 sigma.
Kevin
Edit: Buzz, re your comment about swapping modes through the ASCOM driver: I shoot lights at 1x1, but I set SGP to shoot platesolves at 2x2. Is there any problem with that?
Kevin - the IMX294 is unusual as it has two operating modes, 11MP and 47MP, both of which can also be binned. Unless the camera is losing you resolution, stick to the 11MP mode. In the ASCOM driver, you have to disconnect in S/W before you can change mode. As a rule of thumb, if 3.3x pixel scale is half the seeing, or optical resolution, then smaller pixels or less binning will be useful.
Ah - I wasn’t paying close enough attention. I actually have the ICX694 CCD sensor. I’ve heard about the two modes on the IMX294, but don’t have that one.