SharpCap 3.1.4477 Blind Plate Solve bug

[admin]

Using AstroTortilla, I can get your 'almost black' image to solve with --sigma 10, but not with --sigma 20 or above. Essentially the --sigma limits the detection of stars to those above that brightness, which is useful in a noisy field, but causing issues here. A settings page is going the be the right answer I think!

cheers,

Robin

[oopfan]

Robin,

I was thinking that my requirements are one-off when compared to 99% of your users. Nearly everyone, I would imagine, has a Go-To mount with ASCOM drivers up the wazoo. I'd rather spend $1000's on other things.

What I am getting at is this. I already have experience writing IronPython (see attachment). I know how to capture an image, and now I have a pretty good idea how to plate-solve that image. What I'd really like to do is find an automation interface for C2A so that I can center the screen on the image's coordinates. I don't think that it should be too hard. I can easily add a new groupbox to my IronPython application window.

Thank you.

[admin]

New plate solving options in the latest 3.1 build I have just uploaded (you will need to download manually for now - will go auto-update in a day or so). Hopefully will sort out your issue.

cheers,

Robin

[oopfan]

Thank you, Robin.

A sigma of 5 yielded 47 sources that resulted in success.

I did a timing test. I did this on my desktop PC, a dual-core Celeron with 8GB of RAM, which works very well for me for software development, stacking, and image processing -- certainly not high-end but I am happy with it. My laptop computer has 4GB of RAM with a slow AMD processor. There is a big difference in speed between the two machines.

After a cold boot, the first plate solve took 6 minutes. Subsequent plate solves of the same image took about 45 seconds. I attribute that to the Windows O/S caching the index files. I can almost guarantee you that the 45 seconds will turn into 2 minutes on my laptop.

Then I experimented with giving the plate solver the J2000 coordinates of the DSO that I am targeting using the arguments --ra and --dec, and for --radius I plugged in 5 degrees which is overkill. Here are the results:

After a cold boot, the first plate solve took 53 seconds. Subsequent plate solves of the same image took about 7 seconds. You can see that this a phenomenal speed increase, plus it mimics the way I will use the plate solver with my Setting Circles.

I know that my requirements are not typical but if you could find a way to squeeze it in I would greatly appreciate it. I can think of just one way of doing it and that is to pop up a dialog box when you choose Tools -> Plate Solve. Have inputs for ra, dec, and radius. solve-field will accept this for input:

--ra 19:59:35 --dec 22:43:11 --radius 5

I would just accept text for each of the three fields with no validation. The fields would be initially empty when SharpCap starts. If the user leaves the arguments empty then don't include them in the command line to solve-field. If the fields are set by the user it would be nice to remember them on subsequent plate solves. No need to save them when the application exits.

Thank you.

[oopfan]

Actually there is another way of getting those extra arguments without the need for a new dialog. Just add them to the Plate Solve tab that you recently added to File | Settings. In the course of a night I go to three DSO's, tops. For each DSO I will plate solve four or five times. So it is no great hardship for me to update the arguments that way.

[admin]

Can you use the other option I added to the plate solve page?

* Turn off the goto after sync in the settings
* Connect SharpCap to the simulated ASCOM mount
* Adjust the mount to roughly your telescope pointing position
* Press the GPS plate solve button on the mount controls

That will capture the frame and use the limited area approach for fast solving (with 15 degrees) and once the solve is complete it will sync the simulated mount to the solve position only, so you will see the solution clearly on the mount readout.

cheers,

Robin

[oopfan]

Thanks, I will give that a try. Will have reply by the end of the day.

[oopfan]

Robin,

I am glad that I persevered. An hour ago I was ready to give a not-so-glowing assessment but I finally got it working to my satisfaction with the only exception that I cannot turn on "tracking" AND plate solve -- I get an error from SharpCap saying something to the effect that a function named SetAltAz failed due to tracking. So in order to plate solve I have to turn off tracking and then turn it back on quickly after plate solving finishes. If I don't do that then the reticle that C2A paints showing the telescope pointing direction begins drifting away rather quickly.

The following three images tell my story. First off, let me say that my kit is rather unusual in that it is a 50 year old German Equatorial with good Setting Circles but no Go-To capability. I routinely locate faint DSO's with my Setting Circles, and depending on how accurately I calibrate them I can usually get the DSO in the frame the first time, but sometimes I make a mistake and I can be a couple degrees off. For plate solving I have been using nova.astrometry.net if I have an internet connection, and All Sky Plate Solver (ASPS) if not. I prefer nova.astrometry.net because the star charts are better albeit small. ASPS has rather crummy charts.

The first image is the star field in and around M27 which is in frame but invisible since the exposure is just 1 second. Plate solving revealed that the nebula was close to the center but not exactly. At the telescope what I would do next is adjust the mount's slow motion controls and then do another plate solve. The red-colored reticle I drew with Microsoft Paint in order to show the center of the frame.

The second image is a screenshot from KStars. The thing I like about KStars is that I can tell it the dimensions of my camera's sensor and it will draw the box that you see. The coordinates of the center of the box I got from doing a blind plate solve using SharpCap. It is important to note that the Blind Plate Solve reports J2000 coordinates, so I made sure that was the epoch I used with KStars when I entered those coordinates to draw the box. (The name of the image file is a little misleading -- KStars was NOT connected to ASCOM.)

The third image is a screenshot from C2A which was connected to the ASCOM Telescope Simulator V2, as was SharpCap. There is a lot of information but the legend will indicate where the center of the frame is as calculated by SharpCap's "Plate Solve and Sync" button in the Scope Controls section.

If you compare these three images you will see that they all agree within an acceptable degree (at least to me and my needs.) In the U.S. we say that this is "good enough for government work." That's an old saying from the military.

The center of frame on C2A is just slightly off but that may be attributable to a small amount of drift before I was able to turn tracking back on.

Also know that SharpCap is communicating using JNOW coordinates (apparently). My first go at this yielded a center of frame that was significantly off. After a little debugging I noticed that SharpCap is precessing the J2000 coordinates from the Astrometry.net Plate Solver to JNOW coordinates, and then sending those through ASCOM. I discovered a telescope option that allowed me to switch from J2000 to JNOW. It is much better now.

So in conclusion it would be really neat if I could plate solve while tracking is turned on.

Thanks Robin.

[admin]

Hi,

a couple of quick answers for you

1) Check the configuration of your simulated mount - SharpCap asks the mount what type it is before trying to sync and from the sound of it yours must be reporting as an Alt/Az mount for it to be calling SyncToAltAz rather than the more normal SyncToCoordinates which should be ok with tracking turned on.

2) SharpCap performs the conversion from J2000 to JNOW if the mount reports its equatorial system is EquatorialCoordinateType.equLocalTopocentric - ie the ASCOM mount is saying that it works in JNOW co-ordinates. On some ASCOM mounts you can control this option, on others it is fixed. As long as the mount reports correctly then SharpCap should do the right thing.

Good to hear that you are pretty close to getting it all working.

cheers,

Robin

PS. I don't seem to have 'Telescope Simulator V2' on my ASCOM install, but I do have 'Simulator' and 'Telescope Simulator for .NET' along with 'EQMOD Ascom Simulator' from EQASCOM.

[oopfan]

Robin,

I'm sorry I am using 'Telescope Simulator for .NET'. I was confused by the ASCOM window -- it says 'Telescope Simulator' in the title bar and 'V2' in the upper-left hand corner next to the ASCOM logo.

Regarding the interface, I had 'German Equatorial' checked. I changed it to 'Equatorial' but the sync still failed when tracking was on. Then I changed 'Equatorial System' from 'Local' to 'J2000', and it still failed. And then I noticed all of the 'Interface Capabilities' in the setup screen/options. All were checked including four Alt/Az methods. I unchecked all four and now it works! The synced reticle on C2A is dead-on now that no precession is applied.

This is perfect. Once the index files are cached by the O/S, plate solving is VERY FAST -- faster than nova.astrometry.net and ASPS!

Thanks very much.
Brian

PS. I observed something that you might not have caught while debugging it -- when the 'syncToAltAz' method fails SharpCap crashes.