in my experience it depends on network latency and bandwidth. If you separate the client from the server on different PCs, then all communication has to go through the network.
So, when guiding, all pulses travel back and forth and tracking could be affected by high latency; when focusing all images have to be send to the client consuming bandwidth etc.
If it's a LAN or a fast internet connection first option could work just fine.
In a remote location where only satellite network works the only way is connecting through a remote session on a local computer.
I switched from first option to the second when I moved my telescope from a 100Mb/s observatory to a remote one where connection speed (shared!) is 3Mb/s at best.
If the roof controller is a custom one, you will have to write your own indi driver to manage it from ekos. As an alternative I suggest to use the Dome scripting gateway driver that only requires custom scripts (in any language) as interface to the dome.
Sometime you'll have to restart all devices if needed. Have you considered power hubs like Pegasus upb, ip controlled plug (eg EZoutlet) or observatory controllers like Lunatico Dragonfly?
Given the equipment you listed I would say you are already an experienced remote user but just a couple of question to better focus any advice or tip.
By remote you mean the equipment is located in your backyard and managed from inside your house or the telescope is hosted in some remote farm?
Is your observatory already remote and you are migrating to INDI/Ekos or is the very first time managing a telescope from remote?
(if your message was referring to my post)
really like this new feature.
The terrain fits perfectly into the stellarium view, it feels almost real.
Thank you Hy!
As of today Ekos calculates HFR, Eccentricity, Mean background value and number of stars for each frame but these values are not saved in the fits header.
Having such information stored in the fits file itself is useful for frame selection, benchmarking and processing.
I wrote a simple python command line script that parses the .analyze log file, where these keywords are stored and save them to the matching fits file.
It is hosted on github: github.com/fenriques/astro_tools
Just download the fits_header_import.py file and launch it from a terminal window: python fits_header_import.py
Tested on Linux only, Win/Mac could have directory path issues.
As soon as Ekos will write these keywords directly into fits files, this script will be useless.
Please send feedback if you test it.
Glad to hear that it works.
There's a locking safety switch in Telescope and Dome Tabs:
In Telescope Tab-> Options->Dome locks: This prevents the mount from unparking when dome is parked.
And in Dome Tab->Options->Mount locks: This prevents the dome from parking when mount is unparked.
In my remote hosting facility they provided a device for additional security: two magnet switches fixed on the RA of the mount and connected directly to the roof hardware controller.
In park position the switches close a circuit so that there's a physical check on the mount position and not just rely on software controls. More or less the same as the laser trigger you're thinking of.
Rain / bad weather. You need to connect your rain gauge or meteo station to Ekos through an INDI driver and set safety conditions.
Then Ekos itself manages shutdown (park mount, park dome etc) if weather is not safe.
To connect your device to Ekos you can think of using a standard INDI driver or write your own.
If your rain gauge can output a text file via LAN or Serial port to your Ekos PC, as a first approach I suggest Weather Watcher driver that just need such a text file with proper information.
you could try the Dome Scripting Gateway driver. Then the scheduler triggers startup / shutdown commands through the driver itself.
The driver on the other end needs 2 scripts for opening/ closing operation but they are easier to test because you don' t need the scheduler.
There' s a recent thread on this forum discussing the syntax to use for these scripts. If I find that thread will update this msg.
I tried to find a pattern so I integrated but not registered 120x180s frames with 0.3s dithering every frame (see attached image).
The dither pattern is not linear nor related to RA or DEC. Btw the guide is not drifting: the arc is clearly made of point stars, eccentricity is around 0.3.
Do you experience the same?
1. I experience the same behavior using 0.5s pulses. My idea was to test using longer pulses like 1s.
2. It could be CEM driver related because 10micron doesn't show this issue.
There's a filter settings icon top right of the ccd&fw tab (see attached image).
Try to check the autofocus on filter change feature.