I have a Skywatcher EQ8 and have never managed to get the mount to sync to the pc time. Each time I power up, the mount has the previous observing days date and 8pm as the time. If I don’t change this, SGP/ASTAP never manage to do a plate solve. If I manually enter the date and time in the hand controller, then do a plate solve, it syncs correctly within a second of downloading the image. I am sure SGP can automatically send the mount the PC date and time to do this automatically, but never managed to find out how. Does anyone know ?
SGPro does not ever attempt to sync the mount’s clock with the PC’c clock. ASCOM does allow it, but the ASCOM driver is not required to support it. That aside, a lot of folks have your mount and have not reported this issue. Have you asked around in a group that is more focused on your mount? Maybe somebody here has had that problem.
I’m not opposed to adding this in 4.1, but, again, there is no guarantee it will work for you.
Thanks Ken. I have looked on other forums, but no success. It would be great if someone else with this mount could explain how they automatically sync the mount time and date or if everyone is having to do it manually like me.
Many of the SW Mounts use the same Synta Hand Controller and the latest version is the Synscan V5 Hand Controller which can also be identified by the USB port. My Mount is an EQ6-R PRO. The Mount has the latest SW Motherboard and like the HC, both have a USB port and can connect to a PC using EQMOD. Fun fact: the HC is branded “Celestron” on the PCB and Synta is the parent company of Skywatcher/Celestron.
With the Mount powered off, the last Location and Date are stored by the HC. The default for the Date/Time is the previous Date stored and the Time set to 8pm. There is no internal Real Time Clock (RTC) in the HC. My Mount also does not have an RTC.
Many Users put the HC away in a drawer and never use it again and I have used the Mount with/without a HC successfully. The HC uses the Location, date and time to calculate LST, to assist with Polar Alignment and to do Star Alignment. These functions can be achieved without needing the HC and EQMOD maintains its own independent Sky Model.
One way to set the correct Date/Time/Location is to use a GPS unit attached to the Hand Controller at extra expense. For a Mount that is used at the same location, the GPS unit seems somewhat redundant, so having the option in SGPro to set the Date/Time/Location correctly would be very beneficial.
My first attempt at Plate Solving using ASTAP also wasn’t a great success and SGPro succeeded only using the blind solve failover. I also didn’t have the HC Date/Time setup because I used a laptop EQMOD connection and didn’t have the Hand Controller.
The HC can be powered by 12V from the Mount or from a 5V USB connection. Either power sources are sufficient for it to remain powered up and the time to be maintained, with the HC Setup only initialized when first powered. Using the HC with a USB Power Bank is one (not so good) solution to keep the time if the HC is disconnected from a powered Mount.
Thanks Simon. It sounds like we have had similar experiences. I read in many places that most people disconnect the hand controller and just use the pc interface. As with you, when I attempted this, the plate solve failed because the search start is too far away. Since most people put the hand controller in a drawer, I was hoping someone would be able to advise how they tell the telescope the current time and date so that its search for the first plate solve is successful. As Ken said, this is possible via the ASCOM driver and maybe this is how they do it. It should theoretically also be possible to set up a script in SGP to send it, but this also has me stumped.
When I was using an Atlas EQ-G mount connected directly to a planetarium program alongside SGP I didn’t have a problem with time and date. Have you tried connecting the mount to a program like Stellarium, etc to see how that works?
Bob
I am trying to get setup with SGPro and reach a point where everything “works”. For me the first step in getting plate solving to work is to turn off the “use blind solve” option and evaluate the available plate solving methods to see that they work.
My use of SGPro is very limited, so I can’t say that ASTAP wouldn’t work because I didn’t set the Date/Time manually and there are many reasons (of my own making) why it might not work for me. I’m using EQMOD with ASCOM and my EQ6-R Pro is just another SW Mount which operates with SGPro without (hopefully) ever needing the HC. That must be quite a common scenario. Without an App like SGPro, the HC needs to know the Date/Time so that it can move from the HOME position to do an initial Star Alignment. It is the HC that knows where the Scope is pointing and the Mount is simply receiving instructions to control relative movement. When the HC isn’t used, EQMOD provides a similar Service. If I look at the EQMOD Toolbox and start EQMOD it knows the Date/Time and starting from the HOME position it knows how to point the Scope successfully. Or I can start SGPro and point the Scope successfully. I know that the Date/Time wasn’t set in the HC (it wasn’t plugged in) but does the Mount stop working - it seems to operate without this info?
I did look at he ASTAP website where the use is described: http://www.hnsky.org/astap.htm and the info needed to solve a FITS image is quite modest. The simplest use of ASTAP from the command line is to give it a FITS file and a radius. The FITS file has a header that provides all the info that it needs e.g. the approximate location. The radius is simply a way to get ASTAP to widen its search.
I also searched the ASTAP forum for SGPro problems. I did find (only) one: https://sourceforge.net/p/astap-program/discussion/general/thread/f2b90c76cc/?limit=25#0a53
The interesting thing is that the SGPro log shows how it was invoked and the parameters used. In this case something wasn’t setup correctly. My assumption is that SGPro works with ASTAP by knowing where the executable ASTAP program is and by invoking it with command line parameters.
When I look at what parameters are required, they don’t include the Date/Time from the Mount - so this seems not to be relevant to a successful solve. This is similar to invoking the ASTAP from the command line with only a FITS file and a radius.
ASTAP also has a GUI and can solve a saved image that has a FITS header. It can also view the FITS header. So the obvious thing to do are:
-
Turn on the Mount, setup the Scope in the HOME position. Do a Polar Alignment so that it is roughly aligned. Start SGPro and unpark the scope. Slew to a position and capture an image of a known star e.g. Vega or Capella. etc., and write it to disk. Confirm it has a FITS header and then load the image. From SGPro, ask ASTAP to plate solve it and capture the SGPro log. I assume it will be unsuccessful.
-
Turn off the Mount, attach the HC, turn it on and setup the Scope in the HOME position and use the HC to input the Date/Time/Location to the HC. Do a Polar Alignment and repeat all the steps. Concluding with a second image, and again capture the SGPro log. I assume this time it will be successful.
In each case the same operation has been performed with only the one difference of setting the Date/Time in the HC when it was connected. The two images have a FITS header that can be compared and differences noted e.g. slightly later time. The SGPro logs will also be very similar, so the parameters passed should be similar with only slight variations, excepting a slightly later time.
Two SGPro logs and two FITS headers and two different outcomes should isolate what changed. From what little I know about SGPro, it doesn’t currently set the Date/Time in the Mount and also doesn’t need to query this from the Mount. The FITS header is written by the Camera using info supplied from SGPro. EQMOD shows similar info.
I have had a couple of hardware issues whilst also learning how to use SGPro. My HC wouldn’t power up from the Mount but would power up from a USB connection. The fault was with the SW Motherboard. I had to send my Dealer the HC and HC cable so that they could confirm that they were OK and afterwards they could return them and provide a new Motherboard. I replaced the Motherboard and it is all fixed. Meanwhile, I was trying to use only a laptop and without a HC I found that difficult - I’m used to always setting it up. So using SGPro and EQMOD is a new experience. I’m (almost) getting to the point where I don’t need the HC and can simply use SGPro with EQMOD. I did need to get the SW Motherboard replaced within the warranty period, so that everything works e.g. I sell the Mount later on - to buy an EQ8 Mount…
My main camera also has an issue with one of the USB ports not working properly. I have just returned the ZWO Camera to the Dealer to get it fixed, also within the warranty period. I should get it back in a couple of weeks. My only other camera is my Guide Camera - I might try using this and going without a Guide Camera and continue with learning SGPro. Not good timing, but both the warranties are up in about a month (get it fixed now or pay later).
Simon
Thanks Simon, you have some great ideas there. My main aim is to get the telescope working so that I don’t have to go to my observatory. Remotely power everything up and expect it to work properly, so no manually typing in the date and time. It is really frustrating that SGP and EQMOD are both aware of the date and time, but SGP doesn’t use it presumably because it is irrelevant unless it knows the absolute pointing direction of the telescope relative to earth. EQMOD could find it out, but it only wants it typed in manually or downloaded from a GPS device.
I experimented to see how SGP gets its pointing data that goes into the FITS file used by ASTAP. If I power the scope up without entering the date and time, then SGP takes what it thinks is the telescope direction based on what EQMOD tells it. EQMOD doesn’t have a clue where the telescope is pointing because it is reporting the wrong date and time, so a Solve and Sync fails.
If I then enter the date and time into the mount, EQMOD doesn’t get updated, so it still fails. It seems EQMOD only looks once when it connects.
If I then go to the EQMOD GPS settings and enter the data, then it is possible to get the telescope pointing direction in SGP to change. It is also possible to do this by just entering the local ST and hitting Accept. The only problem is that there doesn’t seem to be anything that links the known physical pointing direction (the calibration) to the setting of local ST. Due to all of these changes I lost the calibration and ran out of time to do another and see if I could get consistency in being able to get a Solve and Sync.
The worst thing is that changing any of the GPS settings triggered a bug in EQMOD (or SGP) where SGP reverses the direction of the RA drive when driving from the Telescope settings tab. Disconnect and reconnect restored this to the correct direction.
Everything is almost there in a way that it could work beautifully, but the developers haven’t quite linked the bits together.
We have different Mounts, so I can only talk about my EQ6-R Pro Mount. As mentioned both the Mount and HC are the latest versions and have USB ports, so are easy to connect to a PC. There is also additional SW on the SkyWatcher US website to download - I haven’t used it except to verify that the latest firmware is in the HC. I don’t have a GPS Unit to set the Date/Time.
We have different scenarios, so I can only talk about using my Mount in the garden and I don’t have a permanent setup. For me I can setup the scope and put it in the HOME Position. I also use a PoleMaster so I can be reasonably sure that the Polar Alignment is almost perfect. The EQ8 has Auto Home and “working with the SynScan hand controller, the mount can be placed to the same home position after turning on the power”.
For my EQ6-R Pro Mount the HOME Position is important because it is the only way to know where the Mount is “physically” pointing. I have limits programmed into EQMOD that limit the Movement to “logically” 20 minutes past 0 RA and 12 RA. Without a known starting HOME Position they are meaningless e.g. the “logical” and “physical” positions are not the same.
I also found two documents that detail the instructions that can be exchanged with either the HC or the Mount. These documents can be found here:
http://www.skywatcher.com/download/manual/application-development/
The two documents are:
Manual: Sky-Watcher Motor Controller Command Set
Manual: Synscan Serial Communication Protocol, Version 3.3
The first one has the commands you can send to the Motor (Mount). The second one has the commands you can send to the HC. For me, the Version 3.3 applies to V4 firmware in my V5 HC.
I had a quick scan of the first document and there is nothing about getting or setting the time. That makes sense because the HC is the “Intelligence” and the Motor is the “Worker”. Most of the GOTO functionality is done by the HC and the Motor is simply there to keep the wheels (gears/belts) operating. Simply put, there wouldn’t be a big advantage setting the time in ASCOM because it wouldn’t get through to the Motor. Sending commands is as simple as typing them into a serial terminal application or finding an astronomy application that uses them e.g. Stellarium, Cartes du Ciel or EQMOD using an application like SGPro.
It was previously stated that ASTAP won’t solve without the HC setting the Date/Time. Have you verified that ASTAP cannot solve for a known location. Setting the Scope to the HOME Position and plate solving around Polaris is very different to solving “anywhere” because “anywhere” requires a knowledge that is relative to a starting point. ASTAP doesn’t need the time to plate solve, only the approximate location.
Assuming that it doesn’t work without the HC. There is still the possibility of getting an SGPro log and the FITS header to indicate why without the HC it doesn’t work, but with the HC, it does works.
Is there a difference between the EQ6-R Pro and the EQ8. If I click the Park button in SGPro, the EQ6-R Pro will go to where it “thinks” the HOME Position is. With the EQ8, will it “force” the Scope to go to the HOME Position. Or, is this a function of the HC to return/set the Scope to the HOME position?
Simon