I think you mean 23.10. If you do, avoid .10 releases with ubuntu, those are for desktop use and quite frankly, I wouldn't even use those for that.
They're for users who really want/need bleeding edge stuff.
For astro use, stick with LTS releases, so 22.04. You're not gonna miss anything.
Oh, on the subject of Ubuntu LTS, refrain from using too new LTS either. So when 24.04 will be released later on this year, don't just upgrade. Wait until 24.04.1, the first update, hits the servers. That's more or less when all the external repositories, like indi ones, catch up.
the kstars source tarball has been mis-named. It is called kstars-2.6.9.tar.xz so the version is wrong, hence the links on kstars site don't work.
This could be a good QoL change: if the user changes the value the force option should be automatically set. I cant think of a scenario where one would set a temperature and then not need it enforced.
thanks for your answer. I still need to find out the exact release in which it stops working right.
I need my friend to find the time and when I'll find out I'll report back.
Can I ask in the meantime if you can post a screenshot of when you connect the mount, what text you have on the bottom of the mount tab?
I want to find out if you too have a strange number during the location update phase and the warning about the date and time not being correctly set.
Also, what release of the Skysensor firmware are you running?
I understand this kind of computer is not that used anymore, but I'd really like to get to the bottom of this.
Any suggestions in how I can try and debug it?
I can also confirm this is the case for me. In my case I do have 2 trains, but I double checked it's the same one selected in both windows.
In the hope that someone can shed some light on this, another pointer: at the end of the connection phase with the 2.0.4 indi, along with the error mentioned in the first post the software fails to set the location too, the strange thing being the longitude (if I recall correctly) has an absurdly high number, negative also. This doesn't happen with 1.8.9.
Just to add here, I uninstalled the PPA provided indi and compiled the last version known to work, 1.8.9.
With this version it's back in working order, so it's definitely something about the new versions.
If someone could point also on how to debug it, I would be grateful.
I recently updated the install of a friend from Kstars 3.5 to the latest, I'm unsure of the indi version we had before, I can check as I still have that version on a backup microsd. This is all on a raspberry pi running ubuntu.
We moved to a 22.04 install of Ubuntu server with mate as a desktop and latest releases of all the softwares, so Kstars 3.6.7 and indi 2.0.4 and we're having a strange issue with his Skysensor.
Basically, it connects and it reads the current coordinates. If we move the mount with the hand controller we can see it moving on the skychart. Also, moving the mount manually through Ekos mount control works.
But, requesting a goto does nothing.
We also have other strange things, like the tracking portion of the mount tab being greyed out, the debug button on the indi configuration panel not sticking on enable (it gets disabled right away, even saying so in the log) and we also have a red error in the mount log at connecting time, stating "[ERROR] Error setting local time"
Everything works correctly with the old revision, so I'm looking at pointers of what could be wrong or tests that I could carry out.
Thanks Fitchie, sometimes the interface is so complete it's confusing!
Thanks for pointing it out, I've found it now!
if I may interject, I think this option should really be moved from the sequence editor to either the capture or guiding interface.
Waiting for the guide to settle after a calibration could be needed in plenty more scenarios that don't necessarily include the sequence generator.
Case in point, I never use the sequence generator, I have little time to take pics, and when I do I just configure the capture module and off I go.
Let me know what you guys think.
this post is for two reasons.
First, if you are a OnStepX on a Fysetc E4 user, for the love of all that's holy, disable DEBUG in the Extended_config.h file. The distributed one has debug incredibly set on VERBOSE on the same serial port as the communication with indi. This gets the driver to crash on multiple occasions: syncs and alignment systematically makes indi crash. This is because OnStepX is writing english sentences on the channel indi uses to communicate... a curious choice for a default!
Second, a praise to Alain for writing such a fine piece of driver. Thanks to its capabilities to write interesting stuff when in debug, I was able to figure out the mount was "talking" in plain english where a protocol was supposed to be. Obviously the driver didn't like that! So I searched for a debug option and disabled it and voilat!
Thanks Alain for writing this!