HA = LST - RA
Normally we have RA fixed so HA is calculated by subtracting RA from Local Sidereal Time.
You can see that calculation is correct in the screen shots. So your Local Sidereal Time is incorrect. That could be due to either your computer clock or your longitude.
You can use PHD2 Polar Drift alignment with an RA drive only mount. In fact, none of the polar alignment tools move the mount in declination. And even RA movement can be performed manually.
Without Dec corrections drift in declination could be an issue. PDA is not highly accurate for PA (within about 10 arcmin) so you might want to follow it up with a classic drift alignment or SPA.
Have you tried running indiserver with indi_eqmod_telescope driver?
Indeed, getting the remote driver name is a problem. I had thought it would be nice in INDI Web Manager to have a drop down list of the available remote drivers rather than having to find out the name and type it in.
But this looks like it would do the job if the same syntax works in INDI Web Manager i.e. can I specify simply @remote_ip in the Remote Drivers field?
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 fo rimaging 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 not return the star to the lock position
fmozza wrote: Regarding the Z-filter comment, a core member from PHD2 told me that Z-filter used an offset. See the discussion here .
This should be a really useful tool. Great work!
hy wrote: This is what Analyze currently does re RMS guide error. Please let me know if you think I got something wrong.
Internal guider, see
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)
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;
and takes the sqrt of the (poorly named) filteredRMS to get the rms value you see. (I guess I should have named it filteredSquareError).
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,
Who told you that? The Z-filter algorithm might result in an off center plot if guiding starts with the star off center and a large X-factor is used. This happens because it works in the frequency domain and a constant offset corrresponds to zero frequency so it does not get corrected. But it does not necessarily result in a 1 arc-second shift under all conditions. In fact, it is arguably preferable for the offset to be retained as it results in a better image.
fmozza wrote: During my session, I noticed an issue with calculating RMS. I used PHD2 for guiding, and I use the Z-filter algorithm for DEC control. According to the folks at PHD2, when Z-filter is used, PHD2 shifts the image - RA is centered, but DEC is shifted by 1 arc-second. I'm not sure why, but this will throw off the calculation of RMS due to the DEC shift. Take a look at the attached pictures so you can see what I mean.
But very nice tool!
In the lsusb output whre it says f266:9a0a
dlwmacgregor wrote: You lost me a bit with the VID/PID stuff.
That's not a big issue. There is a file that translates the USB VID/PID to a description. That file needs to be updated, assuming the VID/PID are registered
Yes you can save to the SD card. In EKOS set the Upload option to Local. Then set the Remote directory to /home/pi/whatever
However, the downloading of the images whether I'm capturing subs or images for alignment is very slow. It takes 40-60 seconds to download one image. I'm thinking there must something I'm doing wrong either in my process or my setup. I'm hoping someone might have some suggestions for me.
Also, is there a way to just save images to the SD card and not have them download? Once I'm happy with the image, it would be nice to speed things up by just running a sequence of captures where it only saves on the camera SD card.
I have format set to native and upload set to client. I am using the offline solver in alignment (with Astrometry loaded on the Raspberry Pi).