Dan Holler replied to the topic 'Astrophysics AP1100 - Starting From Park and Parking' in the forum. 6 months ago

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.

Read More...

Dan Holler shared a photo. 9 months ago
Dan Holler replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 10 months ago

I love the documentation.

Read More...

Dan Holler replied to the topic 'Guiding in the modern age.' in the forum. 11 months ago

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.

Read More...

Dan Holler created a new topic ' Guiding in the modern age.' in the forum. 11 months ago

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.

Proposed Implementation:

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.

Thoughts gentlemen?

Dan

Read More...

Dan Holler replied to the topic 'QHY163M disconnect INDI' in the forum. 11 months ago

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.

Dan

Read More...

Dan Holler replied to the topic 'Sbig ST7E - Invalid sbiglpt0 port' in the forum. 11 months ago

Jim,
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.

Read More...

Dan Holler replied to the topic 'Sbig ST7E - Invalid sbiglpt0 port' in the forum. 11 months ago

JIm,
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.

Dan

Read More...

Dan Holler replied to the topic 'Sbig ST7E - Invalid sbiglpt0 port' in the forum. 11 months ago

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.

Read More...

Dan Holler replied to the topic 'Sbig ST7E - Invalid sbiglpt0 port' in the forum. 11 months ago

Jim,
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.

Dan

Read More...

Dan Holler replied to the topic 'Sbig ST7E - Invalid sbiglpt0 port' in the forum. 11 months ago

Thank you Jim, I will take a look at it sometime soon, I hope. I use a ST7, actually modified into an ST8, as a sky camera. And while, it was always rather slow, it was very reliable and does a nice job.
Not knowing your application of the ST7, let me just say, it is possible to install a KAF1600 ccd into that camera. It requires a slight modification of a 'cover' which holds the off axis prism for the guider ccd. Truthfully, I forget just what software I changed, but, I remember it was not too difficult. Openskyimager is able to loop it with a delay between images.
Dan

Read More...

Dan Holler replied to the topic 'Sbig ST7E - Invalid sbiglpt0 port' in the forum. 11 months ago

Thank you Jim for the parport driver though, this raised a question / wish list item for the older SBIG cameras. SBIG made a serial adapter for these cameras which has long been discontinued, however, today USB to Parallel adapters are available and affordable.

So, this daunts the wish for a modification of the driver to allow it to take advantage of such an adapter. I suspect this is possible and even SBIG might provide the serial code for such. Just an idea.

Dan

Read More...

Dan Holler replied to the topic 'absolute encoders' in the forum. 11 months ago

Yes, it certainly should if the KStars is receiving the position from the mount. This does not necessarily require absolute encoders. For example: We use an AP mount and KStars. Once we make the INDI link between KStars Ekos and the mount, we can use the mount's own hand controller to move the mount. The new position IS reflected on the sky map on KStars.

Read More...

Dan Holler is friends with PaweĊ‚

Dan Holler replied to the topic 'OnStep Driver not accepting date' in the forum. 12 months ago

Date is corrected, however, the driver still does not work.
[2017-11-26T19:46:35.272 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <isSlewComplete> "
[2017-11-26T19:46:35.272 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:D#> "
[2017-11-26T19:46:40.277 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2017-11-26T19:46:40.306 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <17417:48:45> "
[2017-11-26T19:46:40.306 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] VAL [17417.8] "
[2017-11-26T19:46:40.306 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GD#> "
[2017-11-26T19:46:40.322 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <+90*00:00> "
[2017-11-26T19:46:40.322 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] VAL [90] "
[2017-11-26T19:46:41.323 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <isSlewComplete> "
[2017-11-26T19:46:41.323 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:D#> "
[2017-11-26T19:46:42.366 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0*0001:48:47+9*0:00#OV> "
[2017-11-26T19:46:42.366 EST DEBG ][ org.kde.kstars.indi] - INDI Server: "2017-11-27T00:46:42: Driver indi_lx200_OnStep: *** stack smashing detected ***: terminated"
[2017-11-26T19:46:42.366 EST DEBG ][ org.kde.kstars.indi] - INDI Server: "Child process 4922 died"
[2017-11-26T19:46:42.367 EST DEBG ][ org.kde.kstars.indi] - INDI Server: "2017-11-27T00:46:42: Driver indi_lx200_OnStep: stderr EOF"
[2017-11-26T19:46:42.367 EST DEBG ][ org.kde.kstars.indi] - INDI Server: "2017-11-27T00:46:42: Driver indi_lx200_OnStep: restart #1"
[2017-11-26T19:46:42.367 EST DEBG ][ org.kde.kstars.indi] - INDI Server: ""
[2017-11-26T19:46:42.368 EST CRIT ][ org.kde.kstars.indi] - INDI driver "indi_lx200_OnStep" crashed!
[2017-11-26T19:46:42.398 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] Toggle Debug Level -- Scope Verbose "
[2017-11-26T19:46:42.399 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] Toggle Logging Level -- Scope Verbose "
[2017-11-26T19:46:42.406 EST DEBG ][ org.kde.kstars.indi] - INDI Server: "2017-11-27T00:46:42: Driver indi_lx200_OnStep: pid=4966 rfd=4 wfd=9 efd=12"
[2017-11-26T19:46:42.407 EST DEBG ][ org.kde.kstars.indi] - INDI Server: "2017-11-27T00:46:42: Driver indi_lx200_OnStep: initializing from LX200 OnStep device..."

The OnStep appears like its working, yet, motors are not running until I make an initialization by bluetooth with Android Tablet software. Even then, Speed settings are not accepted, Sync and Slew do not work even though the log indicates they are working.

Read More...

Dan Holler created a new topic ' OnStep Driver not accepting date' in the forum. 12 months ago

Anyone else seeing this problem with OnStep?

[2017-11-24T19:21:31.239 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <setUTCOffset> "
[2017-11-24T19:21:31.239 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:SG +05#> "
[2017-11-24T19:21:31.239 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:SG +05#> successful. "
[2017-11-24T19:21:31.239 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:SL 19:21:24#> "
[2017-11-24T19:21:31.239 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:SL 19:21:24#> successful. "
[2017-11-24T19:21:31.239 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <setCalenderDate> "
[2017-11-24T19:21:31.240 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:SC 11/24/17#> "
[2017-11-24T19:21:41.193 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] Unable to parse response "
[2017-11-24T19:21:41.195 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <setSiteLongitude> "
[2017-11-24T19:21:41.195 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sg080:22#> "
[2017-11-24T19:21:41.209 EST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sg080:22#> successful. "
[2017-

Read More...

Login

3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!