Bart
Can you please clarify/repeat, since this is a long thread, what the issue is in the logs you’re submitting?
Thanks for submitting them
Hy
Read More...
@Fitchie,
It is much better if you submit log files instead of scraping the text from the log windows. There is a lot more info sent to the file than is displayed in the window. Also, one can tell the geography and the software being used, etc. Make sure the log files are set to verbose and check all Ekos modules. Usually those files are too large to post directly, so just gzip them and upload them to Google Drive or Dropbox and send a link.
However, in this case, I don't see any problem to look into (other than the color issue), so at this point I don't think logs are necessary. The mosaic tile-switching seems to have worked very well for you until about 9 minutes before it shut down for astronomical dawn. It wouldn't shock me if the system didn't switch jobs a few minutes before it was going to shut down anyway for daylight.
Hy
Read More...
The code simply checks to see if there are files with the right file names in the right directory on disk and counts them. It does not look in detail at those files, just checks the file names
Read More...
If you have 'Repeat until terminated' checked for all your tile jobs then the same schedule should continue to collect images for all tiles.
If you have verbose logs to share, please post links to them along with your description of what problem you're reporting in as much detail as possible. I've alerted Wolfgang who is more familiar with what I think you're describing.
Hy
Read More...
Analyze files are nice to get a broad idea of the session, but log files with verbose logging enabled helps us debug.
See www.indilib.org/support/logs-submission.html
Check all the boxes in the modules section and make it verbose to file.
Compress and share the file via dropbox or google drive.
Read More...
Thanks Max.
I changed those three fields to have 1 decimal place, and now they fit in their boxes.
Hy
Read More...
The answer to your question is usually flexure. That is, the pointing of the guiding telescope and the imaging telescope bending slightly away from each other. To quite John Hayes, "at one arcsecond everything is made of rubber". That was the reason I created this feature in the first place, because I was suspecting that in my system.
In the end, the usual solution is a off-axis guider or an on-axis guider.
Hy
Read More...
Jerry,
From looking at that log you included, I'm not worried by the line you highlighted in red. It's just saying is that the capture module is ignoring the image captured, which is what it should do since the image was requested by Align. In fact, the very next line shows that Align processed the image.
However, it's not working, and from my reading of that log segment, it seems like StellarSolver is continually failing to solve the image. It takes another image and another image and keeps trying but it can never solve the image. It never aborted totally because you weren't using the scheduler, as far I can tell.
So, you main question should be "why did the solver fail (over and over)"? I can't answer that. Perhaps you should check the box in "Developer Options" to save align images, and then if this ever happens again you and I can look at the align images and see if it gives us any clues.
I assume that normally align does succeed to solve your images.
Hy
Read More...
David,
- I think the guider's number of stars and SNR stats should be thought of as relative measurements. That is, you see what they are when the guider starts, but their absolute values may not be too meaningful. As you point out, they depend on the star field in the guide-camera's field-of-view, and the SNR also depends on the brightness of the guide-star that happens to be chosen. So, when you do a meridian flip, the side of the image that the OAG picks off changes to the other side of the image, and the stars there are different.
Currently with SEP MultiStar guiding, even though there are many stars used to evaluate the drift, one star still is the "guide star" and that star's brightness helps determine the SNR. Admittedly, I should change that, but it's probably not a big deal in terms of guiding performance. BTW, I'd recommend you use a lot of reference stars--I use up to 50.
- Usually backlash doesn't affect RA, as the RA motor is running all night. Typically guide pulses are much less than the actual tracking rate so all the guiding in RA does is speed up or slow down the tracking rate, but the motor doesn't change directions. Think of it this way. RA tracking is roughly 15 arc-seconds/second. You'd need an error in RA of > 15 arc-seconds towards the East with 1.0 aggressiveness to completely stop the RA motor for one second. Therefore the motor is always turning the gears in the same direction and there shouldn't be backlash. (This is not true in DEC. DEC isn't tracking, typically, therefore you do change direction in DEC, and backlash may apply. That's why people talk about backlash for DEC.)
You may have large periodic error. This would cause variation in RA that the guider is fighting against. Assuming your mount supports it, you can load a PEC curve to counteract that. That is also what GPG tries to fix, but of course, it would be better if it didn't have to fix it, or didn't have to fix it as much. I have an experimental piece of code that computes and uploads a PEC curve with Ekos for my A-P mount, but only have one volunteer who can help with the testing for EQMOD mounts. It definitely helped my RA performance, though it was already pretty good. See indilib.org/forum/wish-list/5267-softwar...od-mounts.html#93921 if you want to also help test. Of course, you can always use a PC and upload a curve via pempro or theskyx.
- Widgets and the mouse scroll wheel: I agree with you that it would be nice if the scroll wheel didn't adjust the widget until the widget was clicked. This must be something buried inside of the Qt widget library, and we're likely using the default. I'll try and google it to see if it's something that could be changed--but i wouldn't keep my hopes up.
Read More...
No, dithering is not an issue.
We don't reset the GPG during dithering (one pulse or normal). It continues to operate.
There is a GPG input where you can tell it about things like dithering.
invent.kde.org/education/kstars/-/blob/m...?ref_type=heads#L294
GPG only resets on a real slew or a guiding reset, e.g. "lost guide star".
Read More...
Please send a full verbose log, if you have one, re the align and focus running at the same time. Or, send one the next time you see it.
Hy
Read More...