thanks Hy for clarifying the features of this module and I will refer to the documentation in the future.

I used Analyze on a set of images taken last night and it helped a lot to choose which were good or not before downloading from the observatory.
To me it would also be useful if images that don't match some criteria (e.g. HFR>1.5, Eccentricity>0.6) could be discarded /deleted before saving.

Ferrante

Read More...

Thanks again for this useful new module Hy!
I've noticed two minor issues:
- the Temp parameter has different values in the checkbox and in the chart. For example see attached image, the temp value is recorded as 6.40 but plotted as -1 (yellow line).
- The Details windows are always empty; maybe the reason is not having guiding data but the left panel should show at least capture data from my understanding.

ferrante

Don't own a MGPbox but a very useful way to power on the mount from remote is using wake on lan.
If you have MW4 installed it provides, beside its many other features, a front end for wake on lan.

About windows I had a similar issue: 10micron releases its clock sync utility on windows only, so I have a win10 VM on my intel nuc pc and use that utility running this VM. But virtualbox only runs on x64 and not arm architectures, but you can have another emulator (qemu?) on the rpi4.

Ferrante

Read More...

On a 10Micron mount, when entering a Longitude value in 'Site Management' the driver updates the mount coordinates but skips the seconds (ss) value.
For example, entering '02:38:30' in Ekos, will results in 'E002 39 00' on the 10micron handpad.

For Latitude the behavior is different: seconds are stored correctly.
Looking at the log, the reason seems to be different decimal places for Long (5) and Lat (only 2) when setting the Observer location.

[2020-11-27T19:03:52.453 CET INFO ][           org.kde.kstars.indi] - LX200 10micron :  "[INFO] Site location updated to Lat  37:44:24 - Long    2:38:30 "
[2020-11-27T19:03:52.458 CET INFO ][           org.kde.kstars.indi] - LX200 10micron :  "[INFO] Observer location updated: Longitude (2.63556) Latitude (37.74) "

yoandresmza wrote: SUCCESS people!!!

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?

Thanks again

hi Andres,

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:
github.com/fenriques/indi/blob/master/li...dome/dome_script.txt

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.

ferrante

Read More...

hi Wouter,
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:
print('ok')

Read More...

hi Andres,

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.

Ferrante

Read More...

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.

ferrante

hy wrote: Ferrante: wasn't aware of Astrodom, looks very cool. Take a look at the .analyze files and in particular the method processInputLIne()
invent.kde.org/education/kstars/-/blob/m...yze/analyze.cpp#L621
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.

Hy

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?

ferrante

Read More...