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.
The answer to the question of replacing ICs within the SBIG camera is definitely, no. I never had to replace or rewire any circuitry going from KAF400 to KAF1600. Its only a software and rules thing.
As for the interface to usb, I must search again, but when I built my Audine camera, there was a usb interface which a guy made called the Quick Audine. It used a factory made FTDI based usb interface coupled with a PIC18F252. At the time when I built them, I did not think it was too difficult. Such an interface might give you some ideas, but, as you say, it is a singular hardware solution.
Oh, I wanted to ask, which cable you have which is really short? I see 2 methods: 1 USB to parallel adapter attached at the computer with a long parallel cable. Or, 1 USB to parallel adapter attached to the camera with a long USB cable. In the first case, noise and signals of a parallel cable come into play. In the second, its vital the 5V be transmitted to the remote adapter circuit.
The 2 ccds are essentially the same pins out. I have attached the data sheets which I have. As for software, I will search my archives, but, you might find it by contacting SBIG, they used to offer a ccd upgrade in the past, so, they might share this now since the cameras are so very old.