My apologies. Did not mean to trivialize your efforts. I sometimes become frustrated at the number of times we have to ask folks for logs vs trying to interpret their explanation of the issue. Too much room for confusion…
No need to be sorry. This is what the betas are for…
Looking through logs describing the issue, I think I was able to locate a problematic area in this code (not owning a mount that speaks JNow, it’s hard to test). In terms of AP drivers and the like, even if they describe their equtorial system as “passthrough” it still must report a type. From what @Bhwolf said, it sounds like the mount reports topocentric (JNow).
@trevorn - I do not have the inhibit sync enabled in the driver - when using SGP I do not use TPoint as the automatic centering is so good and I use an autoguider for tracking.
Hello ,now after 2 hhhhhours with 2.4.1(cant find 2.4.1.1 in DL section)
it started with not connecting to the eq6 with this error message…i use bluetooth for EQ6->to Laptop so no Handbox last Version on it was V3.35
i tried it with or without PHD2… i changed back to V2.4.0.2773 everything workd as it supposed to be…
also here are the logs…so i hope it helps…i going to sleep…in 2 hours i must stand up;)… CS…nice Programm anyway… unsuported mount.txt (29.3 KB) <a unsuported mount 2.txt (72.0 KB)
The mount is reporting the Equatorial System type as 0 - equOther - that means “Custom or unknown equinox and/or reference frame.”
After this there seems to be all sorts of communication errors, it’s as if the telescope is no longer connected. It looks as if SGP fails to connect to the telescope if it gets a value for the EquatorialCoordinateType that it doesn’t like.
I tried this using the EQMOD simulator and SGP 2.4.1.2
The SGP log shows:
[10/04/2015 08:39:05] [DEBUG] [Telescope Thread] Telescope: CanSetSideOfPier returned False
[10/04/2015 08:39:05] [DEBUG] [Telescope Thread] Telescope equatorial system is 0, not supported…
[10/04/2015 08:39:33] [DEBUG] [Main Thread] Error connecting to telescope. Timed out.
[10/04/2015 08:39:35] [DEBUG] [Telescope Thread] SGM_TELESCOPE_CONNECT complete…
The corresponding DriverAccess log shows:
08:39:05.023 CanSetPierSide Get GET CanSetPierSide - COM
08:39:05.023 CanSetPierSide Get False
08:39:05.023
08:39:05.023 CanSetTracking Get GET CanSetTracking - COM
08:39:05.024 CanSetTracking Get True
08:39:05.024
08:39:05.024 EquatorialSystem Get GET EquatorialSystem - COM
08:39:05.024 EquatorialSystem Get 0
08:39:33.813 Connected Get Issuing Connected command
08:39:33.813
08:39:33.813 Connected Get GET Connected - COM
08:39:33.814 Connected Get True
08:39:33.816
08:39:33.816 SideOfPier Get GET SideOfPier - COM
08:39:33.816 SideOfPier Get 0
08:39:33.816
08:39:33.816 SideOfPier Get GET SideOfPier - COM
08:39:33.816 SideOfPier Get 0
08:39:35.491 Connected Get Issuing Connected command
08:39:35.491
08:39:35.491 Connected Get GET Connected - COM
08:39:35.492 Connected Get True
08:39:35.523
08:39:35.523 CanSlewAsync Get GET CanSlewAsync - COM
08:39:35.524 CanSlewAsync Get True
08:39:35.524
08:39:35.524 RightAscension Get GET RightAscension - COM
08:39:35.525 RightAscension Get 2.82702047976542
08:39:35.525
08:39:35.525 Declination Get GET Declination - COM
08:39:35.527 Declination Get 90
08:39:35.527
08:39:35.527 Altitude Get GET Altitude - COM
08:39:35.527 Altitude Get 51.5999999292566
08:39:35.527
08:39:35.527 Azimuth Get GET Azimuth - COM
08:39:35.527 Azimuth Get 2.47763109556542E-07
08:39:35.535
08:39:35.535 SiderealTime Get GET SiderealTime - COM
08:39:35.536 SiderealTime Get 20.8270232650984
08:39:35.536
08:39:35.536 SideOfPier Get GET SideOfPier - COM
08:39:35.536 SideOfPier Get 0
The driver access log seems to show that the mount is working correctly but it looks as if SGP is not coping well with an equatorial coordinate type that it doesn’t handle. Could it revert to the current system where if does nothing in this case?
It would be useful if EQMOD were to report a better equatorial type. They should know because they must be matching some sort of database of star positions with mount axis positions to get an alignment.
OK - I’m not sure where to post this because I am now using 2.4.1.2 - but it has the latest JNOW fixes - and it appears to work fine. I am doing solves and syncs in SGP and looking at the cursor in TheSky and it all agrees well.
Here is an excerpt from a log. Not sure if you need the whole log but this is the first time the whole system is working well for plate solving and syncing with cge-pro, sgp, and TheSky. I haven’t done much other testing - just this key feature.
Thanks very much - this is a big improvement for me.
Chris - sorry, I had just done a clean install on an Intel NUC and the ASCOM trace was not on by default for your driver. I do however have the SGP files.
There are two SGP log files, trying to center on M81, with the 2.4.1 beta version and 2.4. The failed centering occurred at about 20.54.
I will try the very latest beta as soon as it is clear, trace is on this time too.
This gives me most of what I need to know, the ASCOM driver is reporting that it’s using JNow.
SGP has converted the position, the scope has slewed there and an image collected and solved. This seems to give a J2000 position that’s close to what is expected.
It may be worth trying the new version, I’ve just tried it with TSX running their telescope simulator and it seems fine.
This is the current behavior (just reviewed to make sure). We display a message saying we are not really sure what is going on with your mount and then set the equatorial system to J2000 (will effectively do nothing). That said, these logs were from a broken 2.4.1.0 build.
I’ve tried with the current 2.4.1.2 build and the UI hangs for about 25 seconds and you get a couple of errors and a connection timeout in the log:
[10/04/2015 20:51:32] [DEBUG] [Main Thread] ===== S E Q U E N C E G E N E R A T O R (v2.4.1.2) =====
[10/04/2015 20:51:32] [DEBUG] [Main Thread] OS: Microsoft Windows 7 Home Premium
…
[10/04/2015 20:55:37] [DEBUG] [Telescope Thread] Telescope Dispatch loop: Received SGM_TELESCOPE_CONNECT…
[10/04/2015 20:55:40] [DEBUG] [Telescope Thread] Telescope: Implements MoveAxis…
[10/04/2015 20:55:40] [DEBUG] [Telescope Thread] RA Move Rate Range: Min->0 Max->3.34245933333333
[10/04/2015 20:55:40] [DEBUG] [Telescope Thread] DEC Move Rate Range: Min->0 Max->3.34245933333333
[10/04/2015 20:55:40] [DEBUG] [Telescope Thread] Telescope: CanSetSideOfPier returned False
[10/04/2015 20:55:40] [DEBUG] [Telescope Thread] Telescope equatorial system is 0, not supported…
[10/04/2015 20:56:07] [DEBUG] [Main Thread] Error connecting to telescope. Timed out.
[10/04/2015 20:56:10] [DEBUG] [Telescope Thread] SGM_TELESCOPE_CONNECT complete…
This is using the EQMOD simulator, no hardware required.
The first error reports that the mount uses an unsupported equatorial system, the second reports “Error connecting to EQMOD ASCOM Simulator!”. That’s going to be confusing, especially with the delay.
Ya… We can tidy that up. It is timing out because of the modal dialog was not dismissed quickly enough. I think we will just forego modal errors here all together.
Yes, 2.4.1.2 fixed a bug with some JNow conversions, it did not address the fact that SGPro does not like that your mount is providing an unexpected equatorial system (that we don’t know how to handle). That said, we have decided to suppress the dialog error, log it and connect using J2000 as the default. This is how you could say SGPro “used to work” so it should be transparent to you now.
Please give 2.4.1.3 a shot.
It would still be a good idea for driver authors to specify an equatorial system though…
@Ken
Ok heres the log if needed
i will give 2.4.1.3 a shot… hope to get it testing before trial expires…
but this is the best Tool so far…with great Support/and Wishlist…nonoblabla they “Just Do it…” thumb UP
I tried 2.4.1.2 beta and SGP nailed M51 within 2 pixels within one iteration of slew and center. Nice one. In fact, I was making a video to demonstrate the ease and power of SGP when I had issues with guiding…
@CCDMan - during the startup of the sequence and subsequent dithers, I ran into what appears to be a reoccurrence of the TSX slewing communication issue, which trips PHD2 and DirectGuide. I’m posting on the SB and PHD2 forums. After three trip-ups, I reverted to Pulseguide and continued without issue for the remainder of the evening. (latest builds of each as of 10 April)