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.

How do you guys do this if you want to shoot the same object on different nights? How do you specify that the camera should be cooled before startup? Are you manipulating the esq files as well? Am I missing a dialogue and the same could be achieved much easier?

Thanks for sharing your way of handling the settings in Schedulder and Capture modules.

Alex

Read More...

Alexander Weis replied to the topic 'Re:Polar alignment disabled' in the forum. 4 months ago

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...

Alexander Weis replied to the topic 'Re:Re:Wifi issues' in the forum. 4 months ago

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...

Alexander Weis replied to the topic 'Re:Wifi issues' in the forum. 4 months ago

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)
  



Read More...

Alexander Weis replied to the topic 'Re:Wifi issues' in the forum. 4 months ago

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...

Hi Max, It was in a thread on the problem with the polar alignment with EQMod in the current stable version. Maybe somewhat hidden in the actual thread topic which is why I thought to repeat the question as a separate topic.hoping that someone knows.

The delta for the calculated deviation of the Polar Alignment between the 2 versions is reproducible around 3 arcminutes which indicates in my view something has changed in the code of the apllication or the EQMod Mount driver. At least I would be keen to understand what it is.

Read More...

Alexander Weis replied to the topic 'Re:Dark Flats' in the forum. 4 months ago

If you are using e.g. a T-shirt in the twilight in combination with the auto exposure function for flats, the resulting exposure time will vary naturally between sessions.

How about the capture module would offer the option to read the capture settings from an existing file? If one uses the auto exposure for flats you could read out at any time later what is needed for darks that correspond to a flat.

When using fixed exposure times and a dark library like I do, this could be used the other way round to create flats in line with existing darks.

There might be other use cases, when you perhaps want to add more exposures of the same target after a while. A sample from the previous series could serve as a reference to recall the exposure parameters - reducing the risk to set a parameter wrong accidently.
.
Just a thought to keep such a potential extension simple to follow and flexible beyond the single use case of flats->flat darks.

Gesendet von meinem STF-L09 mit Tapatalk

Read More...

Alexander Weis replied to the topic 'Re:Dark Flats' in the forum. 4 months ago

Hi Nick, my post was a reply to Giles but crossed in the timeline with yours. I have no issue aat all if this was addressed to me. My first post in this thread highlighted that for users of flat panels the option to build a job from a dark frame might be useful. So just the other way around in order. That for me doesn't exclude the other idea but only highlights that depending on the equipment used for taking flats there is not just one direction for creating jobs with settings based on existing images.So variable exposure times using the auto function in Stellarmate: Transfer settings from flat to a dark job
Fixed exposure times when using flat panels: Transfer settings from dark to new flat job

Read More...

Alexander Weis replied to the topic 'Re:Dark Flats' in the forum. 4 months ago

Thanks for summing up the definitions. I have a CMOS camera and I was clear. The topic of the thread in my view started rather to include "dark flat" in the dropdown for exposure jobs.

I use a controlled artificial light source for flats. With this I used the function to find good exposure times in Stellarmate only once per filter/scope/camera setup. Since then I always use the same (rounded value) exposures time for flats and the corresponding (flat) darks.After this one off determination of the exposure time the workflow is then separated for (flat) darks (I use a library) and flats (every session). So I don’t take darks in every session. A bit lazy but works and saves time.

Read More...

When trying to solve a problem with polar alignment I systematically switched between two stable versions of Stellarmate in the same night. As a side effect I noticed that with no changes in the scope orientation I got different results for the remaining PA error. I could recreate it by different runs that the versions came to the same results but the results of the versions were different.Using 3.5.2 stable the error was displayed to be 0'22"
Using 3.5.6 stable without touching the mount the residual alignment error has been 3'31'The difference of about 3 arcminutes could be recreated in several runs of the same setup. (EQMod diver for the mount)Did the algorithm to calculate the alignment error change? Is it an update of the mount's driver?Anyone has another measurement option at hand (and clear skies grrr….) to check what version of Stellarmate is closer to the truth? Hopefully the latest release is the one that is closer, but it would be good to know.

Read More...