I want to update this thread with my latest results and to report a resolution to the issue. Changing USB cables and trying different power sources didn't resolve the camera errors but it did turn out to be a USB problem in the end. I have an iOptron CEM120 EC2 and I was using its USB hub to take advantage of the through the mount cabling feature. A few days ago I switched all the USB cabling from the iOptron hub to the hub in a Pegasus Ultimate Powerboat V2 and I have had three nights of flawless camera performance, including during meridian flips. For the sake of clarity, all my power connections are the same as they always were (routed through the Pegasus) and the only difference is avoiding the iOptron USB hub.

I have owned this mount for a couple of years and this is the third electronic related problem I've had. In this case I'm just going to continue to bypass the USB hub on the mount and continue using the Pegasus.

Thanks to everyone who suggested solutions!

Read More...

Had a chance to try again last night after cleaning up the camera and checking power (which was ok). The same result plus I'll include another issue I've started to experience.

First, after the meridian flip, here are the log entries as EKOS tries to capture an alignment frame:

[2023-09-04T23:54:56.807 PDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[DEBUG] Setting frame buffer size to 30560192 bytes. "
[2023-09-04T23:54:56.807 PDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[DEBUG] Setting Gain=140.00... "
[2023-09-04T23:54:56.808 PDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[DEBUG] StartExposure->setexp : 4.000s "
[2023-09-04T23:54:56.808 PDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[ERROR] Failed to set exposure duration (ASI_ERROR_GENERAL_ERROR). "
[2023-09-04T23:54:56.808 PDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[INFO] Taking a 4 seconds frame... "

This exposure fails and then this entry:

[2023-09-04T23:54:57.853 PDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[DEBUG] ASIGetExpStatus failed. Restarting exposure... "
[2023-09-04T23:54:57.854 PDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[DEBUG] StartExposure->setexp : 4.000s "
[2023-09-04T23:54:57.854 PDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[INFO] Taking a 4 seconds frame... "

After three attempts this fails. Next EDOS tries to restart the imaging sequence (without the alignment having succeeded). This also fails. To get things started I use the INDI Control Panel to first Disconnect and then Connect the ASI6200 again. Then I go in and perform the alignment step, start auto guiding, and start the image sequence again. It all works for 5 hours without a problem.

This morning, trying to take flat frames, the same thing happens: (ASI_ERROR_GENERAL_ERROR). I use the INDI Control Panel to first Disconnect and then Connect the ASI6200 again. Then I start the sequence of flat frames which completes successfully.

I'm happy to send log files again but these are the same as the one I posted before. I can try my other camera to see if it exhibits the same behavior but, if anyone had ideas, I'm all ears.

Thanks

Read More...

Thanks Aaron,

I'll have a look tonight when I start my hoped for next session. I don't have a permanent installation and use a Jackery Explorer 1000. I power my RPi using the separate USB-C output (18W Max, (5V, 9V, 12V up to 3A)) and the rest of the gear using the 12v 10A Car Port - the two big draws are the mount (up to 5A) and the ASI6200 (up to 3A). I use a Pegasus Power Box and occasionally monitor the current and it's never even close, even when using the dew heater. I always start each session with the Jackery fully charged and it rarely goes below 50% overnight.

But - you never know and I'll have a look.

Read More...

An update on the status of things. After the cable change I continue to get the "ASIGetExpStatus failed" and "ASI_ERROR_GENERAL_ERROR" messages in my log. Last night it happened only one time, in connection with a meridian flip. The camera had been imaging for 38 frames and 2 autofocus runs with no interruptions. After the flip, the error popped up again and prevented the post flip alignment process from completing. The stopping and starting using software only again fixed things and the camera continued to image for over 5 hours with no problems.

This morning I took the back off the camera and checked the integrity of the USB 3 connector, It appears to be undamaged and the solder holding it to the camera's circuit board also appears to be solid. I noted dirt (including on the circuit board) and even a couple of expired insects so I cleaned things up, put the back on the camera again and we'll see if any of that helped things - I plan to image again this evening, smoke willing.

Read More...

Aaron and Jasem,

Thanks for your suggestions. I changed out the USB 3 cable to the ASI6200MM and after another night of imaging, an update. The headline is that I experienced the same behavior as well as a new one. Also, this morning I see no evidence of a cable snag (they are rare for me since the iOptron 120 has through the mount cabling).

I should note that I am using the ASI6200's 2 other USB ports to connect to the guide camera and the filter wheel and neither of those devices have exhibited an error. If the primary USB connection to the camera were the problem I would expect those two USB 2 ports to fail as well. Finally, when the camera does fail, I am able to set things right again by either (1) Disconnecting and then Reconnecting just the camera from the INDI control panel or (2) Disconnecting and then Reconnecting all the devices from the EKOS setup module. I don't have to play with the physical connection.

I have attached a screenshot of the Analyze Module covering all of last night's imaging. There are two failures. The first right after the meridian flip when the align module couldn't capture an image and the second where there is a rather large gap in image capture starting around the middle of the screen capture. You can disregard the red focus bars at the end - that was a function of local sun rise. I should note that I have focus set to run every 60 minutes.

In the first failure I was able to get the camera working again (via software disconnect/reconnect) but I could not get the align module to align. The mount had slewed to approximately the right location but it was not framed within the 30 arc seconds I had specified. It would take picture after picture, solve, and then the mount didn't move - the arc second error stayed the same. Finally I discovered that, although the mount was tracking the target, the Mount Module showed the mount as "Parked". Once I unpacked the mount, the alignment worked and I was able to continue the session. I'm not sure how it is possible to be parked and tracking at the same time.

In the second failure a simple software disconnect/reconnect got things working again and EKOS completed an autofocus and resumed capturing images.

I have attached one screenshot and here's a link to the log file (too large to post here): www.dropbox.com/scl/fi/9ltr593hw73yjq4hr...4nhgy1dk0atwq8f&dl=0. For reference the timestamp on the meridian flip is 23:3513 and the timestamp for the end of the blue frame that started the large gap is 01:11:07.

BTW, if there's any advice on how to reduce the size of the log file without discarding useful information, I'd certainly appreciate it - the way I've got it set up makes for large files with many lines.

Thanks for any help.



Read More...

Thanks Aaron - I'll give that a shot and report back. It is a problem that has surfaced only recently so wear and tear could be a factor.

Read More...

I have run into a problem running KStars/EKOS on a Mac. The Mac communicates with an RPi acting as an INDI server (Stellarmate OS) at my mount. The Mac is running 3.6.7 Beta (Build 2023-08-28T17:48:31Z), although this has happened with earlier builds as well. The RPi is running StellarmateOS 1.7.8. I am shooting with an ASI6200MM camera with a filter wheel.

The progression of events in the first case:
1) The mount performs the meridian flip at the proper time.
2) The Align Module changes the filter to Luminance, if needed, and attempts to perform an alignment. One thing perhaps I should do is check the "use current" filter in the Alignment Module - that would at least stop the filter changes.
3) The log shows that after changing the filter, there is an error setting the exposure duration - ASI_ERROR_GENERAL_ERROR.
4) EKOS tries a couple of more times but the log shows "ASIGetExpStatus failed" messages.
5) After pronouncing the align process "aborted" EKOS tries again which for some reason triggers an autofocus run and a filter change back to the filter I was shooting with before the flip. Not surprisingly this also fails since the log shows more "ASIGetExpStatus failed" messages. Then later, more "ASI_ERROR_GENERAL_ERROR" log entries.
6) EKOS tries to autofocus numerous times, including autofocus with the luminance filter which is strange since I wasn't shooting with my luminance filter. Eventually, it fails and everything stops.

I have attached the log file (to get the file size down I removed the hours of logging before the meridian flip and the hours of logging after I started things up again - I've marked where the deleted entries were). The issues seem to start at the 23:41:28 timestamp.

In the second case, a few hours after I started things up again, EKOS crashed completely after properly recording the first blue filter frame in a series (the errors start around 02:28:53). At the end of the log file (the last entry was at 02:28:57) exposure seems to be aborted after 3 attempts because of a series of problems logged as "ASIGetExpStatus failed". The log just stops at the last entry and the Mac's screen showed a hard crash had occurred.

In both the cases, it seems the ASI interface was causing a problem but perhaps it was some setting I have. I should note that I captured over 60 frames successfully last night so things seem to work most of the time. Any help would be appreciated - if I can provide more information, just let me know.

File Attachment:

File Name: 20230828Log_2023-08-29.txt
File Size: 3,663 KB


Read More...

I just went to kstars.kde.org and got the same file damaged error from what I downloaded there.

BUT, when I download the nightly MacOS build from binary-factory.kde.org/job/KStars_Nightly_macos/, it works! So, it's odd that the stable release continues to have the problem while the nightlies seem to work now.

While I know that people may not want to mess with the Terminal and the xattr command, if you trust the download source and you have no other way of running KStars, this is a temporary solution. Here is another article on the same topic: www.howtogeek.com/803598/app-is-damaged-and-cant-be-opened/.

Good luck and hope this gets fixed soon!

Read More...

Peter - excellent tip - thanks!

Read More...

Mike,

This 'damaged' message is something that only cropped up over the last 2 or 3 weeks. I understand Jasem is aware of this problem and I would imagine a fix is in the works. I meant this post only as a temporary way to get around not being able to download and run KStars at all in the meantime.

The one positive of this method is that you don't have to go through the Systems Settings/Privacy & Security mess when you download a new version of KStars. This terminal command seems to bypass that.

Read More...

Just found an answer that requires an additional step for Mac users but it appears to work! I followed the directions from this site (it's a simple one line Mac Terminal command):

www.howtogeek.com/803598/app-is-damaged-and-cant-be-opened/

I was able to launch the previously unlaunchable 3.6.7 Beta. I haven't tried it on the production release but I'll be it works.

Hope this helps!

Read More...

Hi Eli,

Have the same problem with the amount of history they keep. If you don't mind running 3.6.0, I was able to find a site that keeps KStars history. I downloaded it and, after usual Apple security dance, it launched without problem:

www.fosshub.com/KStars.html

It is frustrating that the developers can't seem to have a download that works for the past couple of weeks.

Fred

Read More...