Hi,
I still need help with these focus module crashes. I played around and was able to recreate the crashes with
a) ZWO camera instead of Canon
b) with ZWO and focus simulator instead of moonlite focusser
So I would conclude it is not the Canon driver and not the moonlite driver. I have attached both logs below in a tar ball.
Could it be the installation on my raspberry 4?
Help would really be appreciated!
Best regards
Stephan

I just set up a Virtual Box on my laptop running the Raspbian OS and kstars. With the same combination of ZWO and Focus Simulator that crashed before, I wasn´t able to create a crash. So it seems, it has to do with Kstars/Ekos running on Raspberry Pi Hardware. I am, therefore, officially out of ideas... Need your help.
Best regards
Stephan

In both cases there is an assertion failure in the code:
But maybe the more interesting warning is this:
It seems like there is no telescope driver running. Are you holding your scope in your bare hands?

Add at least the telescope simulator as scope and try again.

HTH and greetings from Schwäbisch Hall to Munich
Wolfgang

Hello Wolfgang,
for the tests, I didn´t hold my telescope in my bare hands , but it was indeed in its box. I just hooked up what I thought was needed. I don´t think this is the right clue, however, because I noticed the crashes when I first used it under the stars - telescope and all hooked up.
Anyhow, I will test it right away - just to make sure. Thanks for your help and for looking into this.
Greetings back to Schwäbisch-Hall (where I was just two weeks ago)
Stephan

Hello Wolfgang,
as I suspected, the telescope not being connected was not the culprit.
I now had the telescope simulator on and the same thing happened. Attached is the log from this latest case.

Is there anything else, I can do to diagnose the issue? Run it in gdb or something?
Thanks
Stephan

Hi Stephan,
OK, so the warning about missing scope parameters are not relevant. The last entry in the log is an assertion failure "Tracking box is disabled when detecting in full-field". I currently do not understand where this assertion comes from. Are you using full field mode and is "auto select star" selected?

Hi Wolfgang,
the path to (quite certain) crash is as follows:
1. Autostar is not selected, Sub Frame is selected
2. Capture image
3. Click in image (to select star - new sub frame is captured and displayed)
4. Select Full Field
5. Capture image
6. Klick on Zoom-to-Fit in image
7. Click in image (as to select different star)
At this point, it sometimes crashes already at this point, some other times, it crashes when you repeat steps 4-7
Cheers
Stephan

Hi Stephan,
sorry, I cannot reproduce it, but I'm on the latest version. You could give a try to compile it from the sources: invent.kde.org/education/kstars

Wolfgang

Stephan,

Re your point #2 (getting the HFR of subs): This functionality is partially implemented right now. It is tied to fitsviewer. As I don't have a DSLR, I can't test it with one, but if you can get your images to come up with fitsviewer after capture, then go to the view menu, and select "Mark Stars". After some computation, you should see an HFR value on the bottom (status line) of the fitsviewer tab's window. All future captures will also compute the HFR and display it there too. You can inspect them that way. If you want a record of the HFRs of all your images, you can run your Ekos with logging set to: Verbosity: "verbose", Output: "file", EKOS: "FITS" (the logging menu is accessed by clicking "Logs" on the "Setup" tab), then the HFR values will be written to your logs and you can grep them out: e.g.

> egrep '(FITS HFR|file saved to)' log_00-27-53.txt
[2020-06-21T00:43:13.245 PDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/home/pi/mydisk//Pelican/Light/Ha/Pelican_Light_Ha_480_secs_2020-06-21T00-43-13_054.fits"
[2020-06-21T00:51:16.911 PDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/home/pi/mydisk//Pelican/Light/Ha/Pelican_Light_Ha_480_secs_2020-06-21T00-51-16_055.fits"
[2020-06-21T00:51:20.585 PDT DEBG ][ org.kde.kstars.fits] - FITS HFR: 2.13282
[2020-06-21T00:59:24.461 PDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/home/pi/mydisk//Pelican/Light/Ha/Pelican_Light_Ha_480_secs_2020-06-21T00-59-24_056.fits"
[2020-06-21T00:59:28.142 PDT DEBG ][ org.kde.kstars.fits] - FITS HFR: 2.04297
[2020-06-21T01:07:32.299 PDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/home/pi/mydisk//Pelican/Light/Ha/Pelican_Light_Ha_480_secs_2020-06-21T01-07-32_057.fits"
[2020-06-21T01:07:35.969 PDT DEBG ][ org.kde.kstars.fits] - FITS HFR: 1.99833
[2020-06-21T01:15:35.678 PDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/home/pi/mydisk//Pelican/Light/Green/Pelican_Light_Green_240_secs_2020-06-21T01-15-35_032.fits"
[2020-06-21T01:15:39.410 PDT DEBG ][ org.kde.kstars.fits] - FITS HFR: 2.27915
[2020-06-21T01:19:43.799 PDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/home/pi/mydisk//Pelican/Light/Green/Pelican_Light_Green_240_secs_2020-06-21T01-19-43_033.fits"
[2020-06-21T01:19:47.672 PDT DEBG ][ org.kde.kstars.fits] - FITS HFR: 2.25149
...

Obviously this is an inadequate user interface. On my list is a way to improve that, and I hope to get to that in the codebase in next month or two. I'm a fan of monitoring the HFR as well, and in fact use the technique I describe above regularly.

Hy

Hello Hy,
thanks for this idea for the focus monitoring. As soon as I get my crashing situation resolved, I will start playing with it. If it works like you explained, then it will do the monitoring job just fine.
Stephan

Hello Wolfgang,
I tried to compile from source, but was unsuccessful (make reported an error after about 34%). Then it was too late to investigate. I will try again tonight.
Best regards
Stephan

Hey,

The assert was introduced by invent.kde.org/education/kstars/-/commit...b6ed3cd8f04f6ec0ccba, focus.cpp, line 1061.
I removed this assert at invent.kde.org/education/kstars/-/commit...d1b90ee554da22b57c35, focus.cpp, line 1036.
This was a real problem, there should not have been a tracking box in full-field, so the assert was detecting an earlier bug.
Because I could not find the root cause and a re-architecture process was planned, I chose to hide the problem and explicitly disabled the tracking box in full-field to avoid further confusion in the module.

I need to observe that Q_ASSERT_X is empty when the project is built without debug. In debug mode, it will call qFatal() and trigger the debugger.
The code is probably crashing later on because of the induced instability? Or the code is built in debug mode.

-Eric