Really nice pic, though, I am really not sure the stacking by Siril is so bad. Pixinsight seems to just do a better job at normalization of the background as black. Also, looks like Pixinsight has a bit of unsharp masking applied. I am curious if you could not obtain similar results with some setting changes to Siril. Anyhow, very nice.
Is anyone else using Onstep remotely and having trouble? I can only slew a few degrees before the mount stops, then, later I can move a few more degrees. I can not use the Park command to get the mount to its home position. Prior versions did not exhibit this problem.
When I connect using the OnStep Android app from my phone, I can slew with no problems, so, I am ruling out my mount/wiring. The problem occurs in, both, the RA and DEC axis.
KStars Build :
I will attempt to get some logs of this activity.
Thank you for this. I may have to check what settings I programmed into my OnStep. Unfortunately, the CGE mount can not pass the meridian by much of anything without causing a serious mount to mount crash. Its now no wonder Celestron moved on to their present day designs. This is causing me to not trust the mount will flip or even stop before it crashes.
If you should find your cable or remember any other specifics of what settings you used, please do post some more. Thanks again,
Hello to the group,
I am in the process of setting up a CGE mount with OnStep using KStars remotely through Stellarmate on a Pi4. To be honest, I am lost on getting the meridian flip to work. The mount is a GEM, has limit switches and PEC installed, but for now, I just need it to slew and flip when it should. Can someone post their settings for both the OnStep and KStars to accomplish this? i.e. Does KStars setting for meridian flip control the OnStep, or, Does OnStep flip independently of KStars? Does one turn off meridian flip in, say, KStars and use just the OnStep?
Thanks in advance,
Attached screens are for our Northern latitude AP1600GTO. Hopefully, they may help, but, we assume no responsibility for your own mount.
We like to use horizontal pointing north on the horizon, NOT our pole star. It allows us to easily know if initialization is correct, and, when park is correctly being achieved.
Our initial procedure was to manually position the telescope on the horizon facing north. The telescope is EAST of the pier with counter weights to the West. Power up the mount and wait. Our AP is rather slow to boot up. Once it's initialized, we moved the cursor on the KStars map to the approximate location the mount was pointing. Synced. Then, we used the INDI Control Panel command (Site Management, Park Options, Write Data) to write our current position for KStars to use as the Park.
Operationally, we are careful to not Warm Initialize, unless needed during the night. Always, when you initially power up the mount and connect, check to see the star map shows the mount icon in the approximate Parked position. If not, the mount must be properly Synced.
One final suggestion. Be careful to make certain the connection is with the mount and not some other USB device.
I love the documentation.
Interesting discussion starting here. I would not recommend using the entire image because of possible frame rotation causing errors. The automatic guide star should be a single star selected as close to the image center as possible and with adequate separation from other interferences.
If guiding errors were totally random during an entire exposure, the image would not show star trailing. Instead, blooming of the star would occur. It is because tracking errors are NOT random that guiding works.
Random errors such as winds pushing the telescope during the exposure can not be corrected by this method, but would be caught and corrected by a guider camera.
Background: Development of the ST-4 auto-guider was the answer to correct minute errors in equatorial tracking due to any number of deficiencies. Image exposure and transfer times were too long on the primary imaging CCD, so, corrections created by use of a second CCD camera taking rather short exposures seemed appropriate. I am proposing this might not be necessary in this day and age.
Just as today's Polar alignment routine uses an accumulated correction model for proper slewing, guiding could be enhanced using a similar model designed for tracking. The proposed advantage of this system would be to eliminate use of a secondary camera, off axis items, or guide cameras.
The premise is based upon the idea that a perfect polar alignment, coupled with an exact tracking rate, and, precise gearing will maintain a centered image target for the period of 1 exposure. It further requires the primary ccd image field must contain at least 1 guide star. Ekos use of astrometry for slew to target will assure target centering and adequate guiding stars.
This methodology will not correct for transient events such as gearing defects, wind, or temporary atmospheric distortions.
1: KStars Ekos when set to take an imaging sequence, will automatically take a calibration image of a short but detectable length. Automatic astrometry imaging will have already handled proper position identification, target centering, and slewing corrections. Within that field, a guide star will be identified, either, by user or automatically. A second calibration image will be taken with tracking off. Offset for stellar drift will be calculated. A third image taken with an offset in declination, and again, appropriate offsets will be calculated to determine the needed motions for maintaining center of the desired target.
2: From the above data, (just as Lin_guider and others now do) appropriate guiding vector directions and amounts will be established. Appropriate guiding pulsing will be applied, and Ekos will spiral up the exposure time to take the next image. Corrections to the guiding model will be applied by comparing the somewhat longer exposure with the previous one.
3: Each subsequent longer image will be compared and corrections applied. The theoretical hope is, at the desired full exposure time, a single correction vector will produce adequate tracking to image the desired target.
Thank you for taking the time and effort, not only to work through your QHY problem, but to post how you got to the solution. I feel far too many times these problems are specific to hardware and software timing, signal noise, power issues, and in some rare cases, user settings. Today's competitive market, coupled with the cost of production changes, has resulted in a large number of 'short cuts' to get a product out in a hurry.
In defense of the forum, I want you to know that someone is reading your posts.
Answer to the question on just changing from ST7 to ST8, yes. But there actually was a file which does this flash. I know I have it some place, but wow, its going to take some hunting to find it. Sounds like you might the answer with the CCDops program.
Sorry to read about the decline to release the old code, its a shame since SBIG was literally the first camera I can remember which supported Linux. And you are definitely on the approach which I am looking at. I thought the code in the link might get us there, but if not, I will dig a bit more.