×

INDI Library v1.9.0 Released (23 Apr 2021)

Major INDI Library release v1.9.0 bring significant internal changes championed by @pawel-soja to modernize core INDI Library drivers and clients. New drivers for DeepSkyDad Flat Panel & Pegasus devices plus further improvements to PCM8 drivers.

New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

  • Posts: 80
  • Thank you received: 9
I just upgraded and got the latest Kstars - Build: 2020-11-23T10:39:52Z. It won't solve. As the image comes in it prints "Image received", then Kstars goes away after about half a second. Here's everything I could gather on it.
Align settings:
 
[Align]
AlignExposure=3
AstrometryImageScaleHigh=26.396791751972
AstrometryImageScaleLow=19.939342695702
AstrometryPositionDE=56.736666666666665
AstrometryPositionRA=12.508333333333333
AstrometrySolverType=1
SolverBackend=0
SolverBinningIndex=1
SolverGotoOption=0
 
Align logfile:
 
#KStars version 3.5.0. Analyze log version 1.0.
 
AnalyzeStartTime,2020-11-27 18:21:56.699,MST
MountState,0.000,Idle
MountCoords,1.089,326.6833,-0.0161,196.0467,55.3889,-1,9.0333
AlignState,25.617,In Progress
 
 
 
syslog:
 
Nov 27 18:38:32 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: LX200 Autostar :  "[INFO] Device configuration saved. "
Nov 27 18:38:36 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: LX200 Autostar :  "[INFO] Time updated, updating planetary data... "
Nov 27 18:38:42 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: LX200 Autostar :  "[INFO] Site location updated to Lat  33:32:17 - Long  247:49:05 "
Nov 27 18:38:42 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: LX200 Autostar :  "[INFO] Observer location updated: Longitude (-112.182) Latitude (33.5381) "
Nov 27 18:38:44 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.ekos.align: "Capturing image..."
Nov 27 18:38:44 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: SBIG CCD :  "[INFO] Taking 3.00s exposure on main camera... "
Nov 27 18:38:50 Poopster org.kde.kstars.desktop[30749]: Found one coordinate representation.
Nov 27 18:38:50 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.ekos.align: "Image received."
Nov 27 18:38:50 Poopster org.kde.kstars.desktop[30749]: kstars: symbol lookup error: /usr/local/lib/libgsl.so.23: undefined symbol: cblas_dnrm2
Nov 27 18:38:50 Poopster systemd[997]: gnome-launched-org.kde.kstars.desktop-30749.scope: Succeeded.
 

Does anyone know what might be causing this problem?

TIA
Dave
Dave Allmon

12" LX600
SBIG STF-8300EN
Raspberry Pi 4 Indi server
Linux client
6 months 3 weeks ago #63514

Please Log in or Create an account to join the conversation.

  • Posts: 2482
  • Thank you received: 668
This sounds to me like a library linking issue on your system. I am not 100% certain, but KStars is linked to GSL and GSL is linked to the CBLAS library. Either the link to CBLAS is broken somehow or maybe CBLAS is out of date? That is my best guess.
6 months 3 weeks ago #63519

Please Log in or Create an account to join the conversation.

  • Posts: 80
  • Thank you received: 9
Thanks for the quick reply.

I thought that was the problem, but when I looked at the GSL library docs, it says they no longer link to gslcblas, leaving it to the application programmer to link the CBLAS library of their choice. I checked the indi cmake files and there is no mention of a CBLAS with any recognizable name. The libgsl has a 106 undefined symbols, all of them beginning with "cblas_".
To link against the library you need to specify both the main library and a supporting CBLAS library, which provides standard basic linear algebra subroutines. A suitable CBLAS implementation is provided in the library libgslcblas.a if your system does not provide one. 


Perhaps there is an older version that includes cblas.

Thanks,
Dave
Dave Allmon

12" LX600
SBIG STF-8300EN
Raspberry Pi 4 Indi server
Linux client
Last edit: 6 months 3 weeks ago by David Allmon.
6 months 3 weeks ago #63520

Please Log in or Create an account to join the conversation.

  • Posts: 80
  • Thank you received: 9
For the time being I've gone back to the standard KStars release (Build: 2020-02-24T06:23:39Z). I'm going to rip everything out and reinstall during the week. I have clear cold skies and need to get some observing done.

Thanks for identifying the problem!

Dave
Dave Allmon

12" LX600
SBIG STF-8300EN
Raspberry Pi 4 Indi server
Linux client
6 months 3 weeks ago #63533

Please Log in or Create an account to join the conversation.

  • Posts: 2482
  • Thank you received: 668
Yeah, sorry I can't help more. If the problem was with StellarSolver or with the Mac version of KStars, I could help you a lot more, but I am not an expert on library linking on Linux systems.
6 months 3 weeks ago #63534

Please Log in or Create an account to join the conversation.

  • Posts: 732
  • Thank you received: 94

Not clear to me whether you use a self-compiled version, or installed a package? The gsl stuff seems to be in /usr/local, so it looks like that also is a self-installed one?
As I understand it, the gsl installation should (via gsl.pc) tell what should be used? At least on my system I have
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include
GSL_CBLAS_LIB=-lgslcblas
 
Name: GSL
Description: GNU Scientific Library
Version: 2.6
Libs: -L/usr/lib64 -lgsl ${GSL_CBLAS_LIB} -lm -lm 
Cflags: -I/usr/include
and kstars uses that info to properly link against gsl and gslcblas.
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
6 months 3 weeks ago #63581

Please Log in or Create an account to join the conversation.

  • Posts: 80
  • Thank you received: 9
Well, everyone was right. Although I did not build anything, or install gsl or cblas0, they were messed up. I reinstalled them to no avail, as evidenced by the fact that siril blew up in exactly the same way KStars did while trying to register images. I reinstalled the OS, installed KStars and Siril and all is well. I am not using the bleeding-edge version, but I will tonight.

Thanks to all.
Dave
Dave Allmon

12" LX600
SBIG STF-8300EN
Raspberry Pi 4 Indi server
Linux client
6 months 3 weeks ago #63588

Please Log in or Create an account to join the conversation.

  • Posts: 309
  • Thank you received: 13
This is more comment than question, but I think this is the right group to bring this to. I installed Kstars release 3.5.0 on my Win 10 (64 bit) Laptop, 2 days ago. Last night was the first time I used it to actually run Kstars/Ekos, as previously I was running everything on the Rpi 4 (4 Gb memory at the scope) and just using the Laptop as a connection point. The release on the Rpi is an earlier one, but working fine in all points (except as I have said elsewhere it would loose connection to the server after working great for several hours). I ran the solver last night (after loading the index files needed for the FOV of my main, guide and finder scopes) and ran into several failed solves (that had seemed to work during PA when using the Rpi). I am finding that during PA, I need to turn off "use position" in the solver options to get the solver to work well. I PA first with my E-finder scope (ZWO ASI120MC on an Orion 9x50 finder) as that has a large FOV. Then PA with the main imaging camera (ZWO ASI533MC on the SCT 9.25, currently at F6.3). I noticed that after solving with the E-finder EKOS reported that the focal length of the scope (from the solve) differed from what I had entered (I entered 186 mm and it found 176 mm FL). I could only get it to reliably solve if I went and changed the focal length of the Efinder scope in the main configuration setting. Just want to let you know there is some sensitivity there in terms of the pixel scale.

The solves, when working, were extremely fast.

Initially, I attempted to use the astrometry on the Rpi as I knew that was working, even though I was running Kstars on the laptop. So I added Astrometry app, to the Server configuration. But I could not get that to work. As soon as I would start a solve (I selected the 'remote' button in EKOS Align and made location entry changes in the astrometry tab) it would fail and the Astrometry button would change color to 'disabled.' This may be a mute point (or something to be addressed later) as I will probably continue to use the solver on the laptop (it was so fast). But then I question the need/use of the Astrometry APP in the EKOS configuration. Isn't Astrometry always loaded if it is being used on the machine you are running Kstars on? I assumed the purpose of having it in the Server configuration was to use Astrometry on that local machine. I was assuming that since I am saving the images on the Rpi (to a large USB memory stick) that the solve might be faster as the data was there. But I guess the image data gets loaded up to Kstars wherever over ethernet (as I am connected to the Rpi) it is fast enough not to notice any lag.

The changes and updates to this release are amazing, while the capability of this program can be overwhelming, I hope the documentation can keep up!

Thanks for all the hard work and effort going in this.
Ron
6 months 3 weeks ago #63683

Please Log in or Create an account to join the conversation.

  • Posts: 2482
  • Thank you received: 668
So at this point, using the remote solver using the INDI driver astrometry solving with the PI is more of a legacy method of doing things. By far the best way to plate solve is to solve on whichever laptop is running KStars, and usually that computer tends to be the faster one. The "remote" method using the INDI Astrometry driver primarily existed because in the past, it was not easy to install astrometry.net on Windows or Mac and get it all set up to work really well with programs like KStars. Basically it provided an easier way to get it all set up. But now that I made StellarSolver, it isn't really needed anymore since you can now solve internally in KStars. We didn't want to completely get rid of the remote method in this release because a number of people already have their system all set up to use "remote" solving, but if you are using that method, I would definitely recommend transitioning if you can.

For the stuff you mentioned in the first paragraph, those are things with KStars, not really the solver, so we will need to look into these kinds of things to make the performance in KStars a little better. We did a whole lot of work integrating it into KStars, and it probably isn't all perfected yet, but its close.

We will have to work on the documentation, yes, I know I have had a lot of other work in my job etc, and it took quite a lot of work to finish StellarSolver and get it all integrated and working. I just haven't had time to look at documentation. You are right though.
6 months 3 weeks ago #63686

Please Log in or Create an account to join the conversation.

  • Posts: 4
  • Thank you received: 0
So what solving method do you suggest for me? My rpi4 at the scope running astroberry with kstars 3.4.x does it all currently with only an external computer (or iPad) necessary to setup the schedule and polar align. The Indi platesolve works well in this scenario. I assumed the updated solver would also behave well in this use case, but from the last post it sounds like a laptop/ external computer is recommended. - or did I miss something?
6 months 3 weeks ago #63708

Please Log in or Create an account to join the conversation.

  • Posts: 309
  • Thank you received: 13
I can only relate my experience as I am not involved in any of the development. I went to a laptop to run Kstars, because I felt I was over burdening the Rpi4. But the plate solving was not the problem, it was later on in the imaging sessions that I had problems with server disconnects. Tonight, I ran Kstars from the laptop and things went well (solves were very fast), but later on while guiding (with Phd2 running on the Rpi) and imaging from the Laptop, the whole system got very sluggish, and I don't know the cause of this yet (have to look at the logs and see if they tell me something). Eventually, the response got so bad, on the laptop (several seconds to respond to a mouse click) that I just stopped everything and restarted. But then clouds moved in and I just ended the session. I think you have to find out what works best for your setup and stay with that. The Rpi seems capable to handle all the task individually, but at sometime later it just seems to run out of gas.

At this point it has become a very complicated system that has wonderful capabilities (like Polar alignment assist, plate solving, guiding, etc), but there is a price to pay in system performance, especially as we try to move to smaller computers (like the RPi) at the equipment. But my experience tonight says even that may not be the limitation.

Ron
6 months 3 weeks ago #63709

Please Log in or Create an account to join the conversation.

  • Posts: 1114
  • Thank you received: 182
I use a Pi4 with 8 Gb and have no such problems with it except fir the occasional loss of WiFi connection.
I think I have overcome that by using an external WiFi dongle.

I am also using an external SSD for image saving, astrometry files and a Swap partition.

And I am running Ubuntu 20.04, not Raspbian OS. Looks to me the Pi has a lot of power to spare with that configuration.

Jo
Atlas Pro AZ-EQ, ASI1600MM-Pro, ASI120MM-S, ES102ED, WO-Z61, Nikon D3300, ASI-EFW, ZWO LRGB,Ha,O3,S2 filter set
6 months 3 weeks ago #63710

Please Log in or Create an account to join the conversation.

Time to create page: 1.264 seconds