A bit of a hack ... well thank you!
As a longtime Unix/Linux user, this has happened before. And, no, the consequences are not unexpected. I've never had it blowup on me. So, yes, one can wait for a software update that corrects the problem. But, if you had a planned observation for a night, and waiting is not an option, a simple link (or copy) to solve the problem is an easy fix.
Find libindiclient.so.2. On my computer that file is in the directory /lib/x86_64-linux-gnu.
Type sudo ln -s libindiclient.so.2 libindiclient.so.1
That will create a link between so.1 -> so.2
kstars now starts
Hamish and Magnus: Could you please post your optical trains? Jasem will likely have a better take on the data than I.
I have some spectroscopy files from my latest observing sessions in November and the DATE-OBS field is present. I don't understand the connection between plate solving and the appearance of the observation date, or how a spectrometer affects whether the field is present. INDI/Ekos isn't aware of a spectrometer.
Something I did notice: in my FITS header there is always a "Comment Generated by INDI"
FWIW, i did not see a similar line in the header from Magnus.
Here's something I just learned.
Recently I've not been able to guide with the internal INDI guider. Program would say starting RA drift, lost star, then give the usual admonition about larger box. The internal guider had always worked before so I started asking: what has changed?
The optical train specification was the first thing that came to mind. In the secondary train, I have a Lodestar as my camera to do the guiding. What I finally realized is that, at the end of the optical train row, I have to specify the mount (CGX-L) as the guider! Once I did that it all worked again.
The instruction videos need to include these optical train descriptions.
Oh yes. Got to this webpage
and scroll down until you see the header Nightly Builds. You want to add the repository for the nightly builds as shown, then apt-update, then install the programs (kstars-bleeding, indi-full).
I think, but am not sure, you need to remove the stable repository in order for this to all work. To remove the stable repository, type
apt-add-repository remove ppa:mutlaqja/ppa
Jasem is certainly a better authority, but the short answer is Yes, you can update SM without resorting to a key. By a "key" I assume you mean downloading a version onto a thumb drive and flashing the small card that plugs-into the SM.
For example, Linux distributions often update the kernel with the updates installed via a program like apt or yum. The same holds true for updating the Rasberry Pi OS. Updates to Ekos are on a bi-monthly basis and I doubt it's expected we would all go flash new cards every two months.
Hope this helps.
Last night I put the scope on a well populated star area to do a plate solve. The parameters in the "Plate Solving" tab (FL, FOV of guide camera, etc) were as one would expect without a focal reducer. The value of the focal reducer (0.7) was also displayed.
Attempted a plate solve and it failed. Got the usual error message.
I tried to change the aperture and FL parameters, but they were locked. The software would allow me to change the guide camera FOV to reflect the FR. Attempted another plate solve: success. I went to another tab and when I came back to the plate solve there were parameters just like yours where it looked as if the software applied the FR in the wrong direction. However, the guide camera FOV was now correct. I did another plate solve just for verification.
I see Jasem says he has it fixed in the latest build so we can try it out.
I may be having a similar problem. With the latest version of kstars-bleeding, I enter my "optical train" data including a 0.7 focal reducer. In the Alignment Module, the telescope focal length and plate solver camera parameters (which is my secondary) are correctly shown for a telescope without a reducer. The reducer value of 0.7 is also shown.
I've attempted some plate solving recently with the FR and I always get the "Not Enough Stars in the Picture" and "check FOV data" even when there are lots of stars in the frame. This function worked fine before I added the FR.
I had this happen to me once and it might have been at the same time as Morelli's problem. I'm guessing the Ekos computer that handles the update (and upgrade) requests was down at the time. When I tried later in the day, everything worked fine; I was able to update and upgrade with no problem.
If anyone is having problems restarting SM OS 1.7.3, the short answer is to do an orderly shutdown using the Logout button on the SM main screen instead of just "pulling the plug."
SM got hung-up trying to do a s/w update, thought it was finished when it probably wasn't -- anyway, became a brick. No big deal. I downloaded the latest OS, burned the chip, did the usual setup like specifying the IP address, This was all done "on the bench." Loaded some packages that needed updating. Turned off the power, put the unit in the observatory, turned power on, etc. Went back to the control room -- nothing! Couldn't do a simple ping.
Brought the unit to the bench, connected, got a boot error. I thought maybe some part of the updated s/w packages caused the problem. Burned the chip again, did not add any packages, redid all the setup stuff, etc. Turned off, re-install in observatory, probably turned it on and off a few times as I'm connecting the wires, etc. Go back to the control room -- again, can't connect! Back on the bench. Boot error with last line "End of kernel panic." Never a good sign.
Burn the chip again, do all the setup stuff. Asking myself: what could possibly be the problem? With the previous OS, whatever that was, I never had a problem restarting SM although it was seldom that I cut the power. After completing the setup, this time I did a shutdown from the Logout icon. Did this 6 times. On 4 out of the 6 shutdowns, the SM seemed to close in an instant. On 2 occasions, however, the big SM icon came on the screen with the scrolling dots underneath and it took about 20 seconds to finally halt. In every case, the SM rebooted successfully when power was reapplied. Maybe sometimes doing an abrupt power-off left the SM in a bad state.
I went through the SM manual and I did not find any admonition that says something like "Always do an orderly shutdown -- do NOT just power-off." Regardless, for now, I'm always doing a s/w shutdown before pulling power from the SM.
Thanks. So here's what we have.
When I choose the Aux software the responses are
2022-10-14T22:51:32: [ERROR] Cannot continue without connection to motor controllers.
2022-10-14T22:51:32: [ERROR] Got no response from target ALT or AZM.
whereas before I got simply can't connect with the "standard" USB port. So it seems we've made progress; don't know what to do from here.
In the port type there is a selection between AUX/PC and USB/HC. Don't know what this means. Seems to make no difference.
I control my Celestron mount through an interface with the hand controller. Works OK but a little kludgy. Many mounts, including some Celestrons, have a type-B USB connection labeled PC Interface in the side of the mount. When I connect my Stellar Mate to this type-B USB, SM creates a entry called /dev//ttyACM0. When I start Ekos and attempt a connection to this interface, it fails.
So the "wish" is to have those type-B mount interfaces available for connection.
Yes, that's what I did following your suggestion via a VNC connection and the SM terminal window. Time and date are now set.
The rasberry-pi link will be useful. Already did a quick scan.
One thing we don't have here is internet except via the hot spot on my cell phone. Always makes things interesting.