yoandresmza wrote: SUCCESS people!!!
As far as I know, no. In INDI Roll Off Roof drivers are a subset of Dome drivers: they share the same parent classes but with limited functionalities. E.g. no shutter, no CW / CCW rotation etc.
Taking Ferrante and Bundy's scripts as an example I managed to make it work !!! I am more than happy!!!
Thanks a lot, without your help I would not have made it.
Now I can automate my observatory much better.
Question: Is there another dirver similar to this one to run scripts but is it for a Roll Off Roof?
I also want to do something similar for my DIY dust cap and be able to include all these devices in my STARTUP and SHUTDOWN procedures. Is there any that I can use?
I've not been using this driver for a long time and I completely forgot that there are template scripts to implement.
The instructions are at the following link:
The bottom line is that the driver reads 3 digits from a file (/tmp/indi-status) every n seconds.
You just have to update those 3 digits. For example, 1 0 0 means park.
And in the same script you have to include your bluetooth commands.
Andres is able to execute the unpark script from command line so the script should already have the right user/group permissions on the connected devices.
On the other hand, it could be that the indi user and the script user belong to different groups.
Andres, just to understand if it's the script or the driver: what is the output if in your script you only write in it:
I'm not using the Dome Scripting Gateway since a long time now. And trying to launch it from the nightly Kstars / Ekos version it raises an error and doesn't start.
Anyway, have you checked the right user / permission on the script?
Can you share the driver log and the source of the script? that could help to understand what is the issue.
Reading the .analyze file is quite straightforward thanks to the descriptive naming you added to the events.
Astrodom keeps track of imaging frames only, so the main source of information (beside reading fits headers) would be the CaptureComplete tagged line.
To me it would be nice to have on that line also data not directly related to the frame. For example, average RMS during capture and SNR.
Other capture related data like eccentricity and noise would also be nice to have, when will be available. I would rather read those from .analyze than from PI because have to run SubframeSelector first.
hy wrote: Ferrante: wasn't aware of Astrodom, looks very cool. Take a look at the .analyze files and in particular the method processInputLIne()
Note that I'm monitoring real-time processes, so some signals come in in awkward ways.
Let me know if there are other things you'd like to see in the file, or perhaps something like a header line that might make things more future proof.
Right now, the file has no header lines, but there's no good reason for that omission. I guess it does have a version header
#KStars version 3.5.0. Analyze log version 1.0.
It is very early in the evolution of Analyze, it's possible that I'll change the file format...though I have no such current plans.
Of course it would also make a lot of sense to make sure people can real old logs...
Still thinking this through.
BTW, I'd love to include more capture-related analysis (like you get from PixInsight files). Right now the only signal computed
is the HFR. I was waiting on @Rlancaste's StellarSolver software release, which was planned for KStars v3.5.0, as it was a
rework of the whole SEP/Sextractor framework for KStars. Not sure of his schedule, though.
awesome work! thank you. All the insight needed to monitor and review the session in one window; to me it should replace the Setup tab.
@Rick, I'm thinking to use the .analyze file as the only source of information for Astrodom. What do you think?
I read that a model can be build inside Ekos but I prefer using MountWizzard4, really a great software.
It runs on Linux/Windows/Mac and it helps you to polar align, build model and analyse your model's problems (e.g. flexure).
there's a thread on Github where there are additional details:
I preferred reading the log directly because it is more user friendly than manipulating a csv file. Anyway the difficult part was the logic processing the data not reading the file.
I do not guide but I guess that knowing the rms correlation with not only eccentricity but also with alt/az, filter or event different set ups would be helpful to improve guiding performance.
AD time scale will not be affected: as you correctly guessed, phd log data are integrated over the exposure time of the fits file and RA / DEC rms is calculated for that time interval.
the most flexible approach would be to allow the user to add custom fields to AD database: name of the field, type, format could be a minimum set. And then choose the source for these data, like CSV file, json, xml or even direct connection to a server. Filtering, sorting and plotting these data would be then straightforward.
It requires some restructuring of the code but it will be a nice improvement that will allow AD to be a single point of information for image metadata.
As of now I'm following another similar request by a github user (Rick) that suggested to import PHD2 guiding data through its log. It will allow to correlate guiding performance vs eccentricity or Alt/Az etc.
I'm not a PHD2 user so it's quite difficult to test. For example I'm not able to recreate the RMS calculation to have the same result as PHDLogViewer. Seemed to be easy but it's not.
A note about the filename as identifier key: names could change, files could be moved and different images could have the same file name. I chose a different approach that prevents these issues: hashing the file itself (a part of it, for performance reason). But for our understanding saying that file name is a key it is ok, I was just more specific because you're quite into the software details.