Get Connected!
Come and join our community. Expand your network and get to know new people!
Two comments here:
You do not need a dark signal for that calibration. What you measure is the noise of the ADC. If you have dark signal in that image, it will shift the whole histogram to the right, and you might end up with a too low offset that clips for short exposures. So I'd rather recommend short(er) exposures for this. For histograms, you need to use logarithmic view to properly judge the proper cutoff.
And, as someone who does this calibration for all his cameras, I strongly second the request to make such a table (only) a recommendation, and not an automatic override (the most important feature of any automatics is the button to switch it off ;^>)
For implementation, I could imagine a (camera-specific) gain-offset table in the sqlite database that can be edited by the user (somewhat similar to the focus offset table for filters). Filling that one with recommendations on first connect might indeed be helpful for many users.
Read More...
In the guide tab of EKOS, open the Options menu (button in the lower right). There, under 'Guiding', you can activate dither and set the parameters (frequency, amount...).
Read More...
I believe I found one issue that could contribute to this. Fix pushed to GIT: invent.kde.org/education/kstars/commit/7...a7c317b252fdec560fa9
Read More...
Hi Eric,
thank you for the quick reply. I always use Config#1, no matter what scope I used. This was till now no problem, because the focal length from the Profile in Ekos was used.
What I've done to get the problem solved was to create a new Config#2 with the focal length 600mm. But it would be good, if the old behaviour would still exist: choose a telescope in the Profiles and everything is ok. Perhaps til now I used kstars wrong maybe 
Read More...
Alfred,
this indeed matches my experience: There is a continuous stream of exposures from guiding at the requested exposure time exactly up to the point when, after dither, guiding is resumed. This resume triggers a new exposure, which aborts the currently ongoing one:
[2021-06-11T00:19:01.290 CEST INFO ][ org.kde.kstars.ekos.guide] - "Guiding resumed."
[2021-06-11T00:19:01.291 CEST DEBG ][ org.kde.kstars.ekos.guide] - Capturing frame...
[2021-06-11T00:19:01.293 CEST DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI294MC : "[DEBUG] Aborting exposure... "As I mentioned in post #72049, that abort also happened in the 'old' version, but there only once, and after that only one stream of exposure/readouts continues with proper exposure times, whereas now both seem to continue.
Thinking about it, my guess is that the main error is that when an exposure is already going on at the time when a frame capture is requested, the ongoing exposure is aborted, but read out, and then returned as the requested frame, instead of completely dumping it and waiting until the newly triggered frame exposure ends.
Read More...
Could you check what configuration is in use in the Mount module when you open your profile? That may be what the Align module is using. There may be a discrepancy there that we need to fix.
-Eric
Read More...
Hi all,
I just got my new small Newton telescope, so I added a new profile in EKOS, and also added a new telescope with the right focal length (600mm). Meanwhile I have 10 telescopes in the list (with all the reducers, guiding scopes and so on)
When testing the new scope following happens: I choose the right profile, checked weather the right telescope is selected (it was) and started ekos. I pointed to Arcturus and wanted to plate solve, but plate solving was not possible. So I checked everything and realized that the focal length was wrong (1000mm, which I used the session before). Even after restart the wrong focal length was present! Until that issue it was that the focal length of the profile was taken by ekos.
Also missing was the button "Set" in the indi tab for the mount. So it was not possible to easy fix that issue.
What is going wrong here?
I'm using stellarmate with all current updates (kstars 3.5.3, indi 1.9.0).
Read More...
Hi Hank, The drivers I had originally, from years ago, did not include the new Camera I had bought (ASI294MM Pro). When I updated the Indi drivers, everything fell into place. I am not using Astroberry. I did a custom install of the Indi server on a Raspberry Pie 4 and I use the built in Wifi to connect remotely using SSH. I have a dedicated USB Hub and a dedicated Power supply for the Pie 4. I run the whole remote setup from a marine 12V battery. So everyone (Pie 4, mount, camera, guide scope, focuser, heaters, etc..) has plenty of power.
Read More...
Looks good to me.
I also noted the first time I ran the driver the motor locked due to the new code for the board revision.
It was fine once the settings were saved.
Read More...
I repeated the test with the laptop and this time there were no issues at all. Will try to find out what went wrong yesterday.
Read More...
Perfect. I'll test it soon.
I'm not sure if writing to a file is how other drivers do it. But I'm sure it will be fine. Thank you.
Read More...
My attempt to build a master darks library were unsuccessful (yesterday's GIT). Crashes occured repeatedly when the master dark was computed regardless of whether or not older files existed. I guess I had ~10 attempts. One succeeded, all others failed and crashed KStars/Ekos altogether.
Read More...
I managed to guide for a while although conditions were very bad. While guiding, I did not recognize any issues. However, I saw the Indi log window reported double requests for guide images after dithering. The amount of information in my logfile is overwhelming and I can't see whether it confirms the issue you reported. It's attached so everybody can have a look.
What I found though was the process of producing master dark images for the darks libary did not work at all. It crashed KStars multiple times when the master dark was computed and I never got a full run completed. After ~10 crashes I gave up.
Read More...
Okay I just committed a change that will save the position to a file, and restore that position on startup. To be clear, this doesn't actually move the focuser, it's the equivalent of doing a "sync" to the last known position.
Try it out and let me know how it works out for you.
-- Kevin
Read More...
