"Get Current Position" Button

I think that if you do a solve and say ‘use these results as the reference image for the target’ it will use both the center coordinate and the rotation angle for the target. So I really don’t see why this thread implies something is needed; as long as the plate solving works and as long as you have manually framed the object the way you like it - the whole thing just involves a button push and no manual typing of numbers.

The nice thing about doing things this way is that if you use the exact same solver for the reference image and for the target, and if the centering works properly, then there won’t be any issue with slight differences in coordinates or equinox or anything. It should be a very good match. This is very different from taking an already solved image and using its coordinates as the reference. There may be some discrepancy due to different solvers - I guess 1/2 -1 arc-minute - which may or may not be an issue.

And if you are out in the field and don’t have an internet connection to use astrometry.net - just use PlateSolve2.

Frank

yep - that is where I was on response 14. There are always unique approaches and software cannot always accommodate every one. In this case, however, I’m confident that you can achieve what you want using SGP as is, with a single button press. I previously used TSX or C2a to do the alignment, fiddle with rotation and a few small movements to get the framing right and then transfer its plate solve coordinates to the sequence, ran sequence, job done. I still do this when the nebula is irregular, as the AstroPlanner or catalog coordinates for the ‘center’ do not give the most pleasing composition.

I have Pinpoint and I once did a comparison using all the different platesolvers - I have to admit I have not seen the level of difference that Frank mentions. I found them to be identical for practical imaging purposes.

Ok, looks as if I need to clarify what I’m trying achieve. I am aware that I can plate solve a current target, however that requires manual framing and if the physical position of the mount is potentially a number of degrees out (remember I have no sync points yet)… My desired workflow post polar alignment would be, open planetarium application and slew to desired target, switch to SGP, use target coordinates from planetarium application without having to transcribe or switch back, and sync/re-center the mount. This should get me on target, with a sync point close by, without having to switch between applications more than the initial switch.

So quite simply, I am after a way of copying, transferring the ASCOM position of the mount to the target box, or can we change this feature request to Sync and solve on current ASCOM position. If I wanted to be unrealistic, the ultimate solution would be to make the feature request “Integrate Planetarium into SGP”, but I really am trying to make things a little easier for the developers than that. :slight_smile:

If I have to take a frame, as suggested, then I would need to switch back to the planetarium application and re-slew, take another and basically perform the target centring manually.

Another point to re-iterate, my only source for coordinates in the field if especially if I:
a) planned targets and
b) have to change to an un-planned target due to obstruction, change of mind or other entirely valid reason :slight_smile:
Is a planetarium application, so no reference images to solve from.

My previous workflow was - polar align, Slew to target, use astrotortilla to solve centre and sync to current ASCOM position, begin imaging run.

I think that as nobody has come up with an efficient way of transferring ASCOM mount coordinates to SGP without typing them or switching multiple times between applications, can I safely say that SGP doesn’t already have this functionality and this is a valid feature request?

Anders

Anders, you can already do this with Stellarium. There is a way to copy
and paste the coordinates from Stellarium into SGP. The “how” escapes me
right now but do some searching on the forum and you should find how to do
it. One thing I do remember is that when you click on an object in
Stellarium and it displays a bunch of info about the object in the upper
left corner, you need to set up Stellarium so that only the RA and DEC
coordinates are showing and not all the other information which can confuse
the paste into SGP.

You can also do it with Cartes du Ceil.

Select and centre an object in CdC, then use the CdC context menu and select Copy Coordinates.
And in the SGP Target Settings window use the RA or DEC context menu and select paste. Ctrl-V also works.

1 Like

There could be a button in the telescope control page that says “use this ra/dec for the target coordinates” - but I wouldn’t recommend it. Unless you have a high end mount with a good sky model, that ra/dec position will have a fair amount of inaccuracy and won’t be repeatable from night to night - especially with different setups.

But yes you can do a direct copy/paste from several of the planetarium programs into SGP - and that is much more solid as long as you use the right equinox - which is usually j2000.

I use TheSkyX and it has some of the features for this - but is annoyingly lacking in certain things. You can click on a star or object and then cut and paste from the “Object Information Report” panel directly into sgp - and that is great. But the annoying thing is that you actually need to click on an object or star - and you can’t just use the center of the view - at least I don’t think you can.

And I like to plan things using a field of view indicator, or FOVI, by dragging it around and rotating it. And the FOVI has a center point indicating exactly where the center is. But you can’t click on it to get the coordinates and copy them into sgp. You need to click on a star right next to it - if there is one.

So there could be a ‘use this position’ button - but I don’t recommend it. It’s much better to do a plate solve and know exactly where in the sky you are pointing referenced to the stars. And if you are already using a combination of imaging and planetarium to find objects - which is also what I do - then all you need to do is press plate solve and then press “use solved coordinates for target” or equivalent.

Frank

Thanks Joel and Chris, I’ll give it a try, do you know if I can copy and paste one value, or do I have to switch back and forward a couple of times?

Frank - @freestar8n , you’ve missed one crucial piece of information I think, you are talking about having a good sky model, I believe in this case, that is irrelevant, thus my point for the request. I don’t need a model at all (and am trying to do this without building one as it’s not needed), as I slew post polar alignment, then plate solve, sync and nudge to target (hopefully automatically). Hopefully it makes sense?

Thanks

You should just have to copy and paste once, no need to flip back and forth.

You seem to be saying two different things: Use the coordinates from the planetarium program, and use the coordinates from the ascom position of the mount.

If you are not currently centered on the target and your goal is to center on the coordinates indicated in the planetarium program - then the ascom mount position has no value. You just want to copy and paste the planetarium coordinates into sgp and tell it to go there. And it will go there by plate solves and the normal centering procedure. The ascom telescope coordinates serve no purpose here.

The only time you would use the mount coordinates themselves are if you are already centered on the target and are well sync’d to the sky. And if you are, you can just use the plate solve coordinates.

Anyway - It sounds like cut/paste is the way to go for you - and it should work pretty well and without re-typing in many cases.

Frank

Thanks Joel, I’ll give that a try, hopefully the RA and DEC coordinates come across in the clipboard in one go, otherwise there would be a need to task switch.

Frank, my logic is that by slewing using my planetarium program then using the ASCOM mount reported position as my target, I would be able to bring the target coordinates across to SGP without any sync points and use the integrate plate solve engine to do so. It may be two different things, however I have successfully used this procedure before adopting SGP and found it to be quite efficient, to, after initial “blind” slew, plate solve and add the first sync point on a target. I think there is an efficiency to gain here by combining them in this use case, as to be able to slew an unsynced mount then use those coordinates would enable me to be hopefully close enough not to need to blind solve the mount position, and from the solve sync that point, re-center etc.

It has no value unless I slew there then copy the ASCOM coordinates as the target value and get SGP to solve, sync and re-center

My logic is that I don’t need to be synced to the sky at all, as it’s the mount coordinates (post un-synced slew) that I’m interested in bringing across then using the solve engine to do the centering.

I think the point I’m trying to convey (and maybe not too clearly :slight_smile:) is that what I’m trying to achieve is to reduce the amount of task switching and use SGP as an ad-hoc imaging platform without web connectivity, without entering or transcribing coordinates and without manually framing the target, leveraging a plate solve engine to sync and center.

I still maintain that my original request would be a useful and easy to implement feature (at least to me, but also to a few others that have replied to this thread and other threads communicating similar challenges.)

Another thread that I think would benefit from the same is: Framing with skychart - Sequence Generator - Main Sequence Software

OK - I finally get what you are asking for.

You set up the mount so it is roughly aligned to the sky and you choose a target with a planetarium program. You click on the target and it tells the mount to go to the coordinates you want. The mount slews to those coordinates and it thinks it is at those coordinates - but it isn’t because the mount isn’t sync’d yet.

But right there - sitting in SGP in the telescope control - are the coordinates you want to use for the target. And all you want to do is press a button at that point and say - use the telescope coordinates - even though they are not truly where the mount is pointing - as the target coordinates.

Then you start the sequence and it centers on those coordinates for real - with a plate solve - and there is no cutting and pasting. All you did was click on the planetarium program - then click in sgp.

This actually would match one of my use cases and I can see the merit of it. It’s just one little added button in the telescope dialog.

But it’s a pretty obscure usage and I’m not sure how common it would be. But in a way it is natural.

One annoying problem with it is the problem I have with my mount and some others: when you slew to a specified Ra/Dec value - you may not land exactly there - even according to the mount’s own ra/dec values. You are assuming that when you click on a certain ra/dec value and slew, when the mount stops it really will be at those dialed in values (even aside from the actual pointing error). So there will be a small amount of error there that is mount dependent.

But I do see the merit of what you’re asking for - and it would have advantages over all the cut and paste tricks that might be needed - if they work at all.

Frank

1 Like

That’s it Frank!

Sounds like we’re on the same page now. It may seem obscure, but it makes sense to me and especially when I don’t have the time to plan my targets or there is some sort of obstruction to a pre-planned target, it allows me to set up and perform more ad-hoc imaging leveraging the integrated plate solve. Hopefully this will get some traction from the developers and it is seen as a useful feature.

Thanks (for bearing with me and persisting)

Anders

The method you are describing is the exact same method that I used to use
with Astrotortilla. Slew to target coordinates with Stellarium/Stellarium
Scope, run Astrtortilla and it would get the last coordinates that you
slewed to automatically from the ascom driver. It would them plate solve
and adjust until you were actually on target. Then use whatever program to
image. What you want is a button to use Platesolve2 to actually center on
where the mount thinks it is or “Confirm Position”. That sounds very
useful to me.

Best,

Bruce

1 Like

I just noticed that the telescope control panel does have a button to set, or go to, the current telescope position as a “target position”. So it isn’t based on a plate solve and it will store the current telescope ra/dec values for use as a goto later. It’s intended for manual focusing where you jump back and forth between target and bright star.

This use of “target” is different from the target in the imaging sequence. But there is a button already that does half of what is needed. It ignores plate solve and just stores the current ra/dec values. But I don’t think you can display them - and you can’t cause them to populate the ra/dec values of the current imaging target - like you can with a plate solve.

But if you did a slew from planetarium program, and then pressed “set target marker” in the telescope dialog - and then did a plate solve - and then did a “Go to target marker” - you would end up pretty close.

Not ideal, but avoids the cut and paste.

Just one extra button next to Set and Go on the right side of the dialog could be “Set for current target” - and I can see that would be useful.

Frank

I understand now - that approach, however, gives a different outcome on each night (if you have a portable setup) - that is why I have always tried to use centering to a real RA/DEC target with plate solving. This allowed me to pop my tripod and Paramount MX into the garden, into fixed leg positions, not bother with checking polar alignment and just run the SGP sequence. It took care of the rest and allowed me to image the same target over several nights.

1 Like

That’s what was preventing me from understanding why this approach was ok: It would work fine with a portable setup and should give the same outcome regardless of setup differences.

The reason is that the path from clicking on the planetarium program, going into the telescope, and then being read by sgp - is direct. It just replaces a cut and paste and is in a way more natural.

All the button does is say - the current ra/dec values are not where the scope is aiming in the sky - but they are what I want to use for the target. So center on those values for real with a plate solve and start imaging.

There is a small problem that “landing error” will cause the mount not to land exactly at the ra/dec values it is aiming for. I’m not talking about sky error - I’m talking about a slight miss of the actual values the mount is trying to dial in during the slew. That is a real source of error affecting my mount and others - but for this application it is small.

I think the confusion is in the name “Get Current Position”. It isn’t getting the true current position of the mount - it’s reading the ra/dec values the mount thinks it is pointing at - and you know that it isn’t. Those values are the real, exact target values you want to use.

Frank

1 Like

Thanks guys,
Maybe I should have requested the feature under a different name, however it appears that through persistence I think my request is understood! Now to wait and see if we can get it integrated into SGP. Thanks all for bearing with me!

Frank, the last piece of my logic would be that the landing error would be resolved by the plate solve engine iterating the mount position to match and getting me within my set margin of error, and not unique to this situation I’m assuming for a multi-night target on a mobile platform.

Anders

Yes - that’s the bit I was concerned with and hence why my advice to use an absolute target. The mount might think it is pointing correctly but time variation and physical mount alignment, from one night to the next will yield a spread of actual image centers.

I would go as far as to say that putting in a button for this feature is not a good idea, as it encourages a less accurate approach and can catch out the unwary, who do not necessarily appreciate the real errors in a mount pointing system.

@buzz The idea of the feature basically doesn’t have anything to do with where the mount is pointed, as this is sorted out via a plate solve. So this is not a manual frame exercise, it is being able to use an application to get the mount within a margin of error for a plate solve, and blind solve if needs be. The feature is about an easy way with one button click to transfer a position in the sky from a planetarium application to SGP.

I could have requested alternatively that SGP uses The Sky, CDC, Stellarium, etc SDK and create an integration, however as we all have a universal tool to transfer the coordinates (ASCOM), this is a way to leverage the tool to populate the target.

Correct, the mount does think it’s pointing correctly, however the idea isn’t to begin to image then, it is to grab the current ra/dec values and use those as a target value for a capture plan. So by my logic, to use the current reported mount position to populate the target would allow a smooth process to perform the data transfer and easily sync the mount to the sky via a platesolve (or 3). The issue with “one night to the next” again is resolved by using the coordinates as a target, as I can then start up the mount on the next night and use the previous session’s coordinates as my target, solve sync and fire away.

Can I ask, does anyone create a model when they start up, or as I want to, rely on a set of target coordinates with an un-synced mount, goto, plate solve, sync and capture? This has worked for me in the past with my previous application suite.

Thanks

Anders

Buzz I can speak from experience that this idea is not obvious and it seems inaccurate - but it really isn’t. The mount could be pointing 10 degrees off and it wouldn’t matter as long as ultimately it can plate solve and find its way to the true target location.

The mount and usb and ascom are just conduits for the exact coordinates sent from the planetarium. All sgp ends up doing is reading off those exact values that the user clicked on in the planetarium program.

Now - unfortunately there is a tiny twist to this that I don’t think Hamiland sees yet. If my target is ra=1h, dec=10N - and I click on that target in the planetarium program and tell the mount to slew there, you would expect the mount, when its done slewing, to say that it is at 1h/10N. At this point it doesn’t matter where it is actually pointing - all that matters is where it says it is pointing - because that is what you want to use for the true target coordinates.

The problem is the mount may actually say, when it stops slewing, that it is at 1h, 0m, 15s RA and 10d 0m 10" Dec. That would be a “landing error” where the mount didn’t exactly obey the request to slew to the target - even according to its own encoders. In that case, if SGP used those values as the true target - there would be some error. But it would usually be small.

Frank

1 Like