×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Items from last night's INDI/Ekos/Kstars session

  • Posts: 535
  • Thank you received: 109
Greetings all, I took some notes from last night's session, and wanted to get some feedback in the case I am doing something wrong. All of my packages are -bleeding unless otherwise noted.

I have:

Intel Gen7 i3 NUC with Fedora 25
Sirius EQ-G with EQ-direct cable from Shoestring
GlobalSat BU-353-S4
a couple ASI cameras
a moonlite stepper focuser

1) I mentioned it in another thread, but will mention it here, too. The time offset for DST is off 1 hour, and it throws off the sync and causes plate-solve to take extra steps. Related link: forums.fedoraforum.org/showthread.php?t=314257 . At this point, this one might be a lower level problem than INDI, though it seems INDI should look at system time and not rtc, but either should work.

2) Indistarter is a separate project, and works very well. It has one bug where after everything is green and the services are started, my ASI camera line turns red again even though the driver is still running fine. I have not looked into this further to see if it is INDI reporting ASI down back to indistarter, or if the bug is entirely indistarter not handling something.

3) I would like to have the option to not have a failed tracking stop the capture. I don't seem to see where to set that. That is, if for some reason I lose my tracking star, I would like for it to just try to pick up another one and no abort the entire sequence. It is much easier to drop 1 image than to restart the entire sequence if I am not at the computer. This might be a setting I have just missed somewhere, as this area seems pretty solid.

4) Astrometry fails with 16bit FITS files. I need to look into this one further. RGB, Luma, and 8bit FITS all work fine. Online upload also works, it is just too slow for my liking. I can solve locally in a couple seconds when I switch the image type from 16 bit to something else. I tried turning debug on, but have not found anything yet.

5) This is a change in the last week. When I set up a sequence, set the cooler, the exposure time, the number of captures, etc, and then hit the "+" button to add it, it appears to add it fine, but when I hit the play button to start it, it run a previously configured job that I had removed with the "-" button. It doesn't appear that the "-" button is fully removing the information and it only goes to the new capture sequence after the now hidden previous one runs again.

6) A feature request, not a bug: For EAA type stuff, it would be nice to be able to stack captured images in the fits viewer, and to have a couple more option for black levels and such in the histogram for tuning the expansion of captured fits files. That being said, I know EAA is not why and how it was designed, so the other 5 items are certainly higher on my list of things to address.

Overall, the experience is great. The level of integration between the parts is wonderful for a one-stop photo session, and the ability to run everything attached to the scope remotely is amazingly versatile. It is really nice, I'd like to help make it nicer by providing any information and testing I can to assist in tracking down the above items. If any of the above are user (me!) issues, I am ready to be educated.

Thanks to the dev team for the hard work on INDI/Ekos!

Jim
The following user(s) said Thank You: Jasem Mutlaq
Last edit: 6 years 9 months ago by Jim.
6 years 10 months ago #16739
The topic has been locked.
  • Posts: 535
  • Thank you received: 109
1) I think I might be being bitten by this bug: bugs.kde.org/show_bug.cgi?id=291203

4) solved by adding --no-fits2fits to the solve-field command line. Was this removed in a later version? I thought it used to work without changing anything.

5) I am live again tonight, and playing with this. It seems to be related to trying to capture a preview when image save is set to "local". Local for me is the NUC on the scope, and the client is my desktop in the house. I get the error that it cannot preview, please set to client mode, but the preview config is somehow stored and when I hit the play button after setting to client, it does the preview 1 frame without saving. Only then will it go on to the actual visible list in the right pane.
The following user(s) said Thank You: Jasem Mutlaq
Last edit: 6 years 10 months ago by Jim. Reason: updated, added 1), update 2, added info for 5)
6 years 10 months ago #16740
The topic has been locked.
Hey Jim! Glad you find INDI/Ekos useful!

1. Yes, we are aware of this issue, but it is not easy to fix. KStars needs to use tzdata from system rather its own set, no one yet stepped in to fix it and the others are busy. Try to adjust use a different UTC offset rule that would fix your issue for the time being.
2. It's an external project so I can't comment on it. Have you tried INDI Web Manager?
3. Guider failure restarts are possible once you start using the Ekos Scheduler. If you just do a plain sessions for now capture aborts on guider failure.
4. This is a known issue acknowledged by ZWO, 16bit is not available on all platforms. They say USB3 should be used, but I've seen reports that even 16bit fails then.
5. I've seen this reported before, thanks for describing it in details, I hopefully should be able to track it down.
6. No plans to implement this now but we would welcome any code contributions!!
The following user(s) said Thank You: Jim
6 years 10 months ago #16742
The topic has been locked.
For "--no-fits2fits", if you see the tooltip in the Astrometry Options, it says when to use it. Already in GIT, KStars tries to detect the local offline astrometry option and then sets/unsets "--no-fits2fits" accordingly, but it cannot detect remote astrometry version yet.
The following user(s) said Thank You: Jim
6 years 10 months ago #16743
The topic has been locked.
  • Posts: 535
  • Thank you received: 109
Thanks knro. Item 5 is probably the biggest detractor at this point, so if there is any more information I can get to you, please say, and I will do what I can on this end.

Try doing a preview with the storage set to the remote machine. This seems to trigger it every time. You will get the error, but it seems to put the request in the memory stack so that when you switch the storage back, it runs it, even though it doesn't appear in the list.
6 years 10 months ago #16786
The topic has been locked.
I tried to replicate it yesterday but couldn't, can you please list the exact steps to reproduce the issue with the simulators?
6 years 10 months ago #16789
The topic has been locked.
  • Posts: 535
  • Thank you received: 109
I managed to reproduce it on the simulators as well. Here is what I did:

set up devices on remote: telescope simulator,gps simulator,focus simulator,ccd simulator,astrometry

verify indi services are running

go to second machine with kstars-bleeding or equiv.

configure profile for first remote machine and connect all devices

go through some motions to simulate a session (auto focus, preview, cooler, etc.) -- probably not necessary

change Upload: from Client to Local, set a Remote: of somewhere (/tmp /home/<>, whatever)

Set a target Prefix: name

Hit the preview button. You will get the message:



2017-05-17T08:02:51 Cannot take preview image while CCD upload mode is set to local or both. Please change upload mode to client and try again.
2017-05-17T07:58:30 Capturing image...

It is at this point where something is stored on the stack, but not visable to the user. To see it better, now add a sequence or two, and try another preview with the Upload: Local set. Now press play on the sequence, and get the message about preview:

2017-05-17T08:06:14 Cannot take preview image while CCD upload mode is set to local or both. Please change upload mode to client and try again.

You should not get this when pressing the sequence play button, because a preview should not be stored as something to do in the sequence list, right? This also can happen with sequences if you hit the "-" button to remove one. It is not actually removed, and if you then hit the blue reset button, and the play button, it will run through your old sequence and then the new one as well.

Hope this helps
6 years 10 months ago #16793
The topic has been locked.
  • Posts: 106
  • Thank you received: 11
I can endorse that Ekos insists on finishing the Preview image download before allowing you to move on irrespective of attempted cancellation.

FWIW: when setting the capture to download to Client I created the chosen download folder using the folder dialog in Ekos as apposed to simply linking to an existing folder (I also save the settings for the camera in the Indi Control before capturing. Adds a little confidence). with local folders (I experienced this using Raspberry Pi) they must have user and group permissions set.
Skywatcher 190MN - EQ6 Pro (with Belt Mod) - ASI1600MM-Cooled - ASI EFW7 - ASI120MM - WO f4 Guide Scope - Rigel nStep - KStars/Ekos - KDE - PixInsight
6 years 10 months ago #16794
The topic has been locked.
I believe I fixed this issue, so hopefully with next KStars release it would be fixed.
6 years 10 months ago #16805
The topic has been locked.
  • Posts: 535
  • Thank you received: 109
Music to my ears. Thank you!
It looks like 1,4, and 5 will all be addressed shortly.
I am trying to work around 3) by running a dedicated USB cable for the guide camera, but have not had cooperative weather to try it. I was using the hub on the ASI1600 to run the guide, but wonder if it was a bandwidth issue trying to run both cams on one port. I could also try to reduce the bandwidth setting more, but it is at 40 and running on a i3 NUC with USB3 ports. I will update when I can test it more.
6 years 10 months ago #16806
The topic has been locked.
  • Posts: 535
  • Thank you received: 109
an update:

#3 continues to plague me. What is happening, is I have a high-resolution camera (ASI1600), and I am not binning, so the file size set at 16bit RAW (FITS) is quite large. After I do a capture, and the image is downloading, this is when the guide camera times out or goes offline. My download is to a remote computer over wifi, so it takes a few seconds. It appears this transfer is not allowing the guide processing to happen in the background, and it is timing out. I am not sure that is what is happening, but that is the user perception. As a test, I changed the file saves to write to the machine local to the camera. That has now sent 5 frames without aborting the tracking. With the saving to my main computer, it would abort the guide and the sequence every time an image was transferred.

Edit 2: Setting the image save to "local" did allow the guiding to work frame to frame without aborting. It did not seem to actually save any images on the machine with the camera though, even though I set it to a path that exists. They were not in the path specified, and I did a search of the machine and did not find them anywhere else either. No errors were reported in the logs.

#5 Does indeed appear to be resolved! Thanks for the work on this, and sorry for the delay. The weather was not cooperative.
Last edit: 6 years 10 months ago by Jim. Reason: more information
6 years 10 months ago #16905
The topic has been locked.
Right, I introduced a timeout value recently specifically for ASI since sometimes it randomly stops sending frames. I think what I will do in this case, is to suspend guiding while the frame is downloading. This is the same process that is being done for guider chips on the same camera.

For Local, there was a bug in INDI that was introduced last week and it is now fixed, so "Local" should work again.
6 years 10 months ago #16906
The topic has been locked.
Time to create page: 0.188 seconds