Good deal, Jasem. That sounds promising and could help narrow down any issues in the future.
Alex - I re-installed Ubuntu Kstars 3.6.6 last night and used the default settings. The first session went excellent (synced almost 100%) except my mount was slewing the opposite direction shown on the Kstars map.
I rotated/flipped the scope, restarted my equipment (and Kstars, of course), and the issue of syncing once and not being able to solve another image after the first re-appeared. I'll continue testing and see if I notice a pattern.
There are a few options I played with under the Stellarsolver Options tab. However, I did not change anything related to the solver profiles.
Thank you.
Read More...
Alexander -
Thank you for your post. I am having similar issues with the Kstars 3.6.6 I ubuntu version. Essentially it performs one platesolve, syncs, and is incapable of solving another image. This applies to "default", "large scale", and "small scale".
Another issue is the "slew to target" function will slew once, sync, PRETEND to slew, sync again, PREYEND to slew sync, etc.
I'll try uninstalling and reinstalling and report back when I have clear skies.
Read More...
Good news. I was able to perform the alignment procedure Mat outlined above with excellent results on the first time. My target was Polaris, and I achieved multiple 45 second exposures similar to the one attached.
I normally use the Ubuntu version of Kstars on the interface end ( i.e. non-stellarmate end) however due to the recent upgrade to Kstars 3.6.6, platesolving is pretty much useless. I switched over to windows and ran Kstars 3.6.3 (which had a few performance issues, i.e. super slow and froze repeatedly) but it was able to sync multiple times unlike with 3.6.6 allowing me to perform the alignment procedure.
Clouds set in, and I could image only one target. I'm pretty confident in the process. I'll attempt again on a clear sky.
Read More...
Hello, Jasem,
I attached Mat's data to the previous post. We're noticing a strange polling issue in the logs. The issue for Mat is inconsistent polling during 100ms as well as a spike similar to mine (except super big) with a 1 second delay before the spike. For me, my polling is consistent at 100ms except right before the data spikes. To help diagnose the issue, I propose the following.
1. In the skywatcherAPIMount.cpp file, add an if statement to cover us when the PID returns a "0" value (Line 1227 & Line 1284). For instance, use the last non-zero value from the prior poll for the current poll and log the results as we did previously for the non-zero values.
2. Define a function which allows us to view the step period ("i") in the skywatcherAPI.h and skywatcher API.cpp files. Call the function after setting it as a variable for both axes (we can set it as a variable before as as TrackingRateReadBack or something to this effect.) in skywatcherAPIMount.cpp at line 1233 & 1290, respectively for axis 1 and axis 2.
Does this make sense?
Thanks,
Michael
Read More...
Mat - in regard to your first post, yes, that's exactly what appears to be happening.
As far as your second post, you'd expect one setpoint per poll per axis. In my data, I did not see that particular issue. The reason may be that I only tested settings by turning tracking on/off once with the my settings (i.e. I didn't change settings during the 10 minute sessions). This could be a separate issue which we may need to explore.
If you have 10 minutes, could you try the following indoors and send me the log file? I want to compare the data in the spreadsheet and see what exactly is happening. Just looking at the log file with many data points is difficult.
1. Set the settings to default with 100 ms poll time. make sure tracking is off.
2. Delete the log file for the session (it will re-appear).
3. start tracking.
4. track for ~ 10 minutes with no interruptions.
5. stop tracking.
6. end the session.
7. provide the log file as an attachment.
Two things we can conclude from this testing:
- If we see the same issue in your log file as I have (spikes), then it is a common cause which we'll need to investigate further.
- If we do not see multiple setpoints per poll period, we know there is probably an issue with settings being applied during the same session (i.e. changing of the poll time or other setting).
Of course, anyone else may send data as well following the above procedure. This thread has nearly 19k views, so I know there are more people out there 
Thanks!
Read More...
I tested at 100 ms with no deadband.
I noticed something in the data. There appears to be a 5 second delay in the log file where the spikes in error are occurring. I went back to the other data files I submitted a few days ago, and it appears to be a similar situation for those as well. I also went back to the data from March and before the spike a 5 second gap exists (when a spike occurred, that is).
I did a conditional formatting of column J on the attached files. Look at the rows approximately where the large spikes occur on the graph and you'll see that instead of 100ms between the time increment you'll see 5 seconds right before the spike.
The question is: What is happening? Is the program freezing up resulting in tracking to turn off?
Thanks,
Michael
Read More...