Star Discovery Problem

[Shaun_Astro]

Sometimes I notice my mount will not align properly. Tonight and last night were such occasions. I have released it's perhaps because I've aligned it just before midnight, and it seems to mess it up as soon as it goes past 12! It ended up being of sync by about a day (nearly a degree on the az, and about 20 mins on the alt).

I turned it off and then on after 30 seconds, put the new correct date in, the 25th (it was after midnight now), with the right time etc. Everything was correct, but it was out by the same amount.... I reset it again and it came back on with the previous day's date, the 24th...

I re-aligned it FOUR TIMES, with the same problem every time.... Should I reset it to factory? Would this be just as it was delivered?

Also, it seems to want to do a 160 degree spin to get to Deneb from Alberio! Why?

 

[ronin]

If you are doing half the alignment before midnight ahd half after then I can partially understand. These things are not PC's and have if you are lucky an 8 bit processor and 4K of ram. The software is not sophiticated either, I would guess that it starts with T1 for star 1 and then T2 for star 2.  expecting T2>T1 however in the scenario you describe it may check and find T2<T1 and so throw an error state. I doubt that the software is sophisticated enough to take the date into account during alignment.

One aspect also forgotten is that the software will not be specified or written by astronomers, Synta will have made a specification and it is given to an internal dept or an external company and they write simply what is specified.

Not sure about dates on your mount but on mine it may keep the same dates if powered off then on for a few seconds, say 15-20, but if off for a longer time the date that appears can be easily a few years different. About the one consistant aspect is the time is always 20:00 but all the rest can be anything. As said very simple processor.

One strange thing is that just after midnight on the 25th is still the 24th, you work on BST the scope has converted to UTC = one hour earlier so in UTC time the 24th. I half suggest that you gave it the 25th, then said DST = On so the scope has stored the UTC Date and Time of 24th.

The 160 degree swing is likely to be the presence of end stops, in effect if it went the "short" route then it would either hit an end stop (so never get there) or it will pass a "wind-up" point which to the scope defines that it has rotated too much in one direction. Present on many scopes. It can be a bit odd when you do not have one, the things will/can sort of go round the same way all the time - ETX-60/70/80 have no end stops but the ETX-90/105/125 do.

Think my ETX-105 if set central will rotate 1 1/3 clockwise and 1 1/3 anticlockwise then meet an end stop - it may be 1 2/3. The idea is to start from the straight ahead unwound position, just you have no idea where that is, unless you undo clutches and try to work it all out, and on them you actually do not have an indication of front and back so the thing can start out facing 180 degrees out initially.

No idea about the 1 degree and the 20 seconds out, I would have just put that down to alignment and initial start position and center a reference star then perform a Sync.

London may be a "bad" location, something to do with a longitude of 0. 0's and software do not mix well.

[Shaun_Astro]

Thanks for the reply. I even aligned it after my session to see if the error persisted, and it did. It was 01:11 utc, 05/25/2017. I used Arcturus and Vega, then Arcturus and Altair, both times the same error persisted. 

Initially I put the 24th in, and despite putting the 25th in, and realigning, then turning it off and on and realigning, it seemed nearly a day out. 

Hopefully next time it'll be ok again, just wanted to see if anyone had encountered this before.

[Shaun_Astro]

Another dreadful time trying to align tonight!

I set it at 06/08/17 23:23 UTC=0. When it was 07/08/17 UTC +1, which is correct.

Twice I aligned off of Altair, then it spun all the long way (240deg) via North to Hamal, instead of 130 deg East.

Then centered it on Hamal perfectly, and again it would align 2 degrees North of the target star, and wouldn't track accurately.

I did this THREE TIMES, and it ended up being aligned 2 degrees North every time. So I decided to align off of Hamal first, and then Altair (it went South and the short way), and It decided to align properly after that!

It took 30 mins to align when it could have taken me seven. There must be a pretty bad bug in the handset to cause this. I'm sure I've drained half of my new batteries with all of this slewing about.

 

[nightfisher]

Are you putting the date in using American format, in your post above you say 06.08.2017 but it should be 08.06.2017    just a thought

[nigelg]

Hello Shaun

I notice you are based in London, so you are close to the Meridian. Have you checked that you have the correct East/West settings.

If you have an Android phone or tablet, there is a free app called Synscaninit. This will display the settings you need to input in the correct order.

Hope this helps

Nigel

[BargeGazer]

+1 for the date format.

David

[Shaun_Astro]

Thanks for the replies, I think the date format has to be in MMDDYYYY, I recall it not working with DD MM YYYY, but I'll try that again. Also it ended up aligning well in the end, just with the stars in a different order.

[Shaun_Astro]

As a small note, I found that aligning from East to South, or South to West, in a clockwise motion works best, then the mount wont spin 270 degrees, and consequently the alignment will be much more accurate.

[m.tweedy]

On 07/08/2017 at 12:03, Shaun_Astro said:

Thanks for the replies, I think the date format has to be in MMDDYYYY, I recall it not working with DD MM YYYY, but I'll try that again. Also it ended up aligning well in the end, just with the stars in a different order.

If the date is 12 or under and you reverse the order it coud think it is the 8th June not 6th August for example. I always set it for UTC (not UTC+1) and either yes or no to daylight savings depending on the time of year. If you set it to UTC+1 and yes to daylight savings it will throw it out by an hour-assuming you are on daylight savings when you are observing.

PLEASE IGNORE IF RESOLVED AS I NOTE THE ORIGINAL PROBLEM WAS IN MAY