This is what Analyze currently does re RMS guide error. Please let me know if you think I got something wrong.

Internal guider, see
invent.kde.org/education/kstars/-/blob/m...uide/gmath.cpp#L1242
SquareError(t) = ((RA(t) - RA_target(t))**2 + (DEC(t) - DEC_target(t))**2)

In the PHD2 case, the RA(t) - RA_target(t) or diff_ra_arcsecs is taken straight from PHD2 (PHD2 calculates that and sends it to Ekos).
See invent.kde.org/education/kstars/-/blob/m...lguide/phd2.cpp#L487 for PHD2 part.
So, in the PHD2 case, Ekos is taking as the RA or DEC error, what PHD2 says is the RA or DEC error.

Analyze implements an IIR filter with an approximate time constant of 40 samples (nothing magic about 40 samples == about 2 minutes with 3s samples)

// initialize
filteredRMS = 0;
constexpr double timeConstant = 40.0;
rmsFilterAlpha = 1.0 / pow(timeConstant, 0.865);

// at every time sample (x below is SquareError(t) above)
filteredRMS = rmsFilterAlpha * x + (1.0 - rmsFilterAlpha) * filteredRMS;
invent.kde.org/education/kstars/-/blob/m...yze/analyze.cpp#L485

and takes the sqrt of the (poorly named) filteredRMS to get the rms value you see. (I guess I should have named it filteredSquareError).
invent.kde.org/education/kstars/-/blob/m...yze/analyze.cpp#L542

It does not take the mean of the RA or DEC samples. I understand your logic, though, why that might be nice.

All that said, that's not quite true for the case of RMS error printed in the Details box, e.g. when you click on a guide timeline session or a capture timeline session.
There, it does not use an approximate IIR filter, but rather computes exactly the sqrt of the sum of the square error in the interval.

In any event, just to be clear, this is what is currently implemented.
Happy to entertain suggestions,

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

This should be a really useful tool. Great work!
What would be really neat would be the RMS over the course of each capture to identify which ones might be sub-optimal due to poor guiding.
For info: The PHD2 remote interface returns the simple distance from the star centroid to the lock point. But in the Log Viewer (and I think also in the application but I havent checked) the RMS calculation subtracts the mean of the set from each sample before then calculating the RMS. So what is shown on the PHD2 screen is the RMS about the mean offset. What I think of as the "DC offset".

@fenriques I think that would be fine. Might simplify things a lot for you, but it would tie your software really closely with Ekos, meaning anyone who uses other tools wouldn't be able to use it. But since I only use Ekos for imaging at the moment, it wouldn't affect me.

Regarding the Z-filter comment, a core member from PHD2 told me that Z-filter used an offset. See the discussion here .

@fenriques, It seems does not install under RaspbianOS (buster)

OK. I'm the author of the Z-filter module. As Andy said it is normal for an offset to occur and it is not a problem for imaging BUT it does not inherently USE an offset. In addition to the situation I mentioned earlier, an offset can also occur with a drift arising from a large PA error where the Z-filter correction offsets the drift but does not return the star to the lock position

This looks fantastic. It seems to include some features I've posted for on the Wish List. Great work. Thank you.
Question: The RGB color coding is quite clear. But what about narrowband and calibration frames? I'm thinking you went with something along these lines?
Ha: Dark Red
S: Yellow
O: Cyan
Luminance: White
Dark Frame: Black
Bias Frame: 50% Grey
Flat Frame: 25% Grey
Other: Magenta

Wow, fantastic!

@kengs

I had a sense there was some authority behind response to my original post ...

Not directly related to topic, but are there any other conditions that would cause an offset other than PA? PHD2 reports my PA between 0.5 arcmin to 3.2 arcmin, so I'm not sure that's the issue. So, some other force must be in play. I'm guessing its either balance or cabling. I'm wondering if is possible to get a hint from looking at the corrections.

jmh

I would like to see temperature, barometric pressure, dew point, and possibly any other weather data (SQM comes to mind), plotted on the graph to to see how that that has an effect on SNR and HFR throughout the night.This would help people understand when to focus, if they're not doing it a appropriate times, or enough, or maybe too much. Right now, I refocus at every filter change, but maybe I should be doing it at every degree drop in temp, or every several degrees drop. Who knows, but this addition would be great in understanding what's happening.

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