Try this link. github.com/wotalota/indi-rolloffino
The one at indilib.org/domes.html has been done as a relative URL by mistake

Read More...

Ken Self replied to the topic 'HA and local Meridian' in the forum. 4 weeks ago

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.

Read More...

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.

Read More...

Have you tried running indiserver with indi_eqmod_telescope driver?

Read More...

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?

Read More...

Ken Self replied to the topic 'New KStars/Ekos Module: Analyze' in the forum. 2 months ago

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

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

Read More...

Ken Self replied to the topic 'New KStars/Ekos Module: Analyze' in the forum. 2 months ago

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
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

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".

Read More...

Ken Self replied to the topic 'New KStars/Ekos Module: Analyze' in the forum. 2 months ago

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!

Regards,

jmh

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.
On the other hand, RMS values should be calculated about the mean so a constant offset becomes the mean and therefore cancels out of the RMS value.. This is how PHD2 calculates the RMS as you can see.

Read More...

Wiring is decribed here: eq-mod.sourceforge.net/eqdirect2.htm
You can ignore the 12V pins sicne those are coming from the mount.

Read More...

Ken Self replied to the topic 'INDI Driver for SVBONY cameras' in the forum. 2 months ago

dlwmacgregor wrote: You lost me a bit with the VID/PID stuff.

In the lsusb output whre it says f266:9a0a
f266 is the Vendor ID (VID) which corresponds to CKcamera as the manufactuer of the device
9a0a is the Prodcut ID (PID) which corresponds to the SV305

The fact that there is no description showing simply means that the file that contains all the VID's and PIDs and their descriptions is missing the entry for f266:9a0a
It does not mean that the driver is missing.

Read More...

Ken Self replied to the topic 'INDI Driver for SVBONY cameras' in the forum. 3 months ago

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
wiki.debian.org/HowToIdentifyADevice/USB

Read More...

Ken Self replied to the topic 'New User - A speed question' in the forum. 4 months ago

psg8064 wrote:
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).

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
If your userid is not pi then change the remote directory accordingly.

Read More...

Ken Self replied to the topic 'New Tool: Ekos Debugger' in the forum. 4 months ago

I'm having issues with KStars/EKOS crashing on Windows 10. Is there a way to debug the programs on W10?

Read More...