Just checking with JNow owners to see if they are having better luck with the 2.4.1.0 beta (in terms of target centering, mosaics, etc…). No feedback so far (usually a good thing… but you never know).
I didn’t seem to have entering problems before with my Mach1GTO mount, so I don’t know if it’s one of the “JNOW” mounts. However, when I tried 2.4.1 the first time it failed to auto-center when plate solving with large errors (circa 1500 pixel error) on all three attempts before it gave up. I also had at least two crashes with 2.4.1 (SGP has stopped working…). In fact last night was pretty disasterous - I also updated my ASCOM V2 driver to the most recent version and had problems connecting to the mount. It was one of those nights when I had so many compounding problems that I spent 2 hours just getting things working and my directory was so littered with aborted log files that it would be a major job just to sort out which log belongs to which aborted attempt - sorry I can’t be of much help. I ended up rolling back my AP V2 driver and SGP and then was able to connect and get a few hours of imaging. I was waiting for reports here to see if this was a SGP 2.4.1 issue or if it was just one of those glitchy equipment nights best forgotten! I still don’t know why my logfiles seem to report multiple losses of connection to focuser, mounts and cameras - so this could be totally unrelated to SGP.
…Keith
I look forward to trying it with my cge-pro but haven’t been able to yet. I have been traveling - and now am looking for clear skies.
Frank
1 Like
This reply seems to have found it’s way into a different thread…
I’ve done a quick indoors test using the Celestron driver
with NexRemote running in simulator mode and my DSS Camera simulator and it
collects an image, solves and syncs correctly. The previous version
didn’t centre, I ended up with a consistent offset of around 11 arc
minutes.
The mount reports LocalTopocentric (JNow) and the camera simulator
converts the position it reads from the scope to J2000 before retrieving
an image from the ESO DSS archive using the J2000 coordinates.
This isn’t much to go on because there’s far too much simulation to be comfortable with but better than nothing.
Chris
i have a jnow mount , but will not be able to give feeback soon .
I am testing now after downloading 2.4.1.0 - and I confirmed with Help->About that it is indeed 2.4.1.0
This is with cge-pro.
I think I am seeing the same behavior as before. Elbrus does a correct solve and has correct J2000 coordinates for the image - and after the sync, the mount cursor in TheSky has JNow coordinates that roughly equal the solved J2000 coordinates. It is as if the sync was just done with the J2000 coordinates - and those coordinates had not been precessed to JNow for the sync.
I have recently used Maxim/Pinpoint and it was all working properly - so I know combination of TheSky, Maxim, and Celestron/ASCOM work for solves and syncs.
Is there a setting I need to change to turn the new sync behavior on?
Here are notes from the tests:
Use TheSky to slew to near spica and then use sgp to do a solve/sync.
elbrus says 13 25 52 -11 16 16 (J2000 I assume)
sky center is 13 26 40 -11 22 08 (JNow)
13 25 50 -11 17 19 (J2000) -> TheSky value for the center of the image in J2000 roughly matches Elbrus, so the solve looks correct for J2000. It is a little off in dec. but not much.
scope cursor 13 25 58 -11 15 30 (JNow)
13 25 08 -11 10 40 (J2000) -> The JNow value for the scope cursor matches pretty well with the true J2000 value of the image center
I then center the image on spica and do a solve. Elbrus fails so it does a blind solve that succeeds.
Spica 13 26 01 -11 14 31 (JNow)
13 25 11 -11 09 41 (J2000)
scope cursor 13 25 18 -11 08 54 (JNow)
13 24 28 -11 04 03 (J2000)
Once again - the scope cursor has a JNow value that roughly matches the J2000 value of the image center - which is the coordinates of spica since it is centered in the image.
Frank
Hello no clear sky for testing…maybe tomorrow…with eq6 and cdc i will report…cs
I had auto centering failures last night - never getting any closer than 550 px or so. I was surprised as I’d never had a problem with PinPoint before, normally getting to within 20 px first iteration. I have an Avalon Linear Fast Reverse, running Eqmod. I plan to roll back to the previous 2.4.
Barry
Hi Barry
What do you have the epoch set to in EQMOD? I used SGPro 2.4.1 on Sunday with a local Astrometry.net instance and auto centre was working perfectly with my Avalon Linear Fast Reverse + EQMOD (EQMOD and Astrometry.net epoch set to J2000).
Regards
John
Sorry, I should have been more specific. While I appreciate the feedback so far, it is all subjective and not of much use. If you can submit logs highlighting these issues we have put plenty of stuff in them to help trace the path of this stuff.
1 Like
John
Don’t know off the top of my head. I’ll check to see which epoch it is set to tonight.
Barry
I had Eqmod set to JNow and have changed to J2000. So hopefully all OK now!
Problem was located between keyboard and chair (ie me!) . . . not anything within SGP, Eqascom or PinPoint.
Cheers,
Barry
Just had my first clear sky for a while.
Using the 2.4.1beta with Chris Rowland’s ASCOM driver and a Paramount MX - couldn’t get below 900 pixel error. As soon as I went back to 2.4, within 2 pixels on first iteration - on same target.
Sorry - but something appears to be in error with SGP.
I’d like to see a log file from the TSX ASCOM driver.
And I think Jared and Ken will want the log files from SGP.
Quick question Chris, unrelated maybe, , do you have the driver set ‘inhibit Sync to protech TPoint model’ ? I don’t as would not centre if that option was ticked.
I will try the new version of SGP tomorrow if the weather holds and see what results I get.
I spent a fair amount of time to do this and I captured quantitatively the discrepancy between the image coordinates and the telescope sync position - which is hardly “subjective.” I took a look at the log and I see that it does think the mount wants JNow and it does say “converting…” But what is the result of the conversion? I don’t see that in the log. But the actual sync position the telescope was pointed to is given numerically in my post above. Log attached.
Note also the subjective but important point - that if I intentionally offset the telescope cursor with bad sync - the cursor does snap to a new position after doing solve/sync in SGP. So the cursor does move after a sync and it goes to new coordinates.
[4/8/2015 8:06:30 PM] [DEBUG] [Telescope Thread] Plate solving scope frame successful, scope is synced, writing FITs header info…
[4/8/2015 8:06:30 PM] [DEBUG] [Telescope Thread] Telescope: Syncing to J2000 RA: 8.85641386810106 Dec: -42.0851421307488
[4/8/2015 8:06:30 PM] [DEBUG] [Telescope Thread] Telescope Sync: Passed in J2000, but mount requires JNOW, converting…
[4/8/2015 8:06:30 PM] [DEBUG] [Telescope Thread] Attempting to write fits header info for C:\Users\Frank\AppData\Local\SequenceGenerator\Temp\plate_solve_image.fit
[4/8/2015 8:06:30 PM] [DEBUG] [Telescope Thread] Opening fits file…
[4/8/2015 8:06:30 PM] [DEBUG] [Telescope Thread] Successfully opened fits file…
[4/8/2015 8:06:30 PM] [DEBUG] [Telescope Thread] Writing fits headers…
[4/8/2015 8:06:30 PM] [DEBUG] [Telescope Thread] Closing fits file
[4/8/2015 8:06:35 PM] [DEBUG] [Telescope Thread] Scope solve complete…
[4/8/2015 8:06:35 PM] [DEBUG] [Telescope Thread] SGM_TELESCOPE_SOLVE message complete…
Frank
sg_logfile_20150408195559.txt (102.7 KB)
Here is a view of TheSky after doing a sync. The rectangle is a good match to the actual image that was solved, and the telescope cursor should end up in the exact center. Instead it is offset from the center and toward the corner near spica.
I own an Astro-Physics A-P1100GTO mount and I posted a message at AP GTO Yahoo Groups about SGP’s latest upgrade and I asked them what is their controller (GTOCP3) response to EPOCH query. This is Astro-Physics response:
"The mount does not use epochs. It has no clue regarding which epoch is being used and cannot respond to an epoch query. No epoch conversions are done by the mount. It accepts whatever coordinates are fed to it, and spits those same coordinates back out. The GTOCP3 (A-P mount’s brain) is simply a servo control. It does not have a concept of the sky, but does basic calculations to go from point A to point B. The GTOCP3 depends on the controlling software to send the correct coordinates. This is to avoid double precession calculations.
The Astro-Physics Hand Controller takes the catalog coordinates in its database (J2000) and precesses them to JNow before sending them to the mount. Therefore, GoTos done from the keypad are precessed to JNow.
Most other software programs can be set to either send the catalog J2000 coordinates or to send precessed JNow coordinates.
The most critical thing is that you aren’t mixing up the epochs."
Astro-Physics are claiming that A-P mounts do not respond to EPOCH query. Will the latest SGP’s upgrade be an issue with A-P mounts? Lately SGP has worked flawlessly with my mount but that was at least a month ago and I have not yet tried the latest SGP version due to bad weather.
So if I use your latest SGP version, what do you suggest I should do with my A-P mount? Should I just continue to do what I’ve always done in the past? What I have been doing is I set ANSVR EPOCH to JNow probably because that’s what the hand controller also do. Now, if you will always send it using J2000 coordinates from then on to the mount, that might be a problem because I always start my setup with hand controller to slew to a known star nearest to target DSO, center and sync on that star with the hand controller which most likely uses JNow coordinates. From then on, I use SGP’s “Slew Now” and then “Center Now” which will probably now use J2000 coordinates and may not match to the star that was previously slewed and synced by hand controller.
I was going to respond back to Astro-Physics about their response but I would like to hear from you first. Maybe it may not be a bad idea for you to contact:
Howard Hedlund
Astro-Physics, Inc.
Phone: 815-282-1513
Thanks,
Peter
Peter:
I believe the issue here is consistency in the use of J2000 -vs- JNow. The AP hand box expects J2000 data entry probably because, as far as I can determine, virtually all published astronomical data uses J2000 coordinates. The hand box converts the J2000 data to JNow for both mount synchronization and all subsequent slews. A problem would arise if the hand box (or TheSky, etc.) sync’d with JNow and a second software package sent J2000 coordinates for a slew.
It seems to me that SGP needs to maintain that same consistency – expect all data input in the GUI to be J2000 and convert to JNow when slewing the mount UNLESS SGP knows for sure that the mount / ASCOM interface is going to do the epoch conversion.
cm
I think Howard’s/AP response is a bit incorrect or misleading. Really the important thing is what the AP DRIVER responds to. While the CP3 may indeed be dumb, the Driver knows and responds to the EquatorialSystem property as LocalTopocentric (for all intents, JNOW). (Just tested with code/verified…)
I haven’t had a chance to test yet in the field, but I’m happy to have this change. I’ll just need to make sure to put Astrometry back to J2000.
Thanks Bhwolf for very valuable information. I looked at the GTOCP3 serial commands list but could not find any commands that would return the EPOCH. If you know which serial command it is, which one is it? The serial commands list is in Keypad version 4.12 docimentation.
If Ray’s A-P V2 ASCOM driver returns the EPOCH, I wonder if it’s hard coded in his driver?
Thanks,
Peter