Confused

[dwc]

Last week I managed a perfectly average set of images of M42. I used my C9.25/NEQ6, Canon 1100D with APT, guided by ASI120MC/mini guidescope with PHD2 using the onboard capability (ASI direct connected to guide port). Everything worked fine, from the GOTO finding the target, to PHD2 guiding on a random star.

 

Tonight I decided to try to get platesolving and GOTO to work in APT, which requires connecting APT to the mount, and including connecting up Stellarium as well. I’d previously tried this using the various simulators available, and had managed to follow a couple of YouTube tutorials that demonstrated using the same simulators. 

 

But, in short, I just couldn’t get any of the programs to work properly together, or to give sensible results. I couldn’t even get PHD2 to successfully find a star to guide.
 

I’m sure I’ve just missed something basic that’s causing the discrepancies, but I can’t figure out what.

 

I was using the ASCOM Telescope Hub, and connecting APT, PHD2,  and Stellarium.

All the components seemed to think they were pointing at different locations.

 

In the end I went back to just trying to get NEQ6 and EQASCOM to agree on where they were pointing, and couldn’t make sense of the discrepancy. I checked the Lat/Long in the handset and in EQASCOM, they are the same.

 

Here’s what I see. I did a GOTO M44 using the handset, verified that’s what I could see through the eyepiece, checked the Current Position, then put the handset into Direct Mode and connected EQASCOM.

 

The handset is pointing at RA 08h 41m

 

EQASCOM thinks it is pointing at RA 08h 51m. They agree on DEC.

 

Stellarium shows the same as EQASCOM (obviously) and although I didn’t capture it, pointing left of M44 by (I guess) the 10m discrepancy.

 

What am I missing here? I assumed that EQASCOM would take the information directly from the mount.

[Dmack1]

Hi, its frustrating to set up but once it all comes together it works really well every time.

 

I use APT, Stellarium PHD2 all driving a NEQ6 so same set up as you. Heres my thoughts on how I do it;

 

1. I dont drive it through the ascom telescope hub - In both APT and PHD2 I connect through the EQMOD ASCOM HEQ5 option. Control click on the "connect scope" button to bring up this

Its the same in PHD2

2. Make sure you have your location dialed into APT/Setting/location - this could be your main problem.

3. Dont connect stellarium to the scope, there is no need - connect it to APT in the APT/Settings/Planetarium tab. Look at the APT user guide to help with this. You can then locate something in Stellarium(click on say M42 in Stellarium), then use shift click on "Objects" to populate the GoTo coordinates with the current stellarium co-ordinates. (This shift click also works within pointcraft to poulate co-ords for near solving)

4. Dont move the scope other than from APT, so Polar align, put scope to home position (this is really important otherwise the scope has no idea where it is when turned on) Connect scope as above, unpark, populate a goto co-ord from stellarium (or just from Objects if you want) hit goto, use pointcraft to platesolve, SYNC scope from within pointcraft. You are then aligned and can goto anywhere from within stellarium. its best to do your first platesolve reasonably close to you target but the more you do in a given session the more accurate the pointing will be.

5. This all requires that you platsolving is working  - you can set that up and check it out during daytime with already captured images. I find that at the long FL of my SCT with my DSLR platesolving can be tricky. If you have problems with that let me know and i can share my thoughts on that too.

6. On PHD2 not finding a guidestar after working last week,the only thing coming to mind is your focus has changed on the guide scope/OAG camera.

 

HTH and apologies if I'm missing the issue and coming at this from the wrong level.

 

David.

[dwc]

1 hour ago, Dmack1 said:

Hi, its frustrating to set up but once it all comes together it works really well every time.

David, thanks very much for your responses, much food for thought! It was all so easy using the simulators!

 

1. I did originally start to do that, but read somewhere it wasn’t a good idea to drive directly from 2 programs. I will try as you suggest.

 

2. Yes, I do suspect something similar, I’m shortly going to go through it all again and check. One observation is that the Synscan and the software packages use a different granularity for specifying location; Synscan is “ddd hh” whereas all the software packages use “ddd hh mm.s”. Is this alone enough discrepancy, e.g “000 44 W” verses “000 44 38.4 W”?

 

3. Noted, I did configure Stellarium in APT but haven’t used it much (waiting for platesolving). Does this work both ways, it’s useful seeing the scope location in Stellarium? I’ll try this anyway.

 

4. OK, so this is something I posted about earlier:

https://www.backyardastro.org/topic/2114-starting-position
I use Custom Park at the end of each session as I am pier mounted, and I assume I can just start from parked position next session. I will just use the method you suggest once I have platesolving working. Comments?

 

5. Yes indeed. I have the 3 platesolving packages installed, and have managed to get all to solve an image (with varying degrees of difficulty). I found it easier loading up an image from within each package, had more difficulties trying to get APT and NINA to pass images to them. Next on my list is to go through the setup process again in case I’ve got some residual settings fro using the simulators.

 

6. Yes, worried about that as well. Going to have to spend some time looking at that as well.

 

Its more frustrating because there is little clear sky at the moment, so it all seems a waste to spend it working on software. There may be an hour or so on Thursday, not sure after that, risk is I’ll forget everything before I can try it. I’ll test what I can in the daytime.

 

Thanks again for the long response, very helpful.

 

 

 

 

[Dmack1]

You are very welcome Dave! @dwc

 

Taking your points;

1. I think EQMOD is designed to allow that and I've had no issues. So far!. When I'm driving my LX200, because there is no EQMOD, I have to use the Ascom Device hub and it works fine.

2. I cant see that causing a problem. One point though, I dont use the Synscan handset at all, its not plugged in. I'm not even that sure where it is. So I dont know if having the handset plugged in could be causing the mount to get confused?

3. Yes it works both ways. After you have platesolved, within pointcraft hit show and it will then throw your FOV marker around the solved co-ordinates - including rotation. Its really useful for framing a shot. Or planning a shot during the day then saving that planned shot in Objects to go straight to once you are set up and aligned/focused. You first need to have your FOV worked out in stellarium by entering your sensor and scope in the settings tab (I think its explained in either the APT manual or the Stellarium manual but its quite easy).

4. Beyond my experience I'm afraid - I'm a "lug it out every night" guy!. I would think that if the mount is set up to know the parked position when it is switched on then that should work. But I really dont know If/how you could do that.

5. I have found it nearly impossible to get ASTAP to solve a long FL (1960mm) from within APT. If you take the CR2 straight into ASTAP direct it solves flawlessly. But APT sends ASTAP a demosaiced/debayered JPG which seems to completely destroy the image, meaning that ASTAP just fails. See from post #4 here where Han (the developer of ASTAP) gives me some help - but ultimately fails to resolve. https://www.cloudynights.com/topic/811942-astap-question/

 

PS2 also fails but I dont know why.

 

ASPS will solve from within APT BUT, the way I get it to to that consistently is;  In the tools tab, object calculator set it to CCD/CMOS camera - NOT the 1100D or in my case 700D. Put in the FL of your scope and the pixel and sensor dimensions for you camera. Hit recalc EVERY time immediately before solving. I dont know why this makes a difference but it works for me. (NOTE all of this is only with Long FL and DSLR - with my ASI2600 on the SCT and all my other scopes with DSLR or ASI all the platesolvers work flawlessly within APT) 

 

I hear you about not wasting the few hours of clear sky with stuff like this. It breaks my heart when I go out on the first clear night in 6 weeks and something goes wrong. Because, I just know nothing is going to go right from that point on and I'd be as well clearing up and getting an early night.😄

 

I do hope this helps. Good luck.

 

David

[dwc]

Thanks again.

 

I just did some config checking of the software, I didn’t find anything major.

I also found the last image APT tried to pass to platesolving and tried to solve it manually. As you suggest, ASPS solved it and the other 2 didn’t. I will deconfigure the others in APT for now.

 

Something else I found, not sure if it’s an issue or not. I switched on the mount and moved it slightly with the handset. I could hear it tracking. Then I connected up APT via EQASCOM, it connected fine but it turned off tracking. I needed to click on the Sidereal button on EQASCOM to get it to star tracking again. Presumably doing a GOTO with APT would have turned it on again. I don’t know if this is expected or not. I’ll do some more reading.

I also checked the configuration of NINA so I can try that as well.

[Dmack1]

@dwc Whenever I connect the scope in APT it connects as "parked" you have to hit "unpark" in the Gear tab before it will start tracking - that could be what you are seeing.

Edited February 23, 2022 by Dmack1

[dwc]

I came across an interesting “how to” post on the APT Forums:

https://aptforum.com/phpbb/viewtopic.php?f=19&t=5101
 

In Part 3:

Quote

When EQMOD is started it ALWAYS assumes the mount is pointing at the celestial pole (NCP for those in the northern hemisphere and SCP in those the southern hemisphere).

… which bears out what you said originally.

 

”The more I learn the less I understand” 🤪

[dwc]

4 minutes ago, ApophisAstros said:

Question 1 . Have you installed the three platesolvers and in APT settings shown APT where they are?

Question 2. Have you then installed all three libraries for each platesolver?

Recommendation 1. dont use the handset use Eqmod , i think the handset rarely works properly with Eqascom.

Roger, thanks very much for the response.

 

Q1: yes, I have done that

Q2: yes, I think. I have successfully platesolved manually using each program, though not when called from APT, and only ASPS solved the image generated by APT. I have more testing to do.

Recommendation noted, I think it’s a bit of a trust thing for me at the moment, I trust the handset to do what I want, less so APT and EQASCOM. I will be trying to just use software, but I still need to connect via the handset as that’s the only cable I have.

[Dmack1]

32 minutes ago, dwc said:

I came across an interesting “how to” post on the APT Forums:

https://aptforum.com/phpbb/viewtopic.php?f=19&t=5101
 

In Part 3:

… which bears out what you said originally.

 

”The more I learn the less I understand” 🤪

that is interesting. the next para on there covers you though.

 

"However, there is one exception to this. That is when a PARK has been issued to the mount, before the EQMOD is stopped and the mount is turned off, either through the EQMOD Graphical User Interface (GUI) or from a 3rd party application (e.g. APT). When this is done, EQMOD stores the Parked position in it's .ini file and can retrieve that position when it restarts. Of course, it has to assume that the mount has not been moved from this position."

 

So if you shift click park, its going to park in its current location and then turn off everything EQ Mod will remember so when you start up again APT will also remember the position - I think!

Edited February 23, 2022 by Dmack1

[dwc]

@Dmack1 At the moment I shut down EQASCOM and park with the handset. Trust, again. I need it parked correctly in order to safely shut my sliding roof! I will try to park as described.

However, unpacking with the handset and then starting EQASCOM does seem to work, though per my original description, with caveats.

[dwc]

@Dmack1 @ApophisAstros I managed to grab an hour between rolling clouds and occasional gusts to try some of your suggestions, and whilst I’m not sure if I’m getting closer to have everything working, I am at least making progress in understanding how it should be working.

 

I did the basic date/time power on with the handset, and then brought up EQASCOM via APT. It gave status Not Parked as I think we agreed it should, as I had previously Parked using the handset. As I knew time would be limited, I disconnected and went back to the handset.

 

I did a GOTO on M44 which worked fine, and then brought up PHD2 using on board connection. I was able to loop, pick a star, calibrate, and track fine. I think the issue was, the way I positioned the camera meant the cables were fouling the back of the scope, preventing the camera from being fully inserted into the mini scope. I took a few short test images of M44.

 

I then shut down PHD2, connected EQASCOM via APT. It seemed to recognise the correct location, but I did have to turn tracking on. I changed the Pointcraft settings to only use ASPS, and tried to solve on M44. I had a couple of attempts, both timed out. At that point the clouds rolled in again so I stopped.

 

I then did a Park from APT, which didn’t give me any options and Parked to Home position. I didn’t really have time to set up the custom position in EQASCOM so rather than switch off the mount, I disconnected EQASCOM and went back to the handset. I was surprised, but pleased, to see that the handset still knew where it was pointing (Home) and that doing a Park to Custom put it into the right place.

 

So, some gains, better understanding, and a much happier end to the session. Tomorrow I will try to manually platesolve the test shots of M44 to see if I can work out what is going on.

 

Thanks both for your help.

[Dmack1]

Sounds like progress! I think that if you do shift (maybe ctrl) click on park in APT it will park to current location. So if you set a object in apt as your park position you could GOTO that, then shift click "park"   and that should remember next time you start.

 

On the solving, what exposure did you use. With my sct I find that it struggles with a full exposure  of a couple of minutes but 20 secs at iso 800 usually does it. Also, I find if I take an image with a very bright (Bloated in my case!) star in centre fov, it can fail. The other night I solved close to but just off capella  centred capella for focus, then it failed to solve. Moved off again and no issue.Just my experience and as they say ymmv!

[dwc]

5 minutes ago, Dmack1 said:

On the solving, what exposure did you use.

I think it was set for 5 seconds ISO800, will check tomorrow.

The image was very similar to the one from yesterday that I manually solved using ASPS earlier today.

[Dmack1]

Ok, so 5 seconds might just be a shade too short. Although with the beehive I'd have thought you'd have enough stars at that. It is a bit trial and error for your own system though. Another thing I find with my SCT is focus has to be pretty good otherwise it can fail.

 

If you wanted to share a couple of your raw files I can run them through my APT/ASPS - that way we will know if its your set-up of APT/ASPS or if its the image itself that needs tweaking.

[dwc]

Some preliminary findings.

The images are indeed 5 seconds ISO800.

APT passes a .jpg file to ASPS. It will not solve the .jpg.

I converted the .jpg to .fits using ASTAP.

ASPS solved the .fits file in about 20 seconds.

Neither ASTAP nor PS2 will solve the same file; ASTAP comes back very quickly with No Solution Found, PS2 loops forever.

I also converted a raw .CR2 file to .fits using ASTAP and got the same results. ASPS solved faster than it did the earlier file, the others won’t solve at all.

Edited February 24, 2022 by dwc
Hit send too soon

[paul]

1 hour ago, dwc said:

Some preliminary findings.

The images are indeed 5 seconds ISO800.

APT passes a .jpg file to ASPS. It will not solve the .jpg.

I converted the .jpg to .fits using ASTAP.

ASPS solved the .fits file in about 20 seconds.

Neither ASTAP nor PS2 will solve the same file; ASTAP comes back very quickly with No Solution Found, PS2 loops forever.

I also converted a raw .CR2 file to .fits using ASTAP and got the same results. ASPS solved faster than it did the earlier file, the others won’t solve at all.

If you haven't tried it yet, PS2 has its own user interface application (as does ASTAP) to process an image. You might get more feedback from those applications on what they don't like or have missing like the star database or image meta data (co-ordinates, fov/pixel resolution etc).

Edited February 24, 2022 by paul

[dwc]

@paul Thanks Paul. Sorry I didn’t make it clearer, but in my last reply I was using the 3 tools directly, not via APT. I haven’t tried to interpret their logs yet, nor tinkered with any settings.

 

What I have concluded so far is that ASPS will solve the images that APT takes if they are provided as FITS files, but not using the .jpg that APT passes.

[paul]

The trouble I find with these sorts of issues is you solve the problem once and everything is fine and then you forget how you got there😀.

13 minutes ago, dwc said:

@paul Thanks Paul. Sorry I didn’t make it clearer, but in my last reply I was using the 3 tools directly, not via APT. I haven’t tried to interpret their logs yet, nor tinkered with any settings.

 

What I have concluded so far is that ASPS will solve the images that APT takes if they are provided as FITS files, but not using the .jpg that APT passes.

Ok fine 🙂. Your results for APT with ASPS make some sense, ASPS will extract the meta data from the FITS image but for a JPEG APT would need to provide that data separately as command line parameters. 

 

 

Edited February 24, 2022 by paul

[Dmack1]

Hi Dave, this goes back to the thing I mentioned earlier.

This is my M1, 8"LX200, SW 0.85 FR (for FL around 1960mm), canon 700D

With Object calculator set as 700D it fails to solve in ASPS

Same Image - Change Object calculator to CCD/CMOS, Then hit "Recalc" (this is critical) it solves in ASPS in 20s

These are the same exact image (CR2) done sequentially in APT I believe its to do with the image APT sends to ASPS being different if you TELL it its a CCD/CMOS - even if its not!! It does not work with ASTAP

Edited February 24, 2022 by Dmack1
Corect M number

[dwc]

@Dmack1 Sorry, I hadn’t quite grasped that.

So I’ve tried to do what you suggest.

I loaded up the last CR2 file I took.

I changed the camera setting to CCD/CMOS, checked the FL (2350), CCD Pixel (5.2) and CCD Width/Height (22.2x14.7) were correct for the Canon, and hit Recalc.

Then tried to platesolve from Pointcraft.

It still timed out for me.

 

I went directly to ASPS and gave it the .jpg from APT, it timed out.

Converted the .jpg to .fits, it solved.

 

Are there any other parameters I needed?

 

I’m using APT 3.90 and ASPS 1.4.5.11.

[dwc]

[Dmack1]

Ok, so I'm about all out of ideas. I notice that you have RA.DEC in the windows. I'm not sure where that came from. You would only enter that if you were going to near-solve, which ASPS will not do. Only PS2 and ASTAP near solve. I assume you are trying to blind-solve?

 

I also note that you had manually stopped a solve, then immediately started the next solve without recalc - I find that  I have to recalc every time before starting a blind solve for this trick to work.

 

Here are my settings in Pointcraft, the only ones which could be affecting this are those on the DSLR at the bottom and I dont think they will have any impact.

 

So, apologies I've been unable to help!

Edited February 24, 2022 by Dmack1

[dwc]

@Dmack1 I really appreciate all your help, I feel I’m much closer but obviously missing something.

The DEC/RA came from the Object button.

My settings all match yours now.

I cleared DEC/RA, did a Recalc, and it timed out again 😞

If it stays clear and not too windy I’ll try again from scratch with all the right settings, recheck focus, and use a longer sub.

[dwc]

I’ve uploaded the CR2 file in case anyone can spot anything.

Link removed

Edited February 25, 2022 by dwc
Removed link

[Dmack1]

I tried hitting "blind" with cor-ords entered and it made no difference - still solved.

 

When you have managed to get it solved manually, is it reporting calculated Focal Length? With my 0.85 FF/FR the FL should be 1700mm but actual through solving comes out at around 1960mm. It will not solve if i put the theoretical 1700mm in. So maybe you need to confirm your 2350.