Just went through my fits files, it appears that the issue started somewhere around Mid 2022, fits before that are fine, but fits files that are younger all have this issue.
The "youngest" fits file I tested it with is one from sept. 2023 which also had this issue.
Read More...
That's interesting, every single fits file I have from EKOS (and I have 1000's) that I have tested had this issue.
That would imply that something else is causing this, maybe the filesystem?
Read More...
Also for some reason I can not create an account at KDE to report it at their git repo directly. It keeps rejecting my client due to anti spam measures
Read More...
I only just noticed this because I am implementing a .fits file library in C# when I was using my own .fits produced through INDI /EKOS for testing.
The fits file standard specifies, that the file always contains blocks of 2880 in length, meaning the file size should be a multiple of 2880.
Now I noticed that something was off when testing my library using fits files produced by EKOS / Kstars.
The file I was using for testing, only had the Primary HDU, however, the file still had bytes after the last 2880bytes block from the images content.
So my library went ahead and thought "oh nice, here comes more data / a new HDU" but the remaining block was less than 2880bytes in length.
I then uploaded some fits files from EKOS / kstars to the online validator found here: fits.gsfc.nasa.gov/fits_verify.html
And sure enough it throws an error:
*** Error: File has extra byte(s) after last HDU at byte 32803200.Now I can simply do a check in my own fits reader to check if the remaining file bytes are not of at least the length of a new 2880 byte block but this seems kind of strange.
Read More...
The mount moving only a short distance sounds exactly like the issue I am having too.
Is there anyone we could ping maybe to take a look at the logs? (I am kind of lost in them)
Read More...
I did some testing last night, with GPS disabled and kstars set to update all devices, and Meridian flip failed again.
Here is what happend:
- Meridian flip triggers (still an exposure ongoing, it has to wait)
- Once exposure is finished, meridian flip starts
- Telescope moves extremly slow (as in Centering speed slow) during the meridian flip and moves in a wrong direction
- I manually abort the mount movements and trigger a manual GOTO
- Now the telescope moves fast, but misses the target slightly and overshoots (and does not stop moving further)
- I again abort the movement and trigger a new manual GOTO
- Telescope again moves fast (as it should) but misses target again and overshoots again
- I stop the movement again
- I stop the scheduler and delete / purge all the config of the mount in the Mount tab of EKOS
- I trigger a new manual GOTO
- Now it slews to the correct position and stops where it should
- I restart the Scheduler and now it works
Relevant bits from the logs are attached, can anybody make any sense of it? The logs show a very active communication between the mount and EKOS for some reason ongoing during the whole flip. Not sure why.
Read More...
That would actually make sense. I have the gps device also mounted on top of the telescope, however the antenna is just put on the ground and has a fixed position and does not rotate with the telescope.
I can test with GPS disabled and see if it improves the issues
Read More...
I am having a similar issue with my Losmandy Gemini G11 as of late:
The meridian flip triggers, but the telescope moves quite slow. I am getting tons of "Meridian flip completed" messages (like at lest a 100) in the log window, combined with thousands of "Mount unparked" (one every second) after that.
I can enable more logs for the next night and upload them here tomorow if that can help.
I have meridian flip set to flip if HA > 2.5°
Manual goto command works without issues.
As John has mentioned, it could be related to when a sequence is running during meridian flip trigger. It seems to trigger many many flips judging by the many "Meridian flip completed" entries in the log window.
Read More...
Just found that the indi-qhy module / driver is not compiling, which might be causing some of the issues I am having (new sdk with old drivers installed):
github.com/indilib/indi-3rdparty/issues/557
Read More...
Also just tried to connect to the camera on windows (using their supplied ascom drivers) and NINA.
The camera never shows up, even in the Windows Device Manager the camera is nowhere to be found.
There is also no sound playing on windows when I plug the QHY163m into the USB of the pc.
Read More...
Just found this in the logfiles of ekos (when i turn logging on for ccd and capture module):
```
[2022-03-04T10:16:12.804 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] |QHYCCD|qhyccd.cpp|GetQHYCCDParam start " [2022-03-04T10:16:12.804 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] QHYCCD|QHYCCD.CPP|Error! Handle to index Error " [2022-03-04T10:16:12.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] |QHYCCD|qhyccd.cpp|GetQHYCCDParam start " [2022-03-04T10:16:12.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] QHYCCD|QHYCCD.CPP|Error! Handle to index Error " [2022-03-04T10:16:12.806 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] CCD T.: 4294967295 (C) " [2022-03-04T10:16:12.806 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] Cooling Power: 4294967295 (1684300900.00%) " [2022-03-04T10:16:13.804 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] |QHYCCD|qhyccd.cpp|GetQHYCCDParam start " [2022-03-04T10:16:13.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] QHYCCD|QHYCCD.CPP|Error! Handle to index Error " [2022-03-04T10:16:13.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] |QHYCCD|qhyccd.cpp|GetQHYCCDParam start " [2022-03-04T10:16:13.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] QHYCCD|QHYCCD.CPP|Error! Handle to index Error " [2022-03-04T10:16:13.806 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] CCD T.: 4294967295 (C) " [2022-03-04T10:16:13.806 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] Cooling Power: 4294967295 (1684300900.00%) " [2022-03-04T10:16:14.804 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] |QHYCCD|qhyccd.cpp|GetQHYCCDParam start " [2022-03-04T10:16:14.804 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] QHYCCD|QHYCCD.CPP|Error! Handle to index Error " [2022-03-04T10:16:14.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] |QHYCCD|qhyccd.cpp|GetQHYCCDParam start " [2022-03-04T10:16:14.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] QHYCCD|QHYCCD.CPP|Error! Handle to index Error " [2022-03-04T10:16:14.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] CCD T.: 4294967295 (C) " [2022-03-04T10:16:14.805 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] Cooling Power: 4294967295 (1684300900.00%) " [2022-03-04T10:16:15.806 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] |QHYCCD|qhyccd.cpp|GetQHYCCDParam start " [2022-03-04T10:16:15.806 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] QHYCCD|QHYCCD.CPP|Error! Handle to index Error " [2022-03-04T10:16:15.807 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] |QHYCCD|qhyccd.cpp|GetQHYCCDParam start " [2022-03-04T10:16:15.807 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] QHYCCD|QHYCCD.CPP|Error! Handle to index Error " [2022-03-04T10:16:15.808 CET DEBG ][ org.kde.kstars.indi] - QHY CCD QHY163M-7c64ca4 : "[DEBUG] CCD T.: 4294967295 (C) "
```
The logfile is full of those entries
Read More...
Am I the only one with this issue?
I did some more experimenting, seems that even when I hook it up to my laptop, the same happens.
The first exposure works, after that it hangs at "Exposing 0.00s ..." for every other exposure for around 30s and then downloads an empty photo (all pixels = 0)
Read More...
I did an update of EKOS / INDI and all its drivers, since then the capture module seems to not work anymore with my QHY163m.
Whenever I take a photo, it takes really long to capture the image (like 30s for a 1s exposure). My guess is it runs into some kind of timeout.
After the roughly 30s a completly black photo is shown (value is 0 for every pixel).
I am not sure what is going on, I recompiled all the INDI drivers again from source and still have the same issue.
Read More...