Jimbo,

thanks for the report on the success with the TTL232 modification.

I’ll try to include that information on my web site for those who
might be interested.

On the issue with encoder readings, it sounds like you have a problem
with one of the two channels for the RA encoder. It’s likely a solder
or cable issue. You would observe that behavior if only one channel
was connected–the encoder reading would oscillate between two
adjacent values as the encoder was turned. If this is indeed the case,

that would explain the peculiarities with the DEC readings that you
described, too.

You need to be a bit careful of using the ASCOM software to test the
system, because the coordinate transformations can end up giving you
results that you might not expect. For example, you might see both the
RA and DEC numbers change even if you only move the telescope on one
axis, simply because your telescope isn’t perfectly polar-aligned.
It’s easier to test the encoder connections using hyperterminal, since

you can see exactly what the interface returns without having the
coordinate transformations in play. Try that and see if the encoder
readings make any sense. Get the encoders working correctly using
hyperterminal, and then you’ll get much more satisfaction when you use
the ASCOM stuff.

Hope this helps –

Dave

On 9/24/07, Jimbo S. Harris <jimbo@jimbo.net> wrote:
> Hi Dave,
>
> The TTL232 modification was a success; I connected to the board in place of
> the MAX232 at pins:
> +5v – pin 16

> GND – pin 15
> Tx – pin 11
> Rx – pin 12
> (all corresponding pins of the MAX232), and I left out the MAX232, 7805,
> and all the corresponding caps, etc.
>
> The interface booted right up. I connected via both your program and also

> via the ASCOM driver (in ASCOM Validator and in DSLR Focus). I got the same
> results both ways.
>
> I’m having some kind of problem with the actual readings from the interface
> — when I move the Dec axis, both RA and Dec update. a lot. When I move the
> RA axis, there’s basically no movement at all (sometimes it flickers back

> and forth between 2 values, but that’s it).
>
> By the way, I’m not sure that I can trust the Dec readings at all, but it
> seems like the readings are ranging from +60 to -60 or so; is that an
> encoder resolution problem? When I’m setting the scope to 0� and then 90�
> during setup, is there a movement speed that I should not exceed?

>
> I’ve tried a variety of cable-swapping to see if I could isolate the
> problem, but I need to do some more isolation of the problem; so far
> suspects include my soldering on the board, my soldering on the cable, and
> the RA encoder. The encoders were on my mount when I got it; I assumed that
> they’re working, but I have not tested this theory. I have a second set of

> encoders lying around the house; I need to test those and see if I get
> different results.
>
> Anyway, the interface as a whole is what I’m calling a “measured success”,
> but the USB conversion seems to be working like a charm.
>

> Best,
> Jimbo
>
> At 03:13 PM 9/18/2007 -0600, you wrote:
>
> >Jimbo,
> >
> >Yes, there is an ASCOM driver for my interface. I’ve never actually

> >written code to access it, so I don’t know the other side of the
> >interface very well, but I think the ASCOM web site has some sample
> >code. Basically, I think you call an API function whenever you want
> >the celestial position at which the telescope is pointing. So it’s up
> >to your software to decide the polling interval and to do the polling.

> >You’ll also need to call API functions to access the alignment
> >process, etc. The ASCOM documentation is reasonably good, and like I
> >said, I think there’s some sample code, so that’s probably your best
> >source of information.
> >

> >Dave
>
>

Leave a Reply

Your email address will not be published. Required fields are marked *