Come and join our community. Expand your network and get to know new people!
Should be fixed in commit 480e2db4
Hi, I was tracking the moon, and I used mount controls to move the mount a little bit, after a while (near the end of the log files), I gave goto order to go back to the moon location, but the pointer went far below the horizon and tracking stopped.
Why should it even matter?
WoHoo…. it's not just me!
I too had never seen this until I updated to a nightly recently.
Just to follow up, for what it's worth, my activity on the last successful Kstars use was to test a simulated CCD on my Orion Atlas EQ-G goto mount. That worked fine. Fast forward one day, and on re-starting Kstars, and trying to run both a simulated mount and simulated CCD, I am getting the same failure to unpark as the original poster. Kstars 3.4.3 and indilib 1.8.6.
Just to close this out, I solved the non rotation problem by setting the mount speed in the polar alignment section. I think it was just in an undetermined state. Once set to "max", the simulated mount moved correctly. Thanks for all the help from the forum members.
I'm seeing the same thing here! Just started happening. Yesterday, everything work fine. Today, the indi_simulator_ process is maxing out my CPU and the simulated telescope mount will not unpark. "Dome ignored" is set in the Options, although the LED by "Dome Policy" is showing yellow. Not sure what that means.
AirBourn wrote: Now that the seasons are changing and temps are falling, is there a minimum temperature I need to worry about when operating StellarMate outside in the cold?
Some figures concerning the temperature range in which the raspberry pi is expected to function normally are in the FAQ:
Now that the seasons are changing and temps are falling, is there a minimum temperature I need to worry about when operating StellarMate outside in the cold?
Hi Robert, Jaseem
I pulled the code for the libgphoto2 (lumix) library and indi gphoto driver a few months ago, and after some learning (!) and a few modifications to both, I now have ekos/indi working with my Lumix GF7.
I'm running indi on a raspberry pi 4, and I can stream the live view, capture images in both raw and jpeg with my camera connected to my wifi lan.
Thanks for a great effort in pulling all this together!
I still have a couple of bugs to iron out before I commit the code, but I thought I would let you know in case someone else is working on this too.
The changes will need to be in both libgphoto2 and indi gphoto driver for this to work, and this is the first time I've committed anything to either of these projects so please let me know if there's anything I should be aware of.
I'm getting ready to start a permanent observatory, so I thought I'd play around with the scheduler to get familiar with it, and ran into an issue.
I'm using all simulators (ccd, telescope, dome, filterwheel, weather), and setup a sequence that includes 10xL, 10xHa, 10xSII, and 10xOIII. The sequence has Autofocus if HFR > checked at Refocus every 1 minutes. I loaded that sequence with two different targets using the scheduler, with Track, Focus, Align, Guide all checked. I'm using the internal guider with SEP Multistar.
I'm using latest kstars from the stable ppa on ubuntu 20.04 amd64.
Two issues I noticed when doing this.
1. The first auto focus that happens uses whatever filter happens to be selected in the Focus module at the time, not the filter for the first capture sequence. After the initial autofocus, it uses the filter that is being used to capture.
2. When the 10xL are done, and it moves on to the next filter (Ha), capturing stops. The overview (Setup) module just shows the status as "Dithering".
After seeing the issue once, I turned on verbose logging for all the modules, and was able to recreate the issue.
I've attached my verbose logs, as well as the analyze logs, focus logs, and guide logs.
This is my first time playing with the scheduler, so I may have something configured incorrectly, but it feels like a race condition between the focuser and the guider glancing at the logs. Has anyone seen this before?
I saw that since 3.4.3. I´m using now the nightly build with my rpi4 with ubuntu 20.04. i have also <n another rpi4 with Stellarmate beta (raspbian).
the bit per pixel is wrong too for me (D5300)
What version of KStars is that with?
It is using system time. You can see that in the log messages for the mount when you switch on INDI. You get a popup with your equipment and when you go to the mount tab, you can see that it reports the time that is sent to the mount. So that is ONE problem. The other problem is that you should not move the ball head but the entire mount.
Yes I noticed that the time is wrong. But I did not fix it on system level, I just changed the time in Kstars. Might that be the problem? Is Ekos using system time instead of Kstars time?
i've noticed the same thing with my Nikon DSLR (D800, D5300). Pixel site decimal are not saved in Indo driver (only the one is saved) from Ekos capture module.
My apologies, I meant no offense.