the crash of kstars was due to a default gcc option when building 21.04 packages and has been fixed now.
Read More...
Hello,
I've reported a bug on the KDE bugtracker with kstars-bleeding (from the unstable PPA) on ubuntu 21.04, which happen as soon as you start the application.
I've provided a backtrace, but is the KDE bugtracker the prefered way to submit a Kstars bugs ?
Thanks
Anthony.
Read More...
So ... you can now [SOLVE] this one
Anthony.
Read More...
Hello,
same problem as explain in this topic indilib.org/forum/mounts/9705-problem-to...mod-with-ubuntu.html (where I attached a log file)
An EQ6-R (with pegasus eqdir cable) on an Ubuntu 20.10 with ekos/indi 5.3.5/1.9.0 from the stable ppa.
Crash one or two seconds after the connection.
Anthony.
Read More...
sure:
[2021-05-24T00:38:01.588 CEST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] Connecting to /dev/serial/by-id/usb-Pegasus_Astro_EQDIR_Stick_PA40UU16-if00-port0 @ 9600 "
Hello,
I've the exact same problem on an Ubuntu 20.10, with the last kstars/indi from the stable repo. (3.5.3 / 1.9.0)
When I connect the eqmod driver, I seems to connect (all the tabs appears, and looks good) then one or two seconds later, it crashs.
I've attached a logfile. It seems to have a connection issue at line 523. It also complains the port is already used sometime, but it's not the case
I tested the same mount/cable on a Macos with the last kstars (3.5.3 with indi 1.9.0 embedded) ... it works perfectly well.
I tested the indinighly PPA ... (indi 1.9.1) and have the same problem.
I've to admit I had some issue on linux with all my "serial" device since upgrading to 1.9.0 (for example my PPBA powerbox is hard to connect sometimes...)
I never had any issue with the same ubuntu with indi 1.8.x.
Don't hesitate to ask me anything needed to find the problem.
Anthony.
Read More...
Hello,
The Ubuntu stable PPA doesn't contain GSC packages for Groovy (20.10).
Any problem with this ubuntu release ? or just not done yet ?
Thanks
Anthony
Read More...
Hello,
I just had my first 100% automated night using the Ekos scheduler. It was near perfect !!! but I had some small issues coming from misunderstood concept, so I have now some questions I scheduled two targets, one was high in the sky early, the other after 2am, so I use an object altitude constraint (>65°).
My first questions are :
- The first target drop below the 65% constraint at ~90% of job done, but the scheduler pauses until the next day, pausing also the second job, so I had to delete the first target to start the 2nd one (may be a "live" reorder has been enough ??)
- Is the scheduler able to start a job "in the middle" of another job with less priority - as soon as the highest priority constraint is reached - and then resume lowest priority job when it's finish (assuming the low prio job doesn't have any constraint so it can start before the highest one)
- what is the mount behavior between two targets when there is some time to wait between both ? does it park ( even with preemptive shutdown uncheck)
- Is there any examples of startup/shutdown scripts more complex that the one in the documentation ? (using indi to talk to devices for examples...)
I also had a display bug in the job list : the end time of the running job decreases each time a frame was done (it seems its calculated this way : start time + job remaining time instead of current time + job remaining time)
I'm using kstars 3.5.0 nightly build
Thks for support and for this amazing tool !
Anthony.
Read More...
What an explaination
So yes, I was always starting my DSLR (and then ekos) in Bulb mode... so it explain why it was working w/o bulb force
Anthony.
Read More...
@Herrhausen, Are you sure Force Bulb to ON has any effect when camera is in bulb mode ? i've not seen any difference in my tests.
Anthony.
Read More...
Hello,
I'm using kstars/ekos with a 5D Mark III and experienced problems when it was time to capture flat frames.
The 5D mark III is part of the canon DSLRs where the bulb mode is separated from manual mode on the dial.
I've try to make some test to clarify things, here is what I've noticed :
Hello, I'm working on a INDI client and while testing it I had a strange behavior with the CDD Simulator CCD_COOLER property.
When I set the vector to :
COOLER_ON=On, COOLER_OFF=Off
no problem, the property vector is perfectly changed, but when I want to stop the cooling, sending :
COOLER_ON=Off, COOLER_OFF=On
it's strange : first I received a setSwitchVector message with the correct updated state, but then immediatly the indi server send me a new one where COOLER_ON and COOLER_OFF are both "On" (strange for a "One Of Many" switch)
Between thoses two updates, I received a message saying the sensor has reached the temperature.
I first believed an error in my code, but a simple telnet in parallel show me the same values.
Any ideas ? This is the only switch having this problem, may be a bug in the simulator drivers ?
Thks
Anthony.
Read More...
So, I've been able to reproduce the problem. For this, closing/restarting kstars hsn't been enough.
If :
- reboot my computer
- start kstars
- open Ekos and connect simulators
- add a new sequence without changing the pre-filled "Directory" parameter
- start the sequence
then, Ekos is not incrementing the frame index in filename.
As soon as I open the browser UI of the "Directory" param, no problem anymore (even if I restart kstars, this is why I suspect a link with OSX app permissions)
Anthony
Read More...
wcreech19, I don't know stellarmate, but in this case, kstars/ekos is on the stellarmate board ? or do you connect it through INDI on a computer with its own kstars ?
In the first case, it can kill my diagnostic, because there is nothing about OSX and its permissions system in your stack. Btw, may be re-browse the destination folder can have some effect in ekos, so it would suggest a bug somewhere ? I've been unable to reproduce it since a rebrowse, even after a kstars complete restart
Anthony.
Read More...