Synscan timekeeping

[jambouk]

Is there a device which plugs directly into a Skywatcher mount [EQ8] which will pull through the time when starting up the mount from a parked position? I know there are things to plug into the handset, but we don’t want anything on the handset. And we don’t want to run the mount from a PC. 

Thanks for any replies.

James

[malc-c]

Not sure there is as all the communications will go through the handset port regardless if the mount was being controlled from a PC or handset.  It might be possible to design something that could run on an arduino to time stamp when communications are sent, but where the device would get its time reference from is questionable.

What exactly are you hoping to do... and why from the park positions ?

[jambouk]

Thanks.

It is a permanently mounted telescope so to preserve the star alignment it is parked.

I am just trying to make it easier for other people turning on from the parked position to get a better alignment (so not giving them the opportunity to enter the date or time incorrectly). 

I suspect the GPS dongle into the handset is the easiest answer. I just don’t like the dongle on the handset. I wonder if it can be removed once the time and date and location has been done.

Thanks.

James

[Steve Ward]

Sounds like you're looking for an over-complicated solution to a 'problem' that doesn't really exist in my opinion.

The process of entering the time , date and DST data is hardly a difficult operation or am I missing something , never been a problem to me with my HEQ5Pro in the dozen or so years I've had it.

[jambouk]

It isn’t complicated for me either, but I am trying to simplify the process for other people who want to use the set up on an infrequent basis. I am going to explore using a WiFi dongle.

[malc-c]

First off, there is no "park" or "Return to Home" command in the Synta motorboard command protocol.  So its not as if you could some how split the signals between the handset and mount and run an Arduino or similar so that when finished the user hits a button on the box which send a command so the mount reverts back to the home position.

The mounts motor board also lacks the ability to know where it is physically pointing on power up.  The handset assumes the mount is in the traditional home position at the start.  On power up the handset sends commands such as :e1 etc to obtain the firmware version running on the processors on the mounts motor board, and in response to additional commands the mount sends back the details of its gearing and steps per revolution etc.  When you un-park the mount and send it to a target all the handset does is works out the number of steps is needed in either direction for each axis and the tells the mount to send X number of steps in a particular direction  and at what rate for each stepper.   When you want to park the scope back in the home position, the handset simply tells the controller how may steps and in which direction it need to run in order to put the mount back to the starting point.

The means of communication is via the handset port, or on later mounts via the USB socket.  As far as I know you can't use both at the same time as that would really confuse the mount.  I'm quite certain that the handset will disable the USB port and vice versa.  So plugging in a wifi dongle won't resolve the issue, especially as all it provides an an alternative method of connection to a USB cable / EQDIR cable / Handset.  The dongle allows communications to an app on a phone, which would make things even more complicated for your users.

You best bet it to run training sessions for members who want to use the observatory scope.  Have some laminated detailed bullet pointed instructions on pre and post usage procedures to ensure they know how to home the scope.  It's a darn sight easier than looking for a hardware solution.  That's how our local society operates.  In fact I think the protocol is such that the observatory manager will only give the key out to those who have attended such course and are "registered" to go solo.

[jambouk]

malc-c that is REALLY helpful, thank you. Useful to know about how the parked information is stored and use too. 

James

[jambouk]

I might also borrow a GPS dongle and play with that.

[malc-c]

4 hours ago, jambouk said:

I might also borrow a GPS dongle and play with that.

James, it might help if you detailed with as much info as you can on what exactly you want to achieve.   I personally can't see how a GPS dongle will help with parking the scope...

As outlined in the handset instructions the mount thinks its pointing at the NCP in the classic weights down position.  When you run through the start up procedure it requires an alignment routine, where a star is selected, it works out the number of steps for each motor from the default home position and then if alignment is close the star is in the FOV of the eyepiece, and it notes down and applies any corrections you make to centre the target star and applied some math to then apply the error to further goto targets.  Then when you instruct the handset to park, It knows the exact number of steps required for both axis to move the mount back to its original parking position.  The problem is that when the power is disconnected none of that correction process is retained, so it has to be repeated each time.

Controlling a mount via a computer and cable via EQMOD or GSS overcomes that issue as the driver / application saves each position of the target, and reads this data on the next power up, which is why its the better option for a permanently fixed mount in an observatory.  You can even save a custom park position so the mount stops and starts from a known position and can be on its first target with little or no need for any alignment corrections.  Using a PC to control the mount is IMO less complicated than using the handset, especially as all that is needed to park the scope is a single click on the "park" button on the EQMOD application.  I'm sure your members would easily get to grips with commanding the mount via clicks of a mouse than through the handset which may seem really alien to them.

[jambouk]

Thanks.

Currently I park in the home position and power off. Next time I power on, enter the time and date and resume from the previous parked position, so no need to do any alignment as somewhere in either the handset or the mount, it must retain how much the mount was off “perfect” alignment and applies the same correction but with the sky map rotated for the new time and date, as the scope will skew accurately to whatever I want without re fleshing the 3 star alignment. I’m unsure of the previous PAE corrections are also applied / retained, during a power off and power on.

However, if the time and date is incorrectly entered, the sky map will be in the wrong place and so the goto accuracy will be poor. This is what I want to avoid. I want to reduce the need for anyone else to enter the time and date so in effect they just turn it on and can start using goto without doing anything else. 

Thanks.

James

[globular]

From a powered off parked position:

1. plug the GPS module into the handset
2. place the module on a horizontal surface
3. turn on the mount
4. enter the time zone offset in the hand controller.... as + or - HH:MM [For the UK you just leave it as 00:00]
5. enter YES or NO to daylight saving time [Yes in summer time, No otherwise]
6. wait for "Fixing GPS" message to complete
7. resume from parked position (no new alignment needed)
8. unplug the GPS module from the handset

As you see, your users will still need to enter the correct time zone offset and DST - but there is less to get wrong than the normal handset initialisation entries.
It's still not 'turn on and off you go', but it is closer.

 

* disclaimer:  I've not got the same set up as you so can't attest that this works first hand - but it is my understanding of the process.

[jambouk]

Brilliant, thank you. I wasn’t sure if the GPS thing could be unplugged once it had done its job or if the handset/mount needed access to it all the time the mount was live. I think this is the way to go. Much appreciated. 
James

[Steve Ward]

So what has the dongle done ? ,  other than introduce another few steps to a routine that only needs time , date and DST entering.

As I said before I think you are over-thinking things , just have the routine printed up from the manual in great big letters and hang it next to the mount for the users to follow.

[malc-c]

The issue of entering the date correctly is an old chestnut and often the one that can catch out someone who has never used a handset before.  James, your concern can be resolved by simply printing a simple single note to instruct the user the correct date and if required (its been ages since I used a handset) the location in Hrs/Min/Sec.  The last thing you want is for a user to be able to power up the mount, set the credentials and start observing.  If they have to faff around with dongles, and then drill down in to some obscure option in the set up to read the time / date / location from said dongle then it could make the experience one where the user is less likely to repeat.

It may have changed now, but the procedure we set up for our society's observatory for a members 1st time use was  a short training session on how to unlock the building, power up the equipment and then use the scope.  Once that was done and the Observatory Manager was happy to leave the user on their own and if they got stuck everything they had just been shown was documented in laminated sheets in a folder in simple bullet pointed notes.

However, that said, it's your observatory and whilst we may suggest things, that in our minds makes sense, its your observatory, and you can work out your own procedures and if you feel the GPS dongle works better then that's fine.  

 

[saac]

On 07/09/2024 at 13:22, jambouk said:

It isn’t complicated for me either, but I am trying to simplify the process for other people who want to use the set up on an infrequent basis. I am going to explore using a WiFi dongle.

There an app available which when opened presents all the correct information in the correct format (BST ect) for the user to enter into the handset.  While it is not the automatic data push/pull that you are ideally looking for it really simplifies the task of initialising the handset. I believe it is available for android only I think.  I can post a screenshot tomorrow if it would help. 

Jim

[jambouk]

Jim and Malcolm, thanks.

[PeterC65]

The pointing model (location, time, date, global alignment, local pointing accuracy enhancements) is not stored in the mount, but in the handset, or in the SynScan software (on a smartphone, tablet or PC). As @malc-c mentions, the mount itself is dumb, and has no knowledge of these things.

The handset does remember things when it is powered off, but only things that have a fixed value like location, global alignment, and local pointing accuracy enhancements, and at power up these things can be re-instated. It doesn't remember time and date because these are not fixed and instead change over time, and to remember them it would need a constantly running real time clock.

SynScan runs on a device that knows about time and date, and it records the other parameters, so it can start the mount and maintain alignment without any manual intervention.

By the way, the mount can be controlled by both a handset and by a USB connected instance of SynScan at the same time. Being dumb, the mount does not allow only one. It will respond to either, taking up the position it was sent by the last one that controlled it. Doing this is a bad idea as the handset and SynScan will have slightly different pointing models and so will be at odds. However, it does mean that I can leave my handset connected, but untouched, when I'm doing EAA and controlling the mount from SynScan on a laptop. I leave the handset connected because the RJ45 connector that it uses is not designed for large numbers of connection / disconnection cycles.

 

[jambouk]

Thanks Peter. I'm pleased the pointing accuracy adjustments are stored between power down / power up cycles. Useful to know.

Do you happen to know how accurate the "clock" inside the handset is? Is the amount of time drift during say a 6 hour session is?

James

 

[PeterC65]

30 minutes ago, jambouk said:

Do you happen to know how accurate the "clock" inside the handset is? Is the amount of time drift during say a 6 hour session is?

I don't know this, but I would expect the drift to be sufficiently small to have no effect over the duration of a session (even simple electronic clocks will not drift noticeably over periods of a few days).

 

[malc-c]

45 minutes ago, jambouk said:

Thanks Peter. I'm pleased the pointing accuracy adjustments are stored between power down / power up cycles. Useful to know.

Do you happen to know how accurate the "clock" inside the handset is? Is the amount of time drift during say a 6 hour session is?

James

 

Peter has stated that the handset doesn't have a means to store date and time as its RTC circuitry needs constant power and there is no battery back up for either a separate RTC chip  or main processor to maintain date and time.  The moment the power to the mount is removed it loses that data.  Even if it did store the last session time and date it would be irrelevant as without an RTC running on the board the handset has no knowledge of the duration its been left unpowered.

Reading through the data sheet for the processors used the clock is derived internally from the main processors running speed which itself uses a 25 Mhz crystal.  The accuracy is fine for an all night session, as the internal clock would only loose a minute or so over the course of a month of continuous use if the mount was left powered with the handset connected.

Peter has confirmed (thank you) that you can have a USB connection and handset connected at the same time, but using both will confuse the mount and should therefor be avoided.

If you are that concerned about a user entering the date un UK format rather than US  then just stick a label on the handset "use US date format" - Job done without complicating the start up procedure 

[jambouk]

Thanks Malcolm. 

[saac]

@jambouk, Here's the screenshot from the app I mentioned. It is called SynscanInit and was available on the android store, hopefully still available.  It is simple in that it presents a screen when you open it which gives you the parameters gps, time date etc all in the correct format to enter into the handset. I only use the handset very occasionally now but I find it useful as I can never remember the format and whether we are in DST or not! I don't know if that would help, assuming it is still available.  It would of course rely on each user having the app installed !

Jim 

 

[jambouk]

Thanks Jim. I can't see it on the app store so maybe it is still just for android. 

[wookie1965]

https://apkpure.com/synscaninit-2/com.RapidoDroid.synscaninit2         Yes just for Android

Edited September 9 by wookie1965

[malc-c]

10 hours ago, saac said:

@jambouk, Here's the screenshot from the app I mentioned. It is called SynscanInit and was available on the android store, hopefully still available.  It is simple in that it presents a screen when you open it which gives you the parameters gps, time date etc all in the correct format to enter into the handset. I only use the handset very occasionally now but I find it useful as I can never remember the format and whether we are in DST or not! I don't know if that would help, assuming it is still available.  It would of course rely on each user having the app installed !

Jim 

 

 

Of course all this discussion is irrelevant for twelve days of the year as per the example shown above