For me setting it back to "small scale" solved it, but I remember a problem that you might have as well. The options panel has several parameters that say more or less the same, I remember for alignment was not the first entry. Only when I realized there are more granular options than I expected the setting to "small scale" for the alignment (a bit futher down) did the job. Maybe this is helpful.

Read More...

I followed the instructions in the video but no log file is being created in the log directory. I just confirmed that using a simulators profile.

So let's close this as not reproducible as I do not have enogh clear nights available for experiments I'm afraid. I know that for open source projects like Kstars/Ekos this is not too helpful but now I would even have to check why no logs are being created...

Runs for me at the moment by setting the paramater back so better don't touch. I hope others can contribute more evdence how the change of the value "Small Scale" to "Default" initiated by the update is leading to problems. Jasem confirmed in this chain that I'm not the only one affected.

Still I would think for future updates it would make sense for such an automatic override of values in the options or in case changes of the underlying code might change the effect of a setting, this information (changed from -> to) should be transparent to users quite prominently. In case something is broken after an update, there is at least a chance to follow up this route. The alternative is to not update at all as even playing with two SD cards bears the risk of losing a clear night when running the gear automatically which is for me a key factor in using Ekos..

I remember that the changes of the parameters of the internal guider in the past when they were aligned to PHD2 meanings was communicated in a transparent way and it was clear that users needed to take care of their settings after the update

Thanks!

Kind regards,

Alex

Read More...

Hi Jasem,

I have at least various analyze files and will send them to you via PM. I hope it gives you some indication.

Kind regards,

Alex

Read More...

I can confirm this problem but would even consider it being a bug.
I lost one night as I was not able to narrow it down the problem after I triggered the update function and the Align process stopped to work reliably and I was not aware of this post. I could use a number of clear nights (first time this year we have some in a row) to check. Setting the Align profile back to Small Scale in the options switched it back to rock solid autonomous operation.

Why I consider it a bug and not just a matter that "Default" should cover most cases:
1. Platesolve worked for me with no problem for polar alignment where the profile was "Default" and not "Small Scale" as well at the same time with the same setup, same exposure time etc.
2. First solving in the Align tab always worked. After this it reportet "not enough stars" and switched to blind solve. Only here and there the solver worked and I could not get to the target. Clearing the mount model did not help. After one successful solving the next attempts did not succeed (or very rarely every 7-8 attempts, automated scripts already stopped before)
3. Quitting kstars and starting the app again led to the same effect: again for the first plate solving in the align tab worked, the rest failed

The fact that it works once with the setting default is for me an indication that it is not just a matter of the general setting "Default" or "Small Scale" for the Align Process. Maybe I'm wrong, but I could recreate that behavoious with my equipment.

Hope this is helpful.

One wish from my side: If a parameter in the options that exists before is actively being changed by an update, could we make this transparent as part of the update procedure (Changelog text file?) or instead recommend users to switch rather than just doing it? This would give back a bit control. Assuming best intention to "improve" things, as a user I feel rather blind to sort out what could possibly be wrong when something that never grabbed my attention suddenly faiis.

Read More...

Hi Ron,

Tanks for this. In particular option 1 sounds clever as I don't care about the exakt final number of frames but rather look for a smart way to manage files. I need to set up my equipment for every session in my backyard and only when there are two nights in a row I could leave it set up and add frames. As I travel frequently I kicked off some weeks ago a second night session from abroad. It was nice that the cooler kicked off at the time the session started as I was not able to dial in live. So using the scheduler to run a pre-prepared session is for me an attractive use case to be productive even when I cannot attend the start.

Cheers,
Alex





Gesendet von meinem SM-T510 mit Tapatalk

Read More...

I've been pre-programming capture sessions via the scheduler for the last few nights, and everything is currently running stable in the new 64-bit version. At the end of astronomical twilight the scheduler starts the jobs, at the end of the night it parks. Great stuff.

Even though I seem to know what to do,I feel that I use some workarounds as I do not understand the logic in some places, what to enter in Capture and what to enter in the Scheduler. Maybe someone can help me figure out where my logical error is.

I create sequences in the capture module and save them. As an example 90 images at 120 s with the correct camera gain and offset settings. I save this as a Sequence Queue (ESQ) file. In the scheduler, I specify the object name, then I load in the Sequence file and add that sequence to the scheduler. Press play and the night can come

In my understanding the ESQ file is simply a sequence for the camera but independent from the object. In the scheduler I assign this sequence to an object and add it to the list of the scheduler. But this separation seems not to be the idea of the programmers.

Two examples of what I do not understand and why I currently manipulate the esq files in the text editor. Both parameters belong for me rather in the scheduler than to the inputs from the capture module, because I re-use the same sequence file for different objects in the scheduler:

1. When I apply the same sequence to the same object in another night to add more images, the scheduler reports the job is already done. Reason is apparently that the file path for the images stored in the esq file is used. Although I set to include timestamps in the filenames so there would be no naming conflict, the sequence is considered to be already done. If I change the folder name in the esq file, everything runs as expected, just to a separate folder. But I have to keep editing the esq files and can not use a library of e.g. numbers of exposures which I could simply apply whenever needed.
2. There are some relevant options in the esq file, including the "Temperature force" option, which cools the astro camera first and only then starts the acquisition. I use this to avoid having to manually turn on the cooling beforehand, but wouldn't know how to include this default via the user interface when creating the esq file (or do I really have to switch on the cooler when saving the file just to have it in the file? I do that in the daytime). Currently I manipulate the esq file with the text editor and that works ok. As cooling settings should be valid for the whole night, I miss the counterpart to "Warm CCD" in the shutdown procedure in the scheduler for startup.

Chance is you are not using the latest stable release. Quick fix: deactivate the tickbox "Meridian Flip - Flip if HA>" in the mount tab. In the latest stable release this problem (for my setup a problem in the EQModMount driver) has been fixed. We'll in theory according to the displays since I had no clear night's for 3 month to confirm.

Search for Polar Alignment Problem in this forum for more details.

Gesendet von meinem STF-L09 mit Tapatalk

Read More...

Not sure what the difference is, I run it on a Pi4 B as well. I freshly installed Stellarmate from a download image last October. after I had several issues with the update chain as it seemed. I found a hint on this VNC setting in a forum post so I am apparently not the only one who sees this. I'm a strict user though and have no idea what might cause if this is being displayed or not I'm afraid.

Gesendet von meinem SM-T510 mit Tapatalk

Read More...

Back with access to my Stellarmate box here is a screenshot (very classic screen shot as I cannot seem to do one on the computer while being active in the VNC area) which illustrates what I see and refer to on 3)
  

I work with an external USB 3 Wifi adapter as well. Here are some challenges I observed which might be helpful:
- If you work in a home Wifi with several repeaters check if you did the setup at a different location than the actual observation site. I did and it turned out that the WiFi adapter connects to a hardware but not to the Wifi network in general i.e. it tries to connect to a certain box even a repeater in the network with the same SSID nearby provides a much better signal. Indicator: when testing indoors things seem to work much more stable
-Check if besid the WiFi dongle the Raspberry is still connected to your home WFi directly, If so, supress this connection in the network settings (main menu)
- Check the VNC settings (icon aat the top right of the Pi desktop) and uncheck that it disconnects when the connected device is inactive. I don't have a Pi around to check the exact wording at the moment

Maybe one of these things could help you to get closer to the root cause.

Gesendet von meinem SM-T510 mit Tapatalk

Read More...

Peter, thank you for sharing these insights. Worth considering to vary conditions like east/west with the same software version to see what happens.
Alex

Read More...