My logging is set to verbosity "Regular", the log directory which is linked in the logging dialogue is empty. The files that I attached have been fetched from kstars->guidelogs and kstars->analyze. I used the internal guiding, so the guidelogs are not based on PHD2. I hope this helps.
If other logs would be better to analyze if this is a general issue I might need to change the settings for a future session (advice what to active would be great). If there is another log file on this machine that might have been active outside the kstars directory I would need directions as I'm not familiar with the OS.
Thank you for taking the time to look at the logs.
Attached the guidelogs and analyze files sorted in two folders: One ("OK") the session with successful automated flip earlier the same day. The second folder has the data of the session where after the automated flip the guiding was not resumed.
I bumped into a new problem last night. (Second night for me with the new version Kstars Stable release 3.5.5 and Stellarmate 1.60 on a Raspberry Pi ).
I ran a job of 150 exposures and after 89 exposures it triggered the automatic meridian flip but did not resume guiding thereafter though the exposures continued.
According to the analyzer (see attached screen) slew and alignment were successful after the flip and the exposures were continued but the guiding did not resume. The graph does not even show an attempt to start guiding. And looking at the images taken after the flip the guiding was in fact off.
Did the logic of the scheduler change here in the new version? I used the scheduler for the session but did not select any of the steps like focus guiding etc at the left hand side of the screen as I followed these steps manually before starting the job to monitor what happens. I used to do it like this before but so far guiding always restarted after meridian flip and in case the resume of the guiding failed it did not resume the exposures and aborted the job.
Now it looks that there was no attempt to start the guiding but still the exposures have been resumed. The job continued to the end, mount was parked. So somewhat all good except guiding was off.
Earlier the same evening in another session I took some exposures without the scheduler to test another optic on a different object. This included a meridian flip and the guiding resumed with no problem.
Any new parameters that would have to be set in the new version when using the scheduler or was this just a glitch?
Thanks, I was hoping there is a way to patch or work around this for the time being. Last night was clear but the problem is still there and I stopped attempts to reboot or influence the USB connections order after some attempts.
Ok, wait and see and try to manage the polar alignment for the time being with an older version and flip SD cards in between as the latest version seems more stable otherwise ...
I have the same issue that Polar alignment is disabled so the calculated and effective FOV in the dialogue box at the right are >90. I found several posts. (another one is indilib.org/forum/ekos/10435-polar-align...ue-to-fov.html#75957)
This chain here is marked "solved" but the solution seems to be to switch to the beta release.
Is there a way in the stable release to work aound/change a parameter etc? I don't use the beta versions so far and would need to find out how to do that. Moreover I use the stable versions mainly as the numbers of clear nights where I live is very limited (last night the first in 4 weeks).
So it would be great to understand what can be done to work around this issue until the next stable release if there is an option.
Last night was the first chance for me to use the new release. When I bumped into the problem of polar alignment right at the start I first tried rebooting and reinstalling the index files with no success. Then after finding this chain in the forum tried to switch to beta versions using the dashboard on the PI4 via VNC. This went wrong as it seem to have deinstalled parts and I finally flashed the SD card from a previous image. In the meantime I managed to polar align with a separate version on backup SD cad and switched back to the card with the latest release. Took a while and not solved for me - and maybe others.
Thanks for any ideas if there is a way in the stable version to work around for the time being.
Would it be possible as part of a profile setup to store a position (fixed Alt AZ) in addition to the parking position? There is as far as I know an option to define a wall position for the fully automated flat frame acquisition.
Could this principle be used also in a non automated mode to e.g. point the scope straight up which allows to place a light source atop? So simpler variant of the wall position that is not linked to the automated flat frame sequence?
Maybe I miss that there is already a way to store a position independent of the parking position itself by Alt AZ that one could call and for which tracking is paused until the user resumes.
Gesendet von meinem BKL-L09 mit Tapatalk
Another potential source that I found for my box after having the same symptoms that I kept losing the VNC connection:.
I was able in a problematic session to connect a LAN cable for an A/B test in the backyard and still lost connection in VNC
In the syslog file a crash has been recorded around the times when I lost connection
“612 Comm: Xorg Tainted: G C 5.10.17-v7l+ #1403
stellarmate kernel: [ 189.589306] Hardware name: BCM2711
stellarmate kernel: [ 189.589310]”
Advice from people who know how to find such things was to disable the audio driver (BMC2711). This problem might have arised with a system software update as I just use this box for Stellarmate.
Advice to solve was to open /etc/modprobe.d/raspi-blacklist.conf and add a line
Just one clear night since to confirm it is a permanent fix yet but the audio device was not an issue in the last session.
So maybe in addition to check your Wifi connection is ok you check the syslog if you find similar entries that indicate it might not be a WiFi issue,
As the problem that I experience is somewhat similar to what
describes (when turning the knobs on my EQ6R the movement of the stars is not alligned to the vectors displayed): what log should be activated to be able to record helpful input here? The weather might allow me to have a session in the next days so I might be able to get some data that might be valuabe to help to narrow it down.
PDB wrote: Hi,
could it be your mount is not level? l
Sorry, I was not clear in my description of what I think is the problem. I (myself) try to follow the purple line to the crosshair and use both knobs for this. So the workflow for me is basically like in the previous version. The movement of the Alt and Az knobs itself is at least close to orthogonal. So with a bit of trial and error I make my way along the purple line using the knobs for Alt and AZ.
With the split into Alt and AZ components in the display that you implemented my expectation was that I could use this decomposition of the Alt and Az component for the correction. So when I select a star I expected to move only Alt along the yellow line to the edge of the triangle, then only Az along the green line to the crosshair. So only care about one direction at a time. But when moving my Altidude screw on the mount the stars do not move parallel to the yellow line. Same applies to AZ not parallel to the green line.
Wrong expectation that I could move the selected star along the indicated lines, separating the Alt and AZ correction? Do I need to slew back to home before using the hardware knobs as the calculation of the vectors is based on the first position?
In case this is relevant: I start in the home position and slew 30 degrees east with each step so when I start turning the hardware knobs the mount is rotated by 60 degrees. I could see Polaris from where I set up my mount and start close to the pole. At the moment I use my main scope for the polar alignment(432 mm focal length, camera ASI 533MC). I'm not striving for extreme precision below an arcminute.
I could finally try the new polar alignment of 1.5.2 and it looks great. The circle which marks the star selected for the movement is of great help in case of correcting to fast.
However for me the alignment of the green and yellow line with Az/Alt knobs does not seem to correlate and I still follow the direct vector purple line. I would be keen to understand why that is.
The only idea I have so far is that it might be caused by the use of a dual mount where the main telescope and the guider and the main telescope are mounted side by side. So both are outside of the actual rotation axis (see attachement showing my 'home' position.)
I tried to use the dark library when I was investigating the cause of occasional bursts in DEC when guiding. I though have one maybe trivial problem when taking a dark.
When I used the dark option in the guiding tab for the first time I was asked to place a cap ( ASI 120MM). Now even when I delete all dark library files before this prompt does not appear any longer. It seems that the first image is treated as dark. But sometimes also random guide images in between which ends with lights being substracted from lights.
What would be the steps to "reset" the behaviour and being prompted to take a picture with a cap when there is no dark frame in the library?