3833 replies to this topic

[sparrowhawk]

It appears from the work that @davidparks and others have posted if you're considering purchasing a Skywatcher Star Adventurer or iOptron SkyGuider series (or other similar light mount) for astroimaging the Skywatcher AZ-GTi should also be considered. 

 

Are there any functional advantages the SkyGuider or Star Adventurer brings for imaging versus the AZ-GTi? 

 

 

Kind regards,

 

Shawn

[cheesified]

Guys, sorry to sidetrack.. I've been thinking of getting this mount and using it in EQ mode. However does me being at lat + 1.22 degrees affect the function? (Can't see both NCP or SCP here).

[dciobota]

@Shawn, I have an ongoing "small mounts" topic where I compare various small mounts including the az-gti and skyguider pro:

https://www.cloudyni...-you/?p=8857406

 

In a nutshell, the skyguider pro's main advantage is tracking accuracy.  The PE of the skyguider pro is around 10 arcsec while the az-gti is around 26 arcsec (copies may vary of course).  Another advantage is a smaller form factor (if you don't include the skyguider pro's dec assembly and just use a ball head instead).  Other than that, the az-gti ticks more boxes.  Which is why I'm selling the skyguider pro tbh.

 

@cheesified, I'm wondering if Sharpcap polar alignment would maybe work for you, but you would have to be able to see within 5 deg of the NCP.  Other than that, PHD2 has a drift align tool which can definitely get you pretty close without having access to either NCP or SCP. The Sharpcap tool is easier to use, but drift alignment is not terribly hard, just a bit time consuming.  In either case you would have to have a camera to image with that is compatible.  If you just plan to use it for visual only, then using it in alt/az mode may actually be the better way to go.

 

Hope this helps.

[dciobota]

Here is my disassembly guide of AZ-gti in PDF format. You can download it as a reference guide. You can also print it (A4 format). Sorry about some mistakes i'll correct them when i have the time! All the photos is mine exept 2 from the second page that belongs to Daniel (dciobota) (sorry mate, if you have problem about that, just tell me and i'll correct it ASAP).

 

Please think twice before you proceed, because you will probably not manage to assemble it right and that VOIDS THE WARRANTY! YOU MUST ALWAYS ALWAYS ALWAYS TOOK PHOTOS OF YOUR STEPS! Good luck and PROCEED AT YOUR OWN RISK!

 

Download PDF HERE

Cheers Dimitris, many thanks for the writeup!  So, did you have a chance to test the new unit? 

[DIMITRIS K.]

Cheers Dimitris, many thanks for the writeup! So, did you have a chance to test the new unit?

Unfortunately the weather here does not permit yet! Tomorrow the sky will clear and I'll manage to test it!

Στάλθηκε από το Samsung Galaxy μου χρησιμοποιώντας Tapatalk

[dciobota]

So I'm having a weird issue tonight.  Did a goto to the western veil, coordinates RA 20h 45m 38s | Dec +30° 42′ 30″.  Plate solving showed ra only a couple mins off, dec about two deg off, at around 28 deg.  So I did a sync and then tried to go to the correct coordinates.  But the weird thing is that as I slewed in dec the dec coordinates increased until 30 deg then jumped to 36 deg.  No matter how slow I went and whichever way, the dec coords always went from 30 directly to 36 and vice versa.  It's like the encoder is messed up or something, but otherwise the dec values changed very smoothly.   Since I couldn't use plate solve, I ended up manually slewing to the correct dec plus 6 deg and it centered it correctly.

 

Very strange.  I'm going to contact Skywatcher support, but if anyone has suggestions or ideas I'm open.   Actually if anyone could try to slew to that coordinate and  see if your mount behaves the same or not, it would help a lot.

[DIMITRIS K.]

So I'm having a weird issue tonight.  Did a goto to the western veil, coordinates RA 20h 45m 38s | Dec +30° 42′ 30″.  Plate solving showed ra only a couple mins off, dec about two deg off, at around 28 deg.  So I did a sync and then tried to go to the correct coordinates.  But the weird thing is that as I slewed in dec the dec coordinates increased until 30 deg then jumped to 36 deg.  No matter how slow I went and whichever way, the dec coords always went from 30 directly to 36 and vice versa.  It's like the encoder is messed up or something, but otherwise the dec values changed very smoothly.   Since I couldn't use plate solve, I ended up manually slewing to the correct dec plus 6 deg and it centered it correctly.

 

Very strange.  I'm going to contact Skywatcher support, but if anyone has suggestions or ideas I'm open.   Actually if anyone could try to slew to that coordinate and  see if your mount behaves the same or not, it would help a lot.

Check your encoder wheels. Mine happened to have some grease on. 

[dciobota]

Interesting, I may just do that.  These are the encoders on the motor right?  

[DIMITRIS K.]

Interesting, I may just do that.  These are the encoders on the motor right?  

That's right!

Attached Thumbnails

• 
• 

[dciobota]

Oh I see, those are the encoders on the wheel!  I thought those were the secondary encoders, I thought the primary ones are on the motors.  It would be a black disk on the bottom left, just outside your picture.

 

Oh man, I'll have to completely disassemble the thing again.  Thanks Dimitris.

 

I'll see what Skywatcher says first.

[DIMITRIS K.]

Indeed those are the secondary. Just check them and those on motors too. You never know

[DIMITRIS K.]

Is you disassemble check also the decoder led emmiters. Sometimes they are not properly align each other (too far or too close to the wheel) and you have jump issues. I had this problem with my exos2 mount

[dciobota]

Oh man, ok.  To check leds, would I have to take the motor block apart?  I have the secondary encoders turned off so I'm not worried about those.  Probably will never use them.

[nm1213]

So I'm having a weird issue tonight.  Did a goto to the western veil, coordinates RA 20h 45m 38s | Dec +30° 42′ 30″.  Plate solving showed ra only a couple mins off, dec about two deg off, at around 28 deg.  So I did a sync and then tried to go to the correct coordinates.  But the weird thing is that as I slewed in dec the dec coordinates increased until 30 deg then jumped to 36 deg.  No matter how slow I went and whichever way, the dec coords always went from 30 directly to 36 and vice versa.  It's like the encoder is messed up or something, but otherwise the dec values changed very smoothly.   Since I couldn't use plate solve, I ended up manually slewing to the correct dec plus 6 deg and it centered it correctly.

 

Very strange.  I'm going to contact Skywatcher support, but if anyone has suggestions or ideas I'm open.   Actually if anyone could try to slew to that coordinate and  see if your mount behaves the same or not, it would help a lot.

Does this happen only after a sync?  If so then I’ve reported this already to synscan dev.  Their response is that this is normal.  

 

N. 

[dciobota]

Oh, now that you mention it, I did do a sync.

 

I'm not sure how they figure out it's normal for dec to jump 6 degrees.  That makes no sense.  It messes up my platesolving gotos for sure.  Maybe I'll try to see if I can do platesolves without the sync.

 

It also messes up regular gotos, because if you input a dec in that 6 degree 'gap' it will not slew correctly.  I'm really hoping they somehow fix this and not just shrug it off.

[DIMITRIS K.]

Oh man, ok. To check leds, would I have to take the motor block apart? I have the secondary encoders turned off so I'm not worried about those. Probably will never use them.

I think you can access them without dissmandle the motor. But it seems your answer to your problem is at the post above so keep my advice for future issues you may have!!

Στάλθηκε από το Samsung Galaxy μου χρησιμοποιώντας Tapatalk

[nm1213]

Check if it only happens after a sync. If so, then this was the explanation I was given:

Base on the algorithm of the Sync operation in the SynScan app, what you observed is normal when the mount slews crossing the boundary of the Sync area. With a good 2-Star or 3-Star alignment, the changes should not be huge, it might be between several arc-minutes to 30 arc-minutes.

[dciobota]

I see, and I think I understand the reasoning somewhat.  Unfortunately it causes issues with gotos near the boundary.  But you're absolutley right, it was the sync command. Tonight I avoided syncing and the plate solving worked again perfectly.

 

So the moral of the story, at least for me, is to avoid syncs and just use plate solving.  No alignment necessary actually, if the initial mount dec and ra alignments are good enough.

[DIMITRIS K.]

Finally a fully working mount!! I made some quick tests last night. Tracking is way better than the old one. My test objects was Pleiades and Andromeda galaxy.

 

Some issues i had encounter with my old and also with this mount:

 

1. Sometimes, when go-to complete, i have a lot of drift and i need to press a directional button instantly to make the tracking work at it's best! 

2. Sometimes (rare), during tracking, it makes some tracking jumps and i have star trails.  

3. With two star aligment go-to is a little off-target and i must center manually.

 

I made a 3min stacking with Sharpcap with good results. OK stacking artifacts was there, but, compared with a same stacking made with my old mount,  it is clear that tracking now is way better.

[nm1213]

I see, and I think I understand the reasoning somewhat.  Unfortunately it causes issues with gotos near the boundary.  But you're absolutley right, it was the sync command. Tonight I avoided syncing and the plate solving worked again perfectly.

 

So the moral of the story, at least for me, is to avoid syncs and just use plate solving.  No alignment necessary actually, if the initial mount dec and ra alignments are good enough.

I don't understand what you mean by solving but not syncing.  Yes, the solve will tell you where you are pointing, but a sync is then required to tell "copy/paste" the co-ordinates to the mount.  

 

What I'd love to do is to do a north level alignment, accept the stars without checking, and establishing a rough alignment model.  Then, rely on a blind solve/sync to fine tune goto.  Synscan isn't there yet.  Syncs have to be close enough or they're ignored.  Also, we have some strange behaviours after sync like what you found.  What you haven't noticed yet is that the co-ordinates go all wonky after a sync and a random amount of time has passed.  The mount will accept the sync, but then it forgets it after some time. 

[dciobota]

Well, I could be wrong, but I "think" APT doesn't require to sync.  As a matter of fact, once I plate solve and click on goto++ it asks me if I want to sync the mount first, and I said no last night.  That's what made it work.  I assumed that if you give it target coordinates and not sync the mount before using goto++, it platesolves, calculates the difference in coordinates, slews to the new calculated coordinates, takes a shot again, platesolves, recalculates, etc.  It is possible to do iterative relative gotos with platesolves without syncing the mount.  All the code has to do is keep track of the difference between platesolved coordinates and mount reported coordinates.  The other night, when platesolving was failing, I did exactly that.

 

But, it's possible that when APT does iterative plate solves and gotos it does sync after all.  The reason why I think that is that I tried to platesolve to another target later last night (about 3 hours later, on the other side of the meridian), and the ra and dec values started acting funky again (with those gaps).  So, I eventually had to stop and restart the mount as well as the synscan app.  I don't know which one was causing issues, but the restart worked.

 

I too would love to just turn on the mount level aligned to the NCP, with the mount having a default alignment (basically what you described, but without the need to confirm where the mount points to the alignment stars).  That should get me close enough to the target (and it usually does).  The only issue I see is with sync and behaviors related to that.  I truly wish they fix that soon.

 

Dimitris, congrats!  Sounds like you are back in business.   Funny you mention those RA spikes, last night I noticed something similar when guiding.  I wonder if the RA gear needs to be cleaned, just like the DEC one.  As I mentioned, I did find some shavings on the DEC gear.  That's pretty unacceptable imo.

Edited by dciobota, 18 October 2018 - 11:49 AM.

[DIMITRIS K.]

After inspection I've noticed that my mount had lot of backlash. When I remove the cover I've found the problem. The screw that holds the tension spring was loose. Maybe that was the broblem with the jump. Will see. I think skywatcher must have quality control issues lately!

Στάλθηκε από το Samsung Galaxy μου χρησιμοποιώντας Tapatalk

[dciobota]

Oh, good find Dimitris.  I wonder if I should be looking at my RA motor block again too.

 

Yeah, so far, their quality control doesn't seem the best for this mount.  Hopefully they will improve with time.

[nm1213]

Well, I could be wrong, but I "think" APT doesn't require to sync.  As a matter of fact, once I plate solve and click on goto++ it asks me if I want to sync the mount first, and I said no last night.  That's what made it work.  I assumed that if you give it target coordinates and not sync the mount before using goto++, it platesolves, calculates the difference in coordinates, slews to the new calculated coordinates, takes a shot again, platesolves, recalculates, etc.  It is possible to do iterative relative gotos with platesolves without syncing the mount.  All the code has to do is keep track of the difference between platesolved coordinates and mount reported coordinates.  The other night, when platesolving was failing, I did exactly that.

 

But, it's possible that when APT does iterative plate solves and gotos it does sync after all.  The reason why I think that is that I tried to platesolve to another target later last night (about 3 hours later, on the other side of the meridian), and the ra and dec values started acting funky again (with those gaps).  So, I eventually had to stop and restart the mount as well as the synscan app.  I don't know which one was causing issues, but the restart worked.

 

I too would love to just turn on the mount level aligned to the NCP, with the mount having a default alignment (basically what you described, but without the need to confirm where the mount points to the alignment stars).  That should get me close enough to the target (and it usually does).  The only issue I see is with sync and behaviors related to that.  I truly wish they fix that soon.

 

Dimitris, congrats!  Sounds like you are back in business.   Funny you mention those RA spikes, last night I noticed something similar when guiding.  I wonder if the RA gear needs to be cleaned, just like the DEC one.  As I mentioned, I did find some shavings on the DEC gear.  That's pretty unacceptable imo.

Interesting that APT is able to plate solve and then not sync, yet correct the mount and move it to the right place.  I need to investigate this further... solves our problem if this is indeed possible.

[dciobota]

Well, that was my thinking, but the mount going nuts last night might have proved me wrong.  Maybe the goto++ function did do that after all.  Maybe it executed a sync at the very end.

 

Well, no chance to try again tonight, it's clouded over.  Maybe I get lucky tomorrow night.