search

indilib / indi

INDI Core Library Repository
https://www.indilib.org
GNU Lesser General Public License v2.1
377 stars 393 forks source link

Improve AZ-GTi tracking #1646

Closed knro closed 7 months ago

knro commented 2 years ago

AZ-GTi mount in Alt-Az configuration uses SkyWatcher Alt-Az driver. As reported by a couple of users, tracking in Alt-Az is inferior when compared to tracking achieved by using the Synscan app. Images captured show trailing stars, even as short as 5 or 10 seconds.

The tracking is performed in TimerHit function. Currently, the algorithm works as following for Sidereal tracking:

The same algorithm is applicable to the altitude axis. Possible causes for the bad tracking performance:

There might be other reasons beside these. It would be appreciated if someone can help with improving the tracking performance. Perhaps this cold be generalized to an INDI core function to be used for other Alt-Az encoder mounts as well.

federicoparra commented 2 years ago

Hi Jasem, thank you for opening this case. Among the hypothetical causes you mention, I would like to test tonight the hypothesis that the driver needs a higher "refresh rate" of 10Htz. How can I test this?

federicoparra commented 2 years ago

Also, a newby question: do you think we can ask SkyWatcher to share with us at least the pseudo code of synscan's tracking function? It works amazingly well.

knro commented 2 years ago

You can change the POLL period in Options to 100ms down from 1000ms. I don't think this would work well actually, and would probably make things worse, but I could be wrong.

federicoparra commented 2 years ago

Awesome. So that I can easily change from the menu - any other thing you would suggest for me to try? Actually there are many options in the different menus of the driver that I don't know what they do - I could try many tonight, systematically, if you tell me which ones to try.

badryan commented 2 years ago

Not sure this observation is helpful as I’m still having to reproduce the issue: When I’m using Stellarmate on a Raspberry Pi and have the Skywatcher AZ GTI join the Stellarmate WiFi, I seem to get okay tracking results. However, when running Ekos on a Mac, and join the SynScan WiFi, tracking is poor with trails even after a few seconds of exposure. Will try to confirm.

federicoparra commented 2 years ago

Hi @badryan I tried both ways and in both cases tracking is bad - even 2 seconds of exposure gives you trails even after successfully plate-solving 6 times on a small region on the sky and staying there with the tracking.

My understanding is that the driver is doing something quite different to what the SkyWatcher driver (in SynScan) is doing.

It would be great to have their code. In your experience @knro do you think SkyWatcher would accept a request to open source just the tracking loop of their code or to provide pseudo-code if they knew it was to build an INDI driver?

badryan commented 2 years ago

Hi @federicoparra! Thanks for confirming the issue on both the SynScan and Stellarmate WiFis. Interestingly enough, when I first started using the mount with Stellarmate in February, it was relatively well-behaved for a few sessions. However, 'something' happened in the meantime and now I'm only getting star trails. Hence, I'm not quite convinced yet that the tracking code in Ekos is broken for the AZ-GTi. One thing I observed though with verbose logging in the Alignment module is that I get 'Sync failed' after successful plate solving. For me this hints that the mount doesn't know where it's looking and therefore tracks erroneously. @knro / @federicoparra - any idea how to test this hypothesis?

knro commented 2 years ago

Plate-solving failure is another issue. I'm still not entirely sure what could be the issue. Need another developer to take a stab at this.

badryan commented 2 years ago

Plate-solving failure is another issue. I'm still not entirely sure what could be the issue. Need another developer to take a stab at this.

Thanks for the quick reply. Just to confirm: The plate solving runs successful and delivers valid coordinates, but I'm getting the 'Sync failed' which -to me- hints to an interaction with the mount, no?

knro commented 2 years ago

I tested now for more than 30 mins and I can only detect very small deviations. This is unguided 30-sec exposures via AZ-GTi WiFi Alt-Az with SVBony 70mm 503 refractor + Canon 600D. image

badryan commented 2 years ago

My mount keeps misbehaving, with no clear pattern. It 'simply worked' a few times like in your example, I've had objects disappear out of sight with a similar setup to yours within 5min or so, and I've had star trails already occurring in 10 sec exposures. It's frustrating.

I don't want to exclude user error; but -in theory- I'd expect the system to function properly, knowing local time and location, after the first plate-solve.

ukuehn commented 2 years ago

Hi, I'd like to add an observation which might be related to this issue, and could (hopefully) help to understand the issue:

I am using Astroberry server (2.0.4) and get with the original image (using the contained version 1.9.2 of indi-bin and libindi1 package) quite usable stars with 30 sec exposures using a Mak127 (1500 mm focal length). With 30 sec field rotation is barely noticable.

However, after updating the packages to version 1.9.4 or 1.9.5 I get consistently star trails. East of meridian the look like "\", west of meridian like "/". Just tried the old vs. new versions on Procyon this evening (in case it's relevant: Lat 50 deg N, Az 240, Alt 30). Old version (1.9.2) is fine, version 1.9.5 gives trails which are about 20 to 25 arcsec long with 30 sec exposures. Objects are drifting quite quickly downwards and to the side (towards meridian), e.g. when making repeated exposures.

Maybe something relevant did change between those versions? Happy to help testing / troubleshooting.

In any case thanks for making INDI, it's a very cool tool!

edit: I should add: I am using a serial cable to control the AZ GTi in Alt Az config, in case this is relevant.

ukuehn commented 2 years ago

Hi, I did some more testing with different versions 1.9.2, 1.9.3, 1.9.5 and found that I had star trails all over the place. However, after turning to a different part of the gears (pointing somewhere, unlocking the clutches and turning back the telescope to home position manually), and switching to v1.9.6 with tracking factor 0.9 I got now two nights with consistently good tracking. The stars are round or only slightly egg-shaped with 30 sec unguided exposures. This is among the best tracking I have so far seen with this mount. There is only very little drift over time, sometimes going back and forth (plus the field rotation expected for alt-az tracking).

My current working hypothesis is that the tracking algorithms seems pretty fine, and that some issues might be related to the mechanics. Will need to investigate this further.

federicoparra commented 2 years ago

Hi @knro, I don't know why you closed this - I had only a chance to try this today and yesterday and is still as hit and miss as it ever wass. When the Az-GTI is tracking, it does, randomly at times, start going somewhere else. It can be somewhere nearby, it can go and then come back, or sometimes it just starts turning all around dangerously and can hit something. The mount works perfectly well with its own app and with the other driver in Eq so the problem is this driver. I really want this to work, I'm ready to pay for this, the other day someone showed me a Celestina automatic scope, in 10 minutes it was set up and we were getting wonderful plate-solved images of deep space nebulae from the center of Paris with all the lights and all. On the other hand it's been 2 years and I still have not, not even ONCE, enjoyed using Stellarmate hassle free with my Alt-Az mount. Please, the alt-gti is maybe the most popular mount in existance. Stellarmate must work well with it! let's make this happen please. I can pay you for the work.

ckuethe commented 2 years ago

One thing I've noticed is my AZ-GTi is very sensitive to time/location. Occasionally I get unlucky with my GPS producing garbage fixes and then my AZ-GTi takes off into hell's half-acre as the saying goes.

Thanks for mentioning this though; I've been meaning to experiment with different alignment plugins, since sometimes my mount converges in 3 or 4 iterations and other times it takes more than a dozen tries while it hunts around 12-21" from target.

ckuethe commented 2 years ago

I'll pull logs in the morning, but here's my Az-GTi refusing to align until after I manually cleared the mount model.

Screenshot_20220829-234001

federicoparra commented 2 years ago

@ckuethe I wish this was related to GPS, but it's not - when I run Stellarmate entirely from my PC (and so there is no GPS), it still does these chaotic crazy movements out of nowhere. Also, I did clear the mount model and that did not fix the issue.

knro commented 2 years ago

I posted a response to @federicoparra StellarMate ticket that I think it well worth sharing here as well:

Hello Federico,

Thank you for the update. Let me clarify some points:

  1. Always select the default 3rd Math plugin (Nearest) in alignment configuration in the driver. The first two don't appear to work very well with AZ-GTi.

  2. Alignment (Plate-solving) and Tracking are COMPLETELY UNRELATED. You can have perfect GOTOs with object right in the center, but the TRACKING can be terrible and vice-versa. The platesolving is to improve the GOTO accuracy ONLY, and has absolutely nothing to do with tracking.

Once the mount arrives at some point in the sky, assuming that object is a star.. nebulae.. then the mount needs to be MOVE at sidereal rate to keep it in the same place. For Equatorial mounts, that usually involves moving one-axis (the RA) while keeping the DEC off. However, for Alt-Az mounts, you need to move BOTH Az and Alt axis in a stair-like steps always to keep the object in the center. Its performance to equatorial mount is sub-optimal at best this is why it's not usually used for astrophotography.

Now for AZ-GTi, the tracking might be good enough. The tracking code was written originally by Roger Games and then I improved on it later. You can check the driver tracking code and see that it tries to do the following:

  1. Convert tracking target RA/DE to ALT/AZ coordinates.

  2. Apply guide pulses (if any)

  3. Calculate offset in AZ/ALT in order to move from CURRENT AZ-ALT to the NEW AZ-ALT. This is done each second (like 1045)

  4. At line 1057, if there is Azimuth offset, it tries to move the scope by the necessary steps to compensate for the drift.

  5. At line 1096, same as above for Alt offset.

  6. I added a compensation factor called Track Factor, this is set to 1 by default (so essentially has no effect as you can see in like 1113). By changing this, you can adjust the compensation made for each axis ... i.e. if you make AZ factor = 1.5, then the correction would be 1.5 times more. If for example, you noticed it was going too fast in ALT, try decreasing that value below 1 and see. It's a delicate balance that can be achieved by trial and error.

If you know any better method of doing all the above, please propose one. We cannot be compared to Cellestina, we have support for dozens of mounts. If StellarMate was produced for a SINGLE mount that we own and manufacture, then yes, we can be compared. The fact is StellarMate supports dozens of devices and the drivers are developed by the community not the manufacturer so such issues are to be expected in such a heterogeneous system.

federicoparra commented 2 years ago

Dear @knro, a few things:

First, both the eVscope and the Stellina use AltAz mounts and achieve perfect tracking of deep space objects - as I mentioned Stellina can plate solve to find where it is, auto align, and get a first (good) picture of a nebulae sitting right in the middle of Paris with max light pollution, all of that in about 5 minutes.

What I'm trying to say there is that Alt-Az is perfectly fit for deep space exploration. I'm attaching a pic I took using AzGTI with it's own app and using AltAz, so you can see what I mean.

image

Now with regards to the problems I'm reporting: this can't have nothing to do with the code you are mentioning. I am not discussing drifts. I'm telling you the mount will start turning 360 circles out of nowhere and it's caused by this driver. It doesn't do that if using the Eq driver, it doesn't if using the Synscan app - so it's this driver causing it. Other times it will start going to another place without having touched anything, or drift by 25 cm so it's pointing at a fully different thing.

This is unrelated, I know, to the new problems I mentioned in my last help request, related to plate solving.

As I mentioned a number of times now, I can pay to get this done. I say this because I'm well aware you support a large numbers of mounts (although I insist, none of them comes even close in popularity to the AZgti because of its price and quality-to-price ratio). I'm not expecting you to fix this for free, you probably have a million things to do. But I am expecting for you to contact me in private with a quote so that I can help you financially to work this out.

I do not have the skills to do this unfortunately.

knro commented 2 years ago

You can adjust the tracking factors like what @ukuehn experimented with and see if improves the situation. I actually do not know what the problem is, so I can't fix something of which I have no idea idea what is the root cause behind it. I will test tonight with AZ-GTi + Nikon setup in my observatory and see if I can get any odd behaviors.

federicoparra commented 2 years ago

@knro I think what ideally needs to happen is that Stellarmate needs to include an AltAz mode that deals with the conversion, so that the drivers for AltAz mounts only need to deal with pulses etc. I think supporting AltAz is essential to compete with commercial options such as Stellina and eVscope that are based on AltAz and allow for a very lean package one can take in a back pack and still do deep space photo. Also, if you build a builtin AltAz support for the whole Stellarmate then there will be potentially many mounts concerned and then code will be improved more rapidly due to the increase in interest. What do people think ?

federicoparra commented 2 years ago

I'll add the advantage of AltAz is that you don't need polar alignment. Stellina, the guy took out of the bag put in floor, touched on the app on his phone, the telescope turned on, took 2-3 pictures of the sky and platesolved them, took GPS info, and was ready to go. I can do the same with Synscan but I can't platesolve with it so it's a manual task that is painful. I think AltAz + platesolving is a very elegant solution and for mounts that are able of tracking accurately with AltAz such as AZGTI it's a pleasure to use because no need to carry heavy equipment.

ukuehn commented 2 years ago

Let me contribute some more experience with the driver and the mount:

Here is another related question on the statement about independence of tracking and alignment: I somehow was under the impression that the alignment points were actually used in goto and tracking, in particular for compensating for any initial misalignment of the vertical axis and the home position. How else is that compensated if not from the alignments? Maybe I need to dig a bit deeper into the theory and the code...

I hope these observations help.

knro commented 2 years ago

This a 60-second unguide exposure taken with AZ-GTi + Nikon D3500.

60_secs

You can notice some trailing star issues in the 60 seconds image, but only very slightly. For 30 seconds unguided, everything is pin-pointed. This is all using the default settings. Maybe I just have a large FOV with my Nikon D3500 and therefore tracking issues are not as prominent when having a large FOV.

I already explained how tracking works in the driver. To summarize it:

  1. GOTO to a target. Target RA/DE are now saved.
  2. Each second, convert target RA/DE to target AZ/ALT
  3. Compare those to current AZ/ALT and calculate offsets.
  4. Move mounts by the offsets.
  5. Repeat

For the Celestron AUX driver, I developed a PID controller for tracking. For AZ-GTi it's just using simple proportional gain that is set by default to 1 and it modifiable by the user. Perhaps a more robust mount tracking code needs to be developed? Not sure, I'm not exactly an expert on the subject matter.

federicoparra commented 2 years ago

I know this is unrelated but as I'm trying to get plate solving to work I'm annoyed that dark frames do not work in the alignment module. The exact same configuration for which a dark frame will work perfectly in the capture module says there are not available dark frames when used in the alignment module :(

federicoparra commented 2 years ago

Coming back to our issue here - I'm checking and I'm realizing what triggers the merry-go-round crazy thing is when there is a successful plate solving even if it's just set to synch. In theory, that should update coordinates and there should be no movement at all of the telescope, but here it just goes to do a dangerous 360 degree almost movement, with errors saying it can't stop the mount motor and me having to stop it manually. Just to try once I did not stop it, it eventually stopped somewhere, but then, on its own, started doing another merry-go-round somewhere else. So updating coordinates is what sends the driver bananas.

ckuethe commented 2 years ago

@federicoparra I cannot reproduce that. I just tested plate solve and sync:

And over in another window, stellarium's display of my mount location updated itself.

Firmware code 0326 according to the INDI panel,AZGTi_motor_controller_firmware_right_arm_0338.MCF

mwillis87 commented 2 years ago

Before I begin, let me state my relevant hardware:

AZ-GTi mount w/ original tripod SVBONY SV503 80mm ASI178MC (uncooled) 14-bit camera FOV w/setup 59.1' x 39.7' Focal Length w/setup: 431.7 f/ w/ setup: 5.4

I can confirm the issue that @federicoparra is having (let's call this the "dance of death") as well as the tracking issue which started this thread. I am not sure why the issue was closed, since this is a popular mount for beginner due to the price range.

Dance of Death Issue For the first issue, I can usually reproduce the issue after the following steps:

  1. Level the mount using the bubble indicators on the tripod.
  2. Point the mount in the north direction parallel with the tripod surface plane.
  3. Power up the raspberry pi with kstars (version 3.60)/ekos.
  4. Power up the tripod (batteries or power pack)
  5. Connect devices remotely via kstars on laptop.
  6. Turn on tracking via mount control panel within ekos.
  7. Sync the telescope to a star or object in the north direction (close to where I believe the telescope is pointing).

At this point, the telescope would begin the "dance of death", and I manually turned the mount off at the toggle switch before equipment damage could occur. To work around the issue, I reversed steps 6 & 7 and then perform the plate solving routine. There must be some logic issues between the sync command and the tracking command in this particular sequence of steps.

Tracking Issue

@Knro, your 60-second unguided exposure taken with AZ-GTi + Nikon D3500 is interesting. Your FOV is large, and therefore the effect is not as pronounced as mine more than likely. I would be interested in seeing the deviation after you have plate-solved centering the target, and plate-solving with the "nothing" radio button after 60 seconds to see what your deviation is. Personally, I have spent many hours playing with various tracking factors as well as polling times, and the tracking just isn't working. I've attached a visual of the tracking with 10 second exposures (t+10s, t+20s, t+30s, t+40s, and t+130s.) - you'll need to download the photos to really see the movement of the stars.

Plate Solving Issue

I can typically plate-solve on the first or second attempt on a "fresh connection" and cleared alignment model, however the tracking messes up the alignment within a few minutes of the the plate-solving/alignment routine. Once this happens, I attempt to plate-solve again, and it will plate-solve extremely close to the target deviation and will eventually go the other way (high deviation) ultimately unable to plate-solve. At this point, I clear the model and disconnect all the devices, re-connect the devices, and it plate-solves typically on the first attempt. I intend on re-visiting the plate-solving issue to assist with troubleshooting, but I think it would behoove us to focus on the tracking issue first as it seems to be the culprit to two other issues.

t+10s: t+10secs

t+20s: t+20secs

t+30s: t+30 secs

t+40s: t+40secs

t+130s: t+130secs

knro commented 2 years ago

Thank you for the report @mwillis87

I already explained how tracking is performed in the driver above. In the code, here is the Azimuth tracking code and you can see it tries to figure out AzimuthRate first, then sets the clock ticks per microstep accordingly. The only external factor is the user-configurable Tracking Factory (default 1).

Let's forget about mount model for a second and just concentrate on tracking. Factors that could lead to inaccurate tracking:

  1. Wrong time/location that would result in inaccurate RA/DE conversion to AZ/ALT coordinates.
  2. Inaccurate Azimuth & Altitude rate calculation from stepper clock frequency and delta microsteps.

System might also benefit by introducing hysteresis to prevent unnecessary changes, but I actually don't see where this is happening.

mwillis87 commented 2 years ago

No problem, @knro. I appreciate your work and maintenance of these libraries. It's impressive work. I apologize in the delay to your response. It's been a busy last few days of working on projects around the house.

I intend on taking a closer look at the code in terms of logic (my background is FORTRAN and VB --> I'll need to do some homework on syntax), however I did some more testing based on your comment on the two possible factors which could lead to inaccurate tracking. The geographic location I had saved was ~14.6 miles from where my actual GPS coordinate were, so I updated accordingly and ensured it displayed correctly in the indi control panel. One thing I observed is if you press "CTRL+G" in Kstars, the UTC offset for Chattanooga, TN is shown as "-5", but in the indi control panel it shows "-4". Maybe a daylight savings time check is needed for the geographic location setup? I did notice a slight improvement in the tracking testing discussed below (i.e. it took a longer time for the object to leave the FOV).

During my testing, I focused mainly on your first factor suggested factor that could lead to the inaccurate tracking. My testing consisted of centering and tracking an object after doing a quick platesolve. I then used the "nothing" "radio" button in the plate-solving tab to take 1-second exposures to watch the error. I initially did this with a tracking factor of "1" for both azimuth and altitude. The error varied between 10-30 units (I think the "unit" is arcsecond?) after each exposure; that is, 10-30 units additional to the previous error recorded. I varied the tracking factor up to 2 for both azimuth and altitude, and saw no difference in the error data, 10-30 error units difference between each successive exposure. Visually, I also saw no difference in the tracking rate on the image obtained. I turned off tracking at this point to see if tracking was working at all. Tracking was in fact working as it took only two exposures for the object to leave the FOV. At this point, I went the other direction with the tracking factor starting at 0.85 back to 1.0 with both the altitude and the azimuth, but I saw no difference in the error data. In my last test, I dropped the tracking factor to 0.1 for both the azimuth and altitude, and this point the "Dance of Death" began, and I stopped the mount and called it a night. I didn't have verbose logging turned on, so I've turned it on for the next testing session to see if any additional information can be obtained. Currently, it seems that the tracking factor isn't being changed. I intend on testing further and will provide more information as I progress.

mwillis87 commented 2 years ago

Spent several nights and hours testing over the past week:

Snap Package (Manjaro): I had downloaded Kstars from the snap package repository a while back. After testing for two nights, I thought it might have been defective, but it occurred on the official repository for Arch Linux as well. I noticed that changing the polling time made the largest difference to the tracking, however any polling time>1000 ms will cause the mount to swivel between two points repeatedly until finally going into the dance of death after a minute or so. I also found any tracking factor less than ~0.65 causes the mount to have the same behavior. I saw no improvements using the tracking factor.

Arch (official repository): As mentioned, I downloaded the latest version of Kstars for Archlinux and uninstalled the snap package. Same story with the tracking factor and polling time. I booted into windows 10 and downloded Kstars v3.6.1.

Windows 10: The issue were the same as the ones experienced on the Linux distributions.

For all cases, the best exposure without star trails was ~10 seconds. I don't have a field rotator nor an ALT-AZ to equatorial conversion adapter, but I would expect I should have been able to get around 30 seconds of exposure without noticeable field rotation.

I searched the code you sent @knro but did not see where the polling time was being used except for the guide pulses portion of the code. I am not using guiding features. Could you point me to where the polling time (POLLMS) is being used, and how it relates to or could interact unknowingly with tracking?

Thanks!

knro commented 2 years ago

@mwillis87 Thank you for the update. The default polling period is 1 second. It can be configured in the driver Options tab.

mwillis87 commented 2 years ago

Thanks, @knro. I now understand what the polling time does.

Kstars V3.6.1 (windows) has been giving me some issues outside of tracking. The software picked up quite a bit of lag it seems since V3.6.0, however I was able to pull some log files last night while the mount was supposedly tracking (it wasn't, I turned off tracking and there was no difference in how fast the stars were moving through the FOV). I noticed several error codes. I put a few lines of the log files below for reference. Could you point me to where the error codes are defined? On line 1132 of the code you sent earlier and, in the syntax, "error %d", where is a list of error codes for "d"?

Is there a repository for the older versions of Kstars? I was going to switch back to v3.6.0 to try and avoid the lag/software randomly closing.

[2022-10-14T22:36:15.299 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:15.361 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] RES <311> " [2022-10-14T22:36:15.361 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:15.377 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] RES <111> " [2022-10-14T22:36:15.377 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:15.377 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] RES " [2022-10-14T22:36:15.377 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] RES " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] Axis1 encoder 8386007 (Zero 8388608) -> AZ 359.548437° " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] Axis2 encoder 8590543 (Zero 8388608) -> AL 35.058160° " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] TDV x 0.818544 y 0.006451 z 0.574408 " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] Sky RA 3:42:07 DE 57:53:30 " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] TDV x 0.818548 y 0.006445 z 0.574402 " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking AXIS1 CurrentEncoder 8386007 OldTrackingTarget 8386009 AXIS2 CurrentEncoder 8590543 OldTrackingTarget 8590541 " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] New Tracking Target AZ 359.548872° (2071001 microsteps) AL 35.057790° (201932 microsteps) " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] New Tracking Target AZOffset -3 microsteps ALOffset 2073602 microsteps. " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking -> AXIS1 direction change. " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking -> AXIS2 direction change. " [2022-10-14T22:36:15.392 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:15.408 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking -> AXIS1 error 2 AXIS2 error -2. " [2022-10-14T22:36:20.377 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.408 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] RES <101> " [2022-10-14T22:36:20.424 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.439 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] RES <101> " [2022-10-14T22:36:20.439 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.439 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] RES " [2022-10-14T22:36:20.455 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.455 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] RES " [2022-10-14T22:36:20.471 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] Axis1 encoder 8386007 (Zero 8388608) -> AZ 359.548437° " [2022-10-14T22:36:20.471 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] Axis2 encoder 8590543 (Zero 8388608) -> AL 35.058160° " [2022-10-14T22:36:20.486 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] TDV x 0.818544 y 0.006451 z 0.574408 " [2022-10-14T22:36:20.486 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] Sky RA 3:42:12 DE 57:53:30 " [2022-10-14T22:36:20.502 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] TDV x 0.818549 y 0.006444 z 0.574400 " [2022-10-14T22:36:20.502 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking AXIS1 CurrentEncoder 8386007 OldTrackingTarget 8386009 AXIS2 CurrentEncoder 8590543 OldTrackingTarget 8590540 " [2022-10-14T22:36:20.517 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] New Tracking Target AZ 359.548939° (2071001 microsteps) AL 35.057654° (201932 microsteps) " [2022-10-14T22:36:20.517 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] New Tracking Target AZOffset -3 microsteps ALOffset 2073602 microsteps. " [2022-10-14T22:36:20.533 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.533 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking -> AXIS1 restart. " [2022-10-14T22:36:20.549 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.549 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.564 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking -> AXIS1 offset 2 microsteps rate 24000000 direction 0 " [2022-10-14T22:36:20.564 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.580 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking -> AXIS2 restart. " [2022-10-14T22:36:20.580 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.596 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] CMD " [2022-10-14T22:36:20.611 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking -> AXIS2 offset -3 microsteps rate 15999999 direction 1 " [2022-10-14T22:36:20.611 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking -> AXIS1 error 2 AXIS2 error -3. " [2022-10-14T22:36:25.314 Eastern Daylight Time DEBG ][ org.kde.kstars.ekos] - Disconnecting "AZ-GTi Alt-Az WiFi" [2022-10-14T22:36:25.330 Eastern Daylight Time DEBG ][ org.kde.kstars.ekos] - Disconnecting "ASI EAF" [2022-10-14T22:36:25.330 Eastern Daylight Time DEBG ][ org.kde.kstars.ekos] - Disconnecting "ZWO CCD ASI178MC" [2022-10-14T22:36:25.346 Eastern Daylight Time INFO ][ org.kde.kstars.ekos] - "Disconnecting INDI devices..." [2022-10-14T22:36:25.361 Eastern Daylight Time INFO ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[INFO] AZ-GTi Alt-Az WiFi is offline. " [2022-10-14T22:36:25.377 Eastern Daylight Time DEBG ][ org.kde.kstars.ekos] - "AZ-GTi Alt-Az WiFi" is disconnected. [2022-10-14T22:36:25.377 Eastern Daylight Time INFO ][ org.kde.kstars.ekos] - "AZ-GTi Alt-Az WiFi is disconnected." [2022-10-14T22:36:25.424 Eastern Daylight Time INFO ][ org.kde.kstars.indi] - ZWO CCD ASI178MC : "[INFO] Saving device configuration... " [2022-10-14T22:36:25.424 Eastern Daylight Time INFO ][ org.kde.kstars.indi] - ZWO CCD ASI178MC : "[INFO] Device configuration saved. " [2022-10-14T22:36:25.439 Eastern Daylight Time INFO ][ org.kde.kstars.indi] - ZWO CCD ASI178MC : "[INFO] Camera is offline. " [2022-10-14T22:36:25.439 Eastern Daylight Time DEBG ][ org.kde.kstars.ekos] - "ZWO CCD ASI178MC" is disconnected. [2022-10-14T22:36:25.455 Eastern Daylight Time INFO ][ org.kde.kstars.ekos] - "ZWO CCD ASI178MC is disconnected." [2022-10-14T22:36:25.471 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - INDI server disconnected from BLOB manager for Device: "ZWO CCD ASI178MC" Property: "CCD1" Exit code: 0 [2022-10-14T22:36:25.486 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[ALIGNMENT] TDV x 0.818550 y 0.006443 z 0.574399 " [2022-10-14T22:36:25.486 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] Tracking AXIS1 CurrentEncoder 8386007 OldTrackingTarget 8386009 AXIS2 CurrentEncoder 8590543 OldTrackingTarget 8590540 " [2022-10-14T22:36:25.502 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] New Tracking Target AZ 359.549007° (2071002 microsteps) AL 35.057520° (201931 microsteps) " [2022-10-14T22:36:25.502 Eastern Daylight Time DEBG ][ org.kde.kstars.indi] - AZ-GTi Alt-Az WiFi : "[SCOPE] New Tracking Target AZOffset -4 microsteps ALOffset 2073603 microsteps. " "

knro commented 2 years ago

There are not error codes. It's the difference in encoder counts between current encoders and the tracking target.

ukuehn commented 2 years ago

@mwillis87 regarding your tracking issue l notice that you essentially use only one or two plate solving steps.

What I write below is based on my experience, some reading of how the driver and the alignment works. Should I have misunderstood something, please correct me.

As far as I understand the driver uses all sync points to build a pointing model which is used for all transformation between celestial and telescope coordinates (which is also used during tracking to determine where the telescope should be pointing to, and then to drive it there). The number of available sync points determines how the transformation is done. If there are more then three such points the driver / alignment subsystem computes a convex hull (triangulation of the sky based on the sync points) and does the coordinate transformation based on the corners (sync points) of the triangle in the sky the telescope is currently pointing into.

I read somewhere (could not find it anymore) that the zero position (pointing north and level) is used an implicit first sync point. Consequently any error in this position will have an impact on tracking, as long as this point is included in the concrete coordinate translation. So, my setup procedure is to point north and level as good as I can (usually about 1 or 2 degree off, since I cannot see Polaris), and then cover the area in the sky where I will take exposures during the session with some sync points, making sure to have some north and south as well as east and west. This way the triangles the mount tracks through have corners with measured = plate solved correct coordinates, avoiding any possible alignment error of the initial position.

What I normally observe during this setup procedure is that whenever the telescope enters an area where the north/level implicit sync point may have an influence I see star trailing even with rather short (3 sec) exposures. This appears to be consistent with what you observe with only 2 sync points (plate solved positions) in addition to the implicit start point.

Maybe you can give this a try and see if it improves your tracking. With the described procedure I see only the inaccuracies from the mechanics of the mount, such as the periodic error in the worm drives.

mwillis87 commented 1 year ago

Thanks for the suggestion, @ukuehn! I attempted it three nights in a row, however saw no difference. I believe this is because, as @knro mentioned, the telescope direction vector (TDV) isn't used for tracking, but alignment purposes, and therefore the alignment module has no impact on tracking. With that being said, it is very difficult to obtain alignment when the tracking is not working. (you can do it, but it takes a while as the stars are moving out of the frame before the computer has time to solve the second image received. In addition, in about 2 minutes your mount model will be wrong again as your tracking is off). For tracking, the code pulls the angle from the telescope and uses a degreetomicrostep function to get the current position in microsteps, the future target in microsteps, and the zero encoder position in microsteps. With this, it calculates the offset, and sets the clocktickspermicrostep to meet the calculated offset at a specific time.

On the log I submitted above, on October 15th, 2022, you'll notice the altitude offset calculated between the new target and the old tracking target is really large repeatedly and didn't change until I restarted the mount. This tells me either the offset is calculated incorrectly (doesn't appear to be), the clocktickspermicrostep is not calculating the tracking rate correctly (with or without the tracking factor applied), the tracking rate is not being adjusted or communicated to the mount, or my mount is bad. I have a two year warranty and one year is almost up, but it appears this is a common problem, so I am hopeful we'll figure it out. I've been busy with work, so I haven't had time for my hobbies.

m0323 commented 1 year ago

Hi mwillis87,

unfortunately, ukuehn's tip didn't work for me either. I've just come from the balcony after several unsuccessful hours. I would like to help with testing if there are any ideas. I opened a thread on this topic in the indilib forum this week. As shown in the forum thread very rarely it works for me and the tracking speed is right, but I just can't reproduce it.

Mat

mwillis87 commented 1 year ago

@m0323 , Mat, that's crazy - I had literally posted on the indilib thread right before you posted here. As I mentioned, my tracking & strange mount symptoms are precisely identical to yours. When you have a chance, send me your log files (verbose logging turned on) and remove your geographic location. I'm interested in checking your az/alt offsets during a session to see if they are similar to mine above.

In the meantime, can you post your setup and weight of the payload on the mount? My setup information is above. I'm looking for similarities outside the code-related possibilities in our setups to find a common denominator (i.e smaller than tested FOV or heavier than average setup).

Thanks.

knro commented 1 year ago

Another strategy which is difficult to execute but might offer some insight is to sniff the traffic between Synscan App and the mount to see what does on behind the scenes. It might offer up some clues.

knro commented 1 year ago

I added aggressiveness & hysteresis to the Alt-Az tracking algorithm in https://github.com/indilib/indi/commit/754d269598067861a36ff41bd66f3b9934757518

Please check if this makes any difference, I haven't test this yet under actual sky.

federicoparra commented 1 year ago

@knro I know this is not the main thread here but it makes it very difficult to plate solve and therefore to try the driver (see below quote):

I know this is unrelated but as I'm trying to get plate solving to work I'm annoyed that dark frames do not work in the alignment module. The exact same configuration for which a dark frame will work perfectly in the capture module says there are not available dark frames when used in the alignment module :(

federicoparra commented 1 year ago

Another strategy which is difficult to execute but might offer some insight is to sniff the traffic between Synscan App and the mount to see what does on behind the scenes. It might offer up some clues.

This would be AMAZING. The Synscan tracking not only is near perfect, it also gets better and better with subsequent Synscan Pro versions. Last time I tried it really was rivaling EQ-level stuff for 1 minute pics.

ckuethe commented 1 year ago

I know this is not the main thread here but it makes it very difficult to plate solve and therefore to try the driver

Did you file a ticket to add dark frame support to alignment mode? If not, when this specific issue gets resolved it'll be like your issue never happened. If you did file a ticket, could you link it?

When I was getting my alignment settings dialed in, it was useful to spend some time adjusting gain, offset, binning, for a particular filter. My exposure times are 5s or less - usually about 3.5s for a 70mm refractor and a dual-narrowband filter - nothing that needs dark frames. Capture and solve, with action type "None" is a good way to test your capture settings.

federicoparra commented 1 year ago

Did you file a ticket to add dark frame support to alignment mode? If not, when this specific issue gets resolved it'll be like your issue never happened. If you did file a ticket, could you link it?

When I was getting my alignment settings dialed in, it was useful to spend some time adjusting gain, offset, binning, for a particular filter. My exposure times are 5s or less - usually about 3.5s for a 70mm refractor and a dual-narrowband filter - nothing that needs dark frames. Capture and solve, with action type "None" is a good way to test your capture settings.

Hi there! I did not. But it's not like a feature request, it's already there as an option. I think it's very important because (at least for now) with the current tracking problems long exposures for plate solving are out of the question - and very short exposures of 1 sec require quite some gain to work and gain brings up noise. So being able to remove that noise with the dark frame is a really effective way of dealing with that. It works perfectly in the picture acquisition module but in the plate-solving module it always says that there are no dark frames recorded (even if there are), with all settings exactly as in the picture acquisition module. I must confess I tried this months ago so maybe this is a bug @knro worked out in the meantime. Anyways again, let's not get distracted with this issue I will fill in a ticket when I get the time.

knro commented 1 year ago

There is a long thread here about the progress in this driver: https://indilib.org/forum/mounts/13091-az-gti-in-az-mode-tracking-problems.html?start=48#91303

github-actions[bot] commented 7 months ago

This issue has been inactive for 60 days and is being marked as stale.

github-actions[bot] commented 7 months ago

This issue has been closed due to inactivity.