I was having new difficulties with plate solving this evening and am looking for ideas about what could be going wrong. I am using SGP version 3. Upon a successful solve and sync, SGP reports that the mount/telescope has been synced, and I am not able to confirm that although I had no problem with solving and really syncing before I upgraded and I am not saying this has anything to do with the version. I did check my EQMOD settings for a successful sync and all are the way they are supposed to be.
The difference between what EQMOD thinks are the actual coordinates and the Sync coordinates is greater than 15°.
EQMOD thinks that the mount is in a “weights up” position.
In both cases, the requesting software gets no information that the sync was not actually performed.
I would suggest restarting (Power off / Power on) the mount in the home position and then unpark from home. You might also want to delete the last sync info in EQMOD. After that, the syncs should work again. You should be able to set the home position with sufficient precision just by eye.
The behaviour is not ASCOM compliant. The fundamental principle of ASCOM driver development says:
Do it correctly or signal an error.
This is the basic “contract” between a driver and its client application. Your driver absolutely must either do what it is asked or signal an error condition for the client to trap. Unless the client gets an error, it will always assume you have done what it requested and continue in its logic under that assumption. This means that you must not return “illegal” values for properties in lieu of signaling an error, or “try” to do something and return whether it was done or not. You cannot expect client applications to know about limitations and quirks of your device and avoid them (see the first principle above).
Silently ignoring a command is not an option.
However the screen shot shows some interesting things.
The Ra of the mount and the Ra reported by the solver are different by nearly 8 hours - getting on for 120 degrees. With differences like that it’s almost impossible to say what position the mount should be set to by the sync. Not only does the Ra and Dec have to be correct but for a GEM the pointing state must match how the mount is set. There are a number of cases where the correct mount setting can’t be determined - when the sync position is close to the meridian for example.
Using Ra and Dec offsets to sync could lead to all sorts of problems because the mount axis position and the Ra or Dec are so different. The mount could think it’s crossing the meridian 120 degrees before or after it actually is.
Sync is intended to allow a user to make minor corrections to an aligned mount position, not as a way to align a completely unaligned mount.
As Horia says getting an approximate alignment is pretty easy.
I usually start from home position and am very sure that I did last night. I had deleted all the sync data and went through the SGP’s help menu to be sure EQMOD is set correctly. I should have returned to home position, powered down the mount and started over again to clear any bugs in there, but I didn’t.
As I replied to Horia, I started from home position. I acknowledge the 8-hour difference and I do not know how that was happening. As it is usually, I use Starry Night for navigation, and last night M31 was on the west side of the meridian in SN7 when I knew it was on the east side, and when I clicked on it in SN7 and asked it to slew to M31, it guided the scope to a point on the east of meridian where it was more practical to expect M31.
I don’t get too many chances to work with my system given we rarely have clear skies here in winter. In between SN7 thinking backwards and EQMOD not getting changed after a successful sync through SGP, I didn’t know what to think, and I didn’t know what is and is not real and who is telling the truth.
The mount is pretty new and I know that EQMOD does talk with the mount since I tested manually slewing through EQMOD and then come back to park position before launching and setting up SN7 and then going for plate solving. As soon as we have clear sky again I am trying again.
Because of this discussion, and how Horia and Chris both are syncing cannot take place when there is so much difference between the RA, I think SGP should do something to alert a user about that and the user interface should not say that the mount (scope) was synced and perhaps explain why.
Just to be clear, EQMOD did originally raise exceptions on syncs but that caused issues with SGP which insisted on syncing prior to performing meridian flips. Syncs prior to flips are madness - you are applying a pointing correction at a point the furthest posible angular distance from there the mount will subsequently be positioned - there is practically no chance such a sync correction will of any use and will only act to make the flip less accurate. Where the mount had already tracked past the meridian EQMOD would reject the syncs outright and SGP, on receiving the exeption, would then abort the flip process. By avoiding raising an exception the flip process could complete - every one was happy. This was all discussed in depth at the time and it is interesting to note that the comment in the code associated with the removal of the exception is “removed upon the advice of Chris Rowland”! These are your words form a post on this forum made back in Nov 2015:
I’ve tried to persuade Ken and Jared not to do a sync just before the meridian flip slew but to no avail. As you know it doesn’t help and can make the task of pointing after the slew harder.
If you can’t get data that you can use to modify your pointing model safely then silently doing nothing seems the least worst option. Hopefully that will prevent the situation where the mount turns out not to have tracked past the meridian.
Chris R
So it seems silently ignoring a command is an option - at least in the view of one prominent ASCCM developer!
The choice at the time was to have an ASCOM compliant driver that didin’t work with SGP - or a non compliant driver that did - most folks here wanted something that worked, so that is what they got and I make no apologies for that. Maybe things have now moved on with SGP taking a more sensible approach to sync before flips and sync rejection. If so I’ll hapilly re-instate the exception and you folks can take your chances on any side effects that may/may ot have.
Chris, I would like to suggest, do not change that. It works the way it is now and dropping a Sync now and then does not create a real problem for the user, if he understands the reason.
I also do not think that changing something in SGP regarding Syncs, would be a good idea. The ASCOM Definition specifies:
This implies that, before issuing the Sync, the calling program should check with the mount if it is OK to do so. This might open a can of worms, as it is dependent on the mount implementing the optional “SideOfPier” property (at least the “get” part of it).
On a more general chord, the Sync, as defined in the ASCOM standard, has some issues and every mount/driver manufacturer tries to compensate that the best it can. Some examples (this is in no way a critique):
TSX of Software Bisque silently drops all syncs if it is connected to a Paramount. I think - but do not actually know – that it accepts them for other mounts.
AstroPhysics strongly recommends the option “replace Sync by Recal”, which is a kind of nonstandard Sync. It automatically takes care of the “weights up” problem.
There is a dual use of the Sync command: it either syncs (i.e. rotates) the pointing model or it ads points to a pointing model. The second use is not defined in the ASCOM standard and must be taken care of by a setting in the driver. (This is not that bad if the user understands what is going on)
About informing the calling program that the sync was not accepted, the standard only specifies two possible errors:
One might throw the “Invalid Value Exception” to signal dropping the Sync but this is not exactly clean, as the given value might actually be OK. A possible solution would be to have a third exception, something like “SyncRefused”. Thus, the calling program could react accordingly.
I agree entirely on the madness of doing a sync just before the mount does a pier flip. It achieves nothing and, because the mount is in an anomalous state, has caused all sorts of problems.
The ASCOM contract is as I said “Do it correctly or raise an exception”. This contract should be honoured by all parties - the driver, the application and ASCOM itself.
My post in 2015 did not say that silently doing nothing was acceptable in all circumstances, only that I thought it was the “least worst” option for the specific case where the mount had tracked past the meridian. Really it’s making EQMOD non ASCOM compliant because SGP is not ASCOM compliant. Two wrongs don’t make a right.
I was not suggesting that it was acceptable for the general case where a sync is not possible.
With hindsight it was a mistake. It would have been better for the problem with SGP to be fixed. It isn’t difficult, and in the case of a sync before a meridian flip the exception can simply be discarded.
In the case of the different problem that this thread raises silently ignoring a sync is, I believe, definitely wrong. A sync in the context of doing an alignment from cold is a major change to the mount functionality, in this case changing the mount position by 120 degrees.
Sync is intended to make minor changes to an aligned mount’s pointing model, not to do an alignment from a random position.
So I would suggest reinstating the error in EQMOD. SGP should be trapping and handling the error. It may be that the pre flip sync has been removed. It was causing all sorts of problems with multiple mounts.
As ever, thanks for the guidance. I’ll make the change as soon as I can, Its never been a big deal to me either way - it was only the “flipping” SGP users that were struggling
SGP developers: Please confirm that ASCOM sync before flip has been removed, or that sync failure does not prevent a flip from proceding.
I’m sure you will appreciate that I’m not keen on making a release that may trigger an avalanche of fault reports and if the SGP sync/flip issue still persists then it follows that many SGP users may become reluctant to take any new EQMOD release - this will be bad news all round. So, what I’ll do is issue a test release of EQMOD (V2.00n) to our Yahoo group for SGP users to test - particularly with regard to flip operation (I don’t use SGP so won’t be testing anything). If it turns out that there is still an issue then the only way forward (until such time as SGP fixes things) will be to make the raising of the sync exception a setup option (defaulting to raised). SGP users will then have to decide what sort of operation / failure they are happiest to live with.
The current verison of the standard may only explicitly specify two exceptions but EQMOD is written to the verison2 telescope standard based on ASCOM sourced VB6 code of the time. This base code included a number of exception codes- one of which was &H80040402 - value not set - and this is what is being reported.
Ultimately the client has to catch all exceptions and any indicates failure of the called funciton to execute sucessfully. Each exception has an associated descrtiptive text string and if nothing else a client can log this and notify the user.
EQMOD as is certianly an “oddball” driver and does many things that an ASCOM purest could take issue with (its own interface, own mount control functions, syncs building models etc) but we’ve always tired to be as ASCOM compliant as we can. When EQMOD gets called out publically for being non compliant this can give the impressionto our users that EQMOD is not safe to use. To that end I’m happy to be guided by any advice offered by Chris R.
Anyhow lets see what happens, hopefully all will be good. It is after all serveral years since eqmod had to go “silent” to bypass a minor inconvenience in short SGP flip handling and over that time SGP may well have evolved such that it is no longer necessary.
At this stage I’m not making a new public release of EQMOD, only a test release so those using SGP can determine if any issues still exist. If they do then EQMOD will take the “non-compliancy” on the cheek and stay silent on syncs (or if possible stay silent only on those made when past the meridian). Rest assured that given the significant number of EQMOD users who also use SGP I’m not going to leave them in the lurch!
I just want to thank you for the great work you have done with EQMOD. Together with the ASCOM group, the PHD/PHD2 people, the AstroTortilla/ANSRV people, you have had a huge contribution to the progress of the amateur astronomy. Thank you.
Well, I appreciate very much that the subject I started has been the nesting ground for more significant conversation on EQMOD, SGP and handshake thereof. These are my two favorite software although I have complained about the mysteries of EQMOD here and other forums.
Since I have your ears here, I want to offer you that an issue with EQMOD when it comes especially with beginners is that as beautiful as it is, it doesn’t provide some feedback to the user that it should. Two of those are showing what local time it is using to calculate LST and another one is what com port it thinks it is attached to. The selection of com port should be on the EQMOD interface instead of the driver configuration, or on both. For those of us looking for com port randomly because we don’t know better we have to do that on the manager and then relaunch EQMOD to see if “it worked”.
I don’t understand your comment about LST. LST is calculated using the current universal coordinated time (maintained internally by your PC) and your site location (from the EQMOD setup). Local time doesn’t come into it so there is absolutly no point in showing it (I’m sure your PC has a clock that can do that anyhow).
When it come to COM port selection, It seems to me that your issue actually lies with your stange decision to use trial and error. Confirming which COM port is being assigned to your adapter is just a matter of opening up the windows device manager and watching what com port appears/disappers whilst plugging/unplugging it. For EQMOD that com port number needs to be 16 or less - if it isn’t then use the device manager to change it (see the FAQ on the EQMOD project website).
Any follow ups please take to the EQMOD group - as we are moving way off topic and I won’t diserepct this group by making any further posts.
