The nightly #221 now has no issue on the previously reported ones:
1. FITS viewer in the capture module on loading a large FIT file (already fixed in the nightly #218)
2. FITS viewer in the Alignment module on loading a captured image (brought in the nightly #218, but not in 2.9.8 release)


The nightly #218 doesn't crash when a fit loaded sent from RPi3, which is captured by D810.
Thanks, again, Jasem.

However, there arises another issue.
Since it was cloudy last night, I was testing kstars nightly #218 on Windows 10 with the simulators on RPi3.
The kstars crashed, when an image was loaded in the plate solver module. No log is left and the INDI server was still running on the RPi3. It crashes before ansvr starts, no processing logs shown in the console at the bottom of the Ekos panel.
Turning back to 2.9.8, the solver works well, while kstars crashes on loading an image in the capture module just as before.
I hope this will be solved in the coming nightly.


Thanks, Jasem.
I can open the large FIT by "Open" under the File menu of Ver. 2.9.8, but it crashes kstars (2.9.8) when I try to Preview in the capture module of Ekos.
Since I'm now out of home, I'll check later whether the Preview in the latest nightly built work or not for images captured by D810.


It's so good to see the large FIT can be opened in the latest kstars.
How can I get the latest nightly BINARY on Win ?


Try the links again. Now they seem to work.

sorry, I cannot inspect the fits, which I had thrown away. I think I had the full-sized RAWs on the card andthe smaller size of fits with the WCS on the client.


What camera did you use when you experienced the crash?
If your cam has pixels more than 24M, your problem may be the same as that I encoutered:

To avoid the crash, I set the resolution setting in the capture module of Ekos smaller, while setting the image-saving option in the INDI control panel as SD card. If you use a DSLR, this work-around would avoid the crash.



The followings are the links to the upload files:

Debayered fit

BTW, I tried to find a work-around and noticed that reducing the size in the capture module to, say, 3000 x 2000, avoids the crash and the FITs viewer shows the downloaded image. As long as I select the Card as the capture destination in the INDI control panel, full-sized images are kept on the card, so I can finish a sequence without the crash of Ekos.
Since a fit file sent from my D5300 with the full resolution (6016 x 4016) does not cause any crash, at least this size of fits will be downloaded to the FITs viewer on Windows.


In the last session, Ekos capture module crashed when loading a fit file sent from the remote INDI server on RPi3. The INDI server was still running on RPi3, so the issue is on the client side.
I tested with two DSLRs to find that the crash occurs for images taken with Nikon D810, but not those with D5300. Attached are the final parts of Ekos logs with these cams.
kstars on Windows crashes when a fit file taken with D810 is loaded on the FITs viewer.
I also tested with kstars on Mac, but the Fits viewer works fine with both DSLRs.
Is there any limitation on memory for kstars on Windows, or any work-around?


In the last session (may be with kstars 2.9.2 or 2.9.3), I encountered a similar problem with my Mach-1 and GTOCP4. The first slew missed the target and went to somewhere only the RA is different.
It seemed as if the time in the mount was delayed 3-4 hours compared to kstars on the PC.

Today I performed the test suggested by Jasem with the latest INDI built from the GIT today on the RPi3 and kstars 2.9.5 on my MacBook Air. The test was done in doors since we had bad weather in these days.
After connecting the hand controller (HC) and the USB cable from the RPi to the GTOCP4, the power was up, then star the Ekos with a test profile containing the AP experimental and the CCD simulator. Of course, "KStars Updates All Devices" was selected in the INDI setting in the Ekos panel.

1) The Location and Time setting reached from the Setting menu on the HC appears as follow:

2) After turning on the mount (while Ekos has not started), I changed the time on the HC (forwading about 2 hours):

3) Started the kstars and INDI, then went to the INDI control panel to send the time and location data from kstars to the mount:

4) But still the "4=Time/LST" in the Main menu indicates the time has not been updated:

5) Going to the Set up menu and selecting "3=Get Time/Loc FrMnt" (see the first image), the time has been synchronized with that of kstars. This seems to confirm the time was updated successfully:

The log of the test session is also attached.
Simply starting up the Ekos did not update the time (and might be location, but I've not tested whether the location is updated or not) on the HC, but seems to update it on the mount. I hope the time setting issue is really solved, and will check in the next session.


Koichi Funakubo replied to the topic 'KStars v2.9.4 is Released!' in the forum. 2 years ago

Thanks, Jasem, as always.
I installed 2.9.4 for Windows to my PC running Win10, and had to re-install the latest Visual C++ redistributable after that.
It would be better to add some note on this or add a script for vc_redist to the installer.


Have you tried the link on the KDE project site ?

The Download page for the kstars for Mac has been left untouched since release of the older version. The latest version is 2.9.3, which will soon be updated to 2.9.4 and will be available from the link on the KDE project page.


Koichi Funakubo replied to the topic 'KStars 2.9.3 is released' in the forum. 3 years ago

An hour ago, I downloaded the 2.9.3 installers from the quick link, whose size is a bit larger than the previous one.
Now the icons are back, and of course, the offline astrometry works fine on Windows.
Thanks again, Jasem.