Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Clear night, but no plate solving.

  • Please log in to reply
33 replies to this topic

#1 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 10:05 AM

Hey folks, just want to share last night's experience with you. Calibration subs are currently rolling and I don't have much else to do smile.gif

 

Last night I tried out my new .74x field flattener/reducer, taking my 480mm F/6 refractor to 355mm at F4.5. I've been wanting to shoot Markarian's Chain for years now, and though I didn't have high expectations for last night, I was at least hoping to get it framed up in a single shot and have some practice time to make some precise adjustments. Unfortunately, it wasn't to be. 

 

Generally, most of the "This could go wrongs" went right...even surprisingly right for a new equipment setup. Got the guide cam and main camera parfocal, the Rigel autofocus made excellent V-curves, PHD2 calibrated without any hiccups. 

 

But alas, I was unable to accurately acquire a target  - SGP plate solving failed after every single attempt. I'm not sure what I did wrong, but I must be missing something. The images that the plate solver took looked fine, and it looked like all the stars selected were indeed stars. I made sure that I had the correct new image scale in the equipment profile, saved and loaded. I'm kind of at a loss, because it's never failed before. Even blind solving failed. 

 

Capture.JPG

 

Capture2.JPG

 

If anything looks glaringly wrong to you, please give me the heads up. 

 

 

Around 1am I gave up messing with it. I used the hand controlled to get me in the ballpark and started the sequence, and everything went fine once I turned off plate solving. 

 

I'm downloading presently, but I grabbed a single image to share from the get-go:

 

Capture4.JPG

 

So the "minor" tilt just using the regular field flattener at F/6 has become much more obvious. It's bad enough that I actually need to do something about it smile.gif Star shapes actually don't look all that bad though. I'm currently at 56.5mm and might get a slight improvement with a little more adjustment. 

 

I suppose the project for the foreseeable future (doesn't look like we'll have any breaks in the clouds for at least a week) is to try to locate the source of the tilt (being that everything is a threaded connection except the OAG, I'm betting it's the OAG), and try to figure out what went wrong with Plate Solving. And of course, those miniscule diffraction spikes continue to annoy me...but I've got some very thin adhesive felt that I'm going to use to flock all internal surfaces south of the drawtube that will hopefully fix that problem.  

 

If you have any ideas about any of my issues (but let's not get too personal smile.gif), I'd be glad to hear them! 


Edited by zakry3323, 26 March 2020 - 10:10 AM.


#2 OldManSky

OldManSky

    Soyuz

  • *****
  • Posts: 3,612
  • Joined: 03 Jan 2019
  • Loc: Valley Center, CA USA

Posted 26 March 2020 - 10:12 AM

I'm used to NINA, not SGP, but...

Were the settings for focal length correct in the Telescope tab?

Were you really at 0 rotation?

Just some things to check...


  • zakry3323 likes this

#3 ChrisWhite

ChrisWhite

    Fly Me to the Moon

  • *****
  • Posts: 5,618
  • Joined: 28 Feb 2015
  • Loc: Colchester, VT

Posted 26 March 2020 - 10:17 AM

I've had serious problems with PS2 and Voyager lately. No idea why. Like you say, all stars selected look good.... yadda yadda yadda.
  • zakry3323 likes this

#4 einarin

einarin

    Vanguard

  • *****
  • Posts: 2,244
  • Joined: 23 Dec 2016

Posted 26 March 2020 - 10:29 AM

So how many stars did it find ?

Maybe you were too far from your plate solve target.

What do you have as a blind solver ?

If all else fails then remote Astrometry.NET works (but takes time).


  • zakry3323 likes this

#5 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 10:30 AM

I'm used to NINA, not SGP, but...

Were the settings for focal length correct in the Telescope tab?

Were you really at 0 rotation?

Just some things to check...

Thanks buddy smile.gif

 

Fortunately, I still have all my settings from last night right up in front of me on the VPN because I'm still shooting calibration files. 

 

Correct fl in the Telescope tab: 
Capture5.JPG

 

For rotation, I don't have a auto-rotator, and for the sake of maintaining good balance, I didn't even want to do any manual rotating last night. For the Frame and Mosaic Wizard, I leave the "Auto Rotate/Validate Rotation" box unchecked, as is my typical habit. 

Capture8.JPG


  • OldManSky likes this

#6 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 10:32 AM

I've had serious problems with PS2 and Voyager lately. No idea why. Like you say, all stars selected look good.... yadda yadda yadda.

Weirdness for sure. 



#7 OldManSky

OldManSky

    Soyuz

  • *****
  • Posts: 3,612
  • Joined: 03 Jan 2019
  • Loc: Valley Center, CA USA

Posted 26 March 2020 - 10:37 AM

Well, so much for the obvious suspects...

The only failures I’ve had are when I’m shooting something with a bunch of bright stars, like M45, and my default ps exposure time over-exposes. Could the faster focal ratio with the new reducer be an issue?


  • zakry3323 likes this

#8 Peregrinatum

Peregrinatum

    Apollo

  • *****
  • Posts: 1,061
  • Joined: 27 Dec 2018
  • Loc: South Central Valley, Ca

Posted 26 March 2020 - 11:04 AM

Looks like you have the likely culprits already sorted out:  FL, image scale.

 

What I have found is that PS2 needs a good idea where it is in the sky to get a plate solve, seems like you need to be within a few degrees of the actual location for PS2 to be happy... a blind solve and sync prior to using PS2 can tell it where it is currently pointing good enough to get plate solving...

 

I always clear out the mounts pointing model, set it to dialogue mode in eqmod, then blind solve and sync... when I do this first PS2 works flawlessly for me.

 

If you do use or setup the blind solver (ansvr) made sure you have the correct index files (if the FOV for the index files are too large it can't plate solve).


Edited by Peregrinatum, 26 March 2020 - 11:05 AM.

  • zakry3323 likes this

#9 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 11:38 AM

Well, so much for the obvious suspects...

The only failures I’ve had are when I’m shooting something with a bunch of bright stars, like M45, and my default ps exposure time over-exposes. Could the faster focal ratio with the new reducer be an issue?

That's a good point, and something that I haven't checked. Next time out I'll reduce exposure time and see if it helps!



#10 OhmEye

OhmEye

    Viking 1

  • -----
  • Posts: 596
  • Joined: 15 Sep 2019
  • Loc: Western NY Southern Tier

Posted 26 March 2020 - 11:43 AM

I've had serious problems with PS2 and Voyager lately. No idea why. Like you say, all stars selected look good.... yadda yadda yadda.

That's interesting. I know this doesn't help since the OP is using SGP, but I recently tried to evaluate Voyager and decided to give up after running into several issues that flat out prevented me from actually using it. One of those issues was PS2 failing to solve via Voyager. I could run PS2 manually on the same image and it solved fine, but when Voyager used PS2 it failed. I even tried using ASTAP, it's PS2 compatible for commands and that was also weird. ASTAP solved fine manually from Voyager's On the Fly tab for an image, but always failed when using automation or precise goto.

 

I don't know if SGP saves the images anywhere that it uses for platesolving, but if it does it's worth running PS2 manually outside of SGP using the same images to see if it's really just PS2 failing, or something in the parameters SGP is passing to PS2 when it runs it. It's also well worth trying ASTAP.


  • sparkyht, zakry3323 and OldManSky like this

#11 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 11:45 AM

So how many stars did it find ?

Maybe you were too far from your plate solve target.

What do you have as a blind solver ?

If all else fails then remote Astrometry.NET works (but takes time).

I don't have that info anymore, but quite a lot of stars. At least 50, probably more like a hundred. 

I usually slew to the area where my target is just to be in the ballpark and help plate-solving to run faster. Though I have blind-solved and sync/slewed from that point to plate solve for my target previously, depending upon the situation, no plate solving was working last night, including failing-over to Astrometry.net.  

 

Thanks for trying to help me figure this out! 



#12 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 11:48 AM

Looks like you have the likely culprits already sorted out:  FL, image scale.

 

What I have found is that PS2 needs a good idea where it is in the sky to get a plate solve, seems like you need to be within a few degrees of the actual location for PS2 to be happy... a blind solve and sync prior to using PS2 can tell it where it is currently pointing good enough to get plate solving...

 

I always clear out the mounts pointing model, set it to dialogue mode in eqmod, then blind solve and sync... when I do this first PS2 works flawlessly for me.

 

If you do use or setup the blind solver (ansvr) made sure you have the correct index files (if the FOV for the index files are too large it can't plate solve).

This is typically what I do too. Usually my polar-aligned CEM60 can slew from its zero position and be within a few degrees of any target I throw at it. I would think that with an even wider-than-typical FOV with the reducer that it would be even easier to solve when off by a little bit. 



#13 Alex McConahay

Alex McConahay

    Cosmos

  • *****
  • Posts: 8,936
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 26 March 2020 - 11:49 AM

Check out the FITS header on the file.....Does it show the proper coordinates for the target?

 

Did you enter the image scale for a 1x1 (unbinned) or for whatever binning you were using?

 

Does PS2 require a specific size (image scale) catalog download? (I forget)  

 

Alex


  • Madratter and zakry3323 like this

#14 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 01:36 PM

Check out the FITS header on the file.....Does it show the proper coordinates for the target?

 

Did you enter the image scale for a 1x1 (unbinned) or for whatever binning you were using?

 

Does PS2 require a specific size (image scale) catalog download? (I forget)  

 

Alex

The FITS header info has the same coordinates as the actual target I was going after last night. I also popped it into Astrometry to see it with my own eyeballs, and it matches. 
 

Ok, binning settings. Under the Equipment Profile, I have the unbinned image scale set correctly for the FL and Camera (2.2" /pixel). However, I was attempting to plate solve with 2x2 binning, which usually helps when I'm shooting narrowband. That would take my image scale to 4.4" /pixel, but I'm not aware of a means to input this into SGP- it's not an option under Plate Solving. While trying to work through it last night, I dropped binning back down to 1x1 to see if that would get it to behave, but still I had no luck. 

Hmm. I'll have to look to see if the issue is with the catalogs. I could imagine that over 4" might not be built in to the catalogues that I'm using, but it shouldn't have any trouble at 2.2ish"/pixel, I've imaged around that scale before and haven't had any problems.

Thanks for the insights Alex! 


Edited by zakry3323, 26 March 2020 - 01:37 PM.


#15 Alex McConahay

Alex McConahay

    Cosmos

  • *****
  • Posts: 8,936
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 26 March 2020 - 01:54 PM

>>>>>but I'm not aware of a means to input this into SGP

 

Specify the plate scale at 1x1. SGP will recompute for itself when you change it. You need do nothing when changing binning. You do not specify anything except what you already have for 1x1 (as cited in the screenshot of the camera profile in your original post). 

 

If the only change was the reducer, you need to change the plate scale (because your effective focal length has changed, and thus your plate scale). However, in your first post, I think you said you had made those adjustments. (Did you make them correctly?) 

 

However, once you know your plate scale at 1x1 and enter that in SGP, you need not change it again at different binning levels. 

 

The comment about the different plate scale catalogs: I have loaded several iterations of Plate Solvers into my computer, and get confused. Some require catalogs set to a specific scale, and some don't. I do not remember which is which. 

 

The first problem one has with plate solving is making sure there are enough stars. Your image seems to qualify there. The second is hint (starting position) but you say you have that right. The third is plate scale. And it looks like you have thought that out. The second and third problems are relatively immaterial for a blind solve. So, that should be working. In other words......sorry, I'm no help. 

 

Is SGP/PS2 solving other files you used to have in your computer? Is it just failing on files taken after the reducer?

 

Alex 


  • zakry3323 likes this

#16 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 03:57 PM

>>>>>but I'm not aware of a means to input this into SGP

 

Specify the plate scale at 1x1. SGP will recompute for itself when you change it. You need do nothing when changing binning. You do not specify anything except what you already have for 1x1 (as cited in the screenshot of the camera profile in your original post). 

 

If the only change was the reducer, you need to change the plate scale (because your effective focal length has changed, and thus your plate scale). However, in your first post, I think you said you had made those adjustments. (Did you make them correctly?) 

 

However, once you know your plate scale at 1x1 and enter that in SGP, you need not change it again at different binning levels. 

 

The comment about the different plate scale catalogs: I have loaded several iterations of Plate Solvers into my computer, and get confused. Some require catalogs set to a specific scale, and some don't. I do not remember which is which. 

 

The first problem one has with plate solving is making sure there are enough stars. Your image seems to qualify there. The second is hint (starting position) but you say you have that right. The third is plate scale. And it looks like you have thought that out. The second and third problems are relatively immaterial for a blind solve. So, that should be working. In other words......sorry, I'm no help. 

 

Is SGP/PS2 solving other files you used to have in your computer? Is it just failing on files taken after the reducer?

 

Alex 

- Check

- Check

- Will definitely check 
- Don't be ridiculous, of course you're helping!

- Well, I just stuck with the reducer last night. Last week I finished up this year's M42 integration just using the Field Flattener and everything worked fine- and I solved the image to come back to the exact position four nights in a row. So it may just be failing on files taken with the reducer- or just as likely I have something set up incorrectly since switching imaging scales. I'm glad that I didn't seem to make any glaringly bad mistakes, and that there's still plenty of time for Markarian's Chain :)

 

Today I popped on a Gerd Neumann TCU to try to correct that tilt, but it's just a little too thick (4mm). I suppose I'll have to look into thinner options. One thing at a time :)  



#17 Alex McConahay

Alex McConahay

    Cosmos

  • *****
  • Posts: 8,936
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 26 March 2020 - 05:41 PM

So, it works fine without the reducer, but fails with the reducer, even though you have changed the image scale to match the change caused by the reducer?

 

Can you solve one of your images in Pixinsight? Direct with PS2, or Astap, or even a blind solve in some web based system. That is, take SGP completely out of the loop.  

 

Alex


  • zakry3323 likes this

#18 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 26 March 2020 - 07:32 PM

So, it works fine without the reducer, but fails with the reducer, even though you have changed the image scale to match the change caused by the reducer?

 

Can you solve one of your images in Pixinsight? Direct with PS2, or Astap, or even a blind solve in some web based system. That is, take SGP completely out of the loop.  

 

Alex

It did work fine without the reducer, but it'll take a clear night and swapping some connections on the image train to know if it will again :)

PixInsight can solve it just fine once a sub is stretched:

Resolution ............... 2.228 arcsec/px

Rotation ................. 103.674 deg
Observation start time ... 2020-03-26 06:39:28 UTC
Observation end time ..... 2020-03-26 06:41:28 UTC
Geodetic coordinates .....  80 00 00 E  40 00 00 N
Focal distance ........... 351.79 mm
Pixel size ............... 3.80 um
Field of view ............ 2d 52' 53.9" x 2d 10' 42.8"
Image center ............. RA: 12 30 29.211  Dec: +25 33 26.90
Image bounds:
   top-left .............. RA: 12 33 37.555  Dec: +23 53 54.45
   top-right ............. RA: 12 36 44.911  Dec: +26 41 27.23
   bottom-left ........... RA: 12 24 20.602  Dec: +24 24 27.77
   bottom-right .......... RA: 12 27 15.582  Dec: +27 12 43.86



#19 Noobulosity

Noobulosity

    Viking 1

  • *****
  • Posts: 709
  • Joined: 10 Jan 2018
  • Loc: Loveland, CO

Posted 26 March 2020 - 07:34 PM

I would second (third? fourth? eleventh?) checking the focal length with the reducer.  I had made the assumption with my scope that the factory-specified focal length was accurate, when in fact it was not.  MY WO Zenithstar 103 with the 0.8x reducer at f/5.5 should end up at 566.5mm focal length.  But I plugged an image into Astrometry.net and it told me I was really around 579mm.  I struggled with plate-solving until I figured that out.  As soon as I realized I was 12mm off in my focal length, things started working properly.

 

I would suggest taking one of your images with the reducer and plugging it into Astrometry.net.  It should tell you your FOV, and you can extrapolate your focal length from there.  Take this example of a solved image from Astrometry.net:

 

49702096608_3eebf46b34_b.jpg

 

To calculate focal length, we can solve for it by plugging known information into the following equation:

 

Pixel scale (arcsec/pixel) = (Pixel Size in µm / Focal Length in mm) * 206.265

 

In my solved image, pixel scale is 1.46 arcsec/px.  And the pixel size for my Canon 7D Mark II camera is about 4.1 microns (µm).  Therefore, working backwards to the TRUE focal length of my scope...

 

1.46 arcsec/px = (4.1µm / FL) *206.265  ==> rework the math to calculate FL ==>  FL = pixel size * 206.265 / pixel scale  =  4.1µm * 206.265 / 1.46 arcsec/px = 579.22mm

 

So, I would try this and see if it matches the numbers you've entered into your plate-solver.  If it's off by a significant amount, it may not solve.  Some solvers may be more-sensitive than others.  I had issues with PlateSolve2 being very finicky about the inputs.  I now use ASTAP from within N.I.N.A. and it's much easier and faster than PS2, at least for me.


  • zakry3323 and OldManSky like this

#20 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 27 March 2020 - 05:18 PM

I would suggest taking one of your images with the reducer and plugging it into Astrometry.net.  It should tell you your FOV, and you can extrapolate your focal length from there.  Take this example of a solved image from Astrometry.net:

 

 

Well, this is interesting.  PixInsight solved the same stretched photo and measured the image scale to be 2.22"/pixel. This is just a sample sub with an STF stretch, no calibration or drizzling. Guess I need to work backwards and do some maths this evening when the kiddo is in bed.

 

astrosolve.JPG



#21 Noobulosity

Noobulosity

    Viking 1

  • *****
  • Posts: 709
  • Joined: 10 Jan 2018
  • Loc: Loveland, CO

Posted 27 March 2020 - 05:34 PM

Make sure you upload the unstretched and unscaled image.  If you reduce the image size down, it'll affect how it solves.  (i.e. if you cut the resolution down)  If that's the full-size image, the scale is very different than expected.


Edited by Noobulosity, 27 March 2020 - 05:35 PM.

  • zakry3323 likes this

#22 zakry3323

zakry3323

    Apollo

  • *****
  • topic starter
  • Posts: 1,453
  • Joined: 11 Apr 2016
  • Loc: Pittsburgh

Posted 27 March 2020 - 08:22 PM

Ok, here we go. 

Thanks Noobuluous, Unstretched, Astrometry solved my image, which agrees with PixInsight's platesolve (Thank goodness I'm not losing my mind, I just didn't export the previous image properly!) 

notgreat.JPG

 

Last night I tried out my new .74x field flattener/reducer, taking my 480mm F/6 refractor to 355mm at F4.5. I've been wanting to shoot Markarian's Chain for years now, and though I didn't have high expectations for last night, I was at least hoping to get it framed up in a single shot and have some practice time to make some precise adjustments. Unfortunately, it wasn't to be. 

So, my image scale was set to 2.18"/pixel and FL set to 355mm. Actual image scale is 2.23"/pixel and FL is 347mm. So my numbers were off by 8mm due to "lazy math" (480mm * .74).

 

I'll give it another go...there's a possibility that the weather will improve after this weekend, and I'll see if inputting the new values have the desired effect. 

 

I have to wonder though....what is the "fudge factor"? I've only done "lazy math" for obtaining the focal length and image scale for my other OTAs and their respective reducers and never had an issue. But, they're at longer focal lengths. Maybe exacting accuracy is more important at shorter focal lengths?  


Edited by zakry3323, 27 March 2020 - 08:31 PM.

  • OldManSky likes this

#23 Alex McConahay

Alex McConahay

    Cosmos

  • *****
  • Posts: 8,936
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 27 March 2020 - 09:15 PM

2.18 v 2.23 would not have bothered anything.

Besides, you are not having a plate solve problem, you are having a centering problem. It is in ascom and the mount, not the platesolve.

Alex

#24 Noobulosity

Noobulosity

    Viking 1

  • *****
  • Posts: 709
  • Joined: 10 Jan 2018
  • Loc: Loveland, CO

Posted 28 March 2020 - 09:26 AM

2.18 v 2.23 would not have bothered anything.

Besides, you are not having a plate solve problem, you are having a centering problem. It is in ascom and the mount, not the platesolve.

Alex


He said his images won't plate-solve. How is that a mount problem? That's absolutely a plate-solving problem.

#25 Alex McConahay

Alex McConahay

    Cosmos

  • *****
  • Posts: 8,936
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 28 March 2020 - 02:38 PM

Yeah, I goofed. I got this confused with another thread going on about a guy who can get a solve, but the mount does not move where it should. '

 

Alex




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics