The Intelliscope System
by Mark De Smet
I am putting this page up to distribute information that I have learned
about the Intelliscope system by Orion.
The encoders, cabling, pinouts and electronics are all covered here.
All pictures are thumbnails, many can be clicked for a larger version.
Also note that many of these were taken with extreme closeup(between 1 and
6 inches) with a macro lens, so some distortion is present. This
information is provided "as-is". I take no responsibility for how you
use it. This site is copyrighted, do not copy it, contents or pictures
without permision. You can
contact me if you
have any questions about this page.
Table of Contents:
1 Introduction
As of spring of 2004, Orion is providing the following parts to the system:
The intelliscope system is a digital setting circle(DSC) system for use on
the intelliscope family of dobsonian telescopes. Please see the links
above to learn more about the stated features and specifications. One
of the first questions many amateur telescope makers(ATM) ask is, "can I use
this on a different telescope?" In providing this web page, I hope to
provide information which would be required by someone who wishes to adapt
the system for use on something else. Officially however, Orion states
that this cannot be used on other scopes. (sounds like a challenge to me)
The big reason for this question is the low cost of the Orion system,
which is $170 for the computer and the altitude encoder.
The intelliscope system calls it's hand held electronics box a "controller".
This is slightly misleading as it does not actually control anything.
(to prevent confusion, I will refer to it as the computer)
This system instead just combines a large database, a user interface
and sensors to create a "push-to" system. This is slightly different
than a "go-to" system. With a "go-to" system, the user chooses an
object to look at, and the system moves the telescope to the correct position.
In a "push-to" system, the user interface instructs the user how to
manually move the telescope to the correct position. Both systems allow the
user to find objects, but the mechanism is different. Advantages of the
"push-to" style are that movement is much faster, there is no noise from the
motors, and much less battery power is required. The primary advantage of a
"go-to" system is that it is cabable of tracking an object.
The intelliscope system is made up of several parts, the azimuth and altitude
encoders, the computer controller, and the associated cabling. I will
cover each of these in the following sections.
I have investigated the XT10i, but the instruction manuals highly suggest
that all four XTi series scopes function the same.
2 Azimuth Encoder
In order for and DSC system to function, the controller must know where the
telescope is pointed, as well as it's movement. In order to provide
consistant accuracy in pointing(say 1/2 degree), this movement tracking must
be quite accurate. A typical DSC system will use off the shelf optical
rotary encoders. These are small devices which appear similar to
potentiometers, but rotate fully, and have additional leads. Typically
they take in power and ground, and provide two outputs. These outputs are
usually TTL (5V) level logic signals which pulse as the shaft is rotated.
Specifically they produce an output which is quadrature encoded.
This means that a computer which senses these outputs can detect 1/4 pulse
movements, as well as the direction of movement. Internal to the encoder
is a disk attached to the shaft. The disk has slots in it, the number
defining the number of steps on the encoder. A pair of light emitting
diodes (usually infrared) shine through the slots, and the light is picked up
on a pair of photo-diodes. As the shaft rotates, the disk intermitently
blocks the light, creating the signal which is sent to the computer.
Most DSC systems use encoders with 1024 or 2048 slots with the shaft directly
coupled to the axis of the telescope. (note the due to the quadrature encoding, these translate into 4096 or 8192 discernable steps)
The Orion intelliscope system however, does not use standard optical encoders,
most likely for cost reasons.(the 2048 pulse versions usually run about $70
each, which would make the $170 price tag very difficult) Instead, they
have constructed magnetic encoders partially integrated into the base. (the
azimuth encoder is fairly integrated, while the altitude could be easily
attached to a non-intelliscope dobsonian. The azimuth encoder could be
integrated into a different dobsonian with a little more effort)
The azimuth encoder for the intelliscope system is shipped with the
intelliscope base, and is added to the base during assembly. This is
covered in the users manual linked to in section 6.
The encoder is made up of an encoder disk, a brass bushing, and the azimuth
encoder board. These are shown below.
Azimuth encoder board
The large hole to the left is where the brass bushing fits through. The
two black rectangles in the middle are the sensors themselves. On the
far right, you can see the elliptical mounting hole. It is elliptical
so that when installed, it's position can be adjusted.
Azimuth encoder board bottom
The black modular connector sticks up through the top ground board to allow
it to be connected to the connector board.
Encoder disk
Brass bushing
You may notice on my azimuth encoder board that around the central pivot hole
I have some of the green solder resist worn away showing the copper below.
This is not how it was when the board shipped to me. This wear
came from improperly mounting the board against the top ground board.
More on this below.
The encoder board is faily simple. It has a large hole which goes around
the brass bushing which makes up the central axle. It also has two hall
effect sensors, an "handset" type modular jack(4 position, 4 contact), and a
mounting screw hole. The mounting screw attaches the board flush to the
underside of the top ground board. Here is where my problem comes in.
The PCB is supposed to lay flush with the top ground board, yet the pins
for the hall effect sensors are soldered through hole, so they protrude
through the PCB. This prevented my PCB from lying flat. I solved
this by using a dremal rotary tool to dig a small recess into the board to
give room for these pins to stick through. Another member of the yahoo
group indicated that his pins are bent flat and surface mounted to the PCB.
If your pins stick through, you could also desolder the parts, and mount
them like this. However, take care that you do not alter the spacing of
the sensors. You can see the recess here:
Azimuth encoder recess
The left most hole is where the mounting screw goes, next is the rectangular
hole for the modular connector to stick through, next is my recess. The
right most hole is for the central azimuth bearing, the brass bushing.
The two hall effect sensors measure
the magnetic field as they move over the encoder disk. The hall effect
sensors on my board are Allegro A3515LUA. Another member of the yahoo
group indicated that his are Allegro A3517SUA, which seems to be going
obsolete. The A3515LUA part is a compatible replacement.(actually
tighter tolerance) You can find the datasheet from the links in
section 6. The jist of this part is that it is powered
from 5V, and provides a linear reading of the magnetic field. This is a
key difference in this system versus a standard optical encoder. A
standard optical encoder provide TTL level square signals when rotated.
This system will provide a sinusoid. It is a sinusoid because although
the sensors are linear, the magnetic field when measured will show this
sinusoid when you take a slice through it. The two sensors are spaced to
provide a quadrature encoding when used with the encoder disk.
Azimuth encoder board sensors
The encoder disk is a flat steel disk with a magnetic ring near the edge.
This ring has 36 magnetic regions on it. This means that when the
encoder board is rotated over it, 36 sinusoidal pulses will appear with
one complete rotation of the axis.
The brass bushing spaces out the encoder board from the encoder disk, and
provides the central axle that the base rotates around. It is tightened
down onto the encoder disk to the bottom ground board using the central
bolt preventing either from rotating with the top ground board. The axle
is formed by the brass bushing, with the top ground board rotating around it.
Note however, that there is a bit of disagreement in how this central axle
works. I and two others of the yahoo group individually asked Orion
technical support how this functioned, and we were told that the brass bushing
is not supposed to rotate with the top board.(as described above)
However, some people have recieved bases, which when the bushing is put into
the central hole there is so much friction that the bushing has no choice but
to rotate. If the brass bushing rotates, then the encoder disk has a
tendancy to rotate as well, which will prevent the encoder from working
properly. Technical support has suggested that these people file the
central hole in the top ground board wider to allow the bushing to rotate.
Some have glued the encoder disk to the bottom ground board. If I
was present with this, I would first try to fix it by tightening the central
bolt.
Above, I stated that there are 36 magnetic regions on the encoder ring.
Earlier I stated that most DSC systems use encoders with 1024 to 2048
pulses per rotation. So, how does this work? The answer is that
this encoder does not work as a digital encoder, but instead as a combination
analog and digital one. The quadrature encoding allows the computer to
sense which direction the telescope is moving, but more accuracy is required
than the 10 degrees per pulse this would provide.(if read digitally)
Now is where a close look at that A3515LUA datasheet comes in handy. The
key is that it provides a linear measurement. Continuous rotation of
the telescope on it's azimuth axis will produce two sinusoid waves from it's
sensors, shifted 90 degrees apart.(the direction of shift depends on which
direction the telescope is rotated) See below. Channel 1 and 2
are the encoder signals, channel 3 is unconnected. The first two
waveforms are filled in because the sinusoid is actually modulated by a power
pulse, more on this later.
Reading the analog value of each signal allows the computer to measure many
different positions within a single magnetic region.
Azimuth encoder output waveforms.
This is the key challenge in retrofitting the intelliscope system onto a
different dobsonian. The easiest solution is to just get ahold of the
Orion azimuth encoder, and attach it to your dobsonian. However,
remember that this encoder is shipped with the telescope base, not the
controller. Perhaps you could call Orion and see if they will sell you
the parts as "spare parts". Alternatively you could try to come up with
a different encoder which produces the appropriate sinusoidal output. Or
build a converter box which takes in an optical encoder and provides the
analog signals. Or modify the code running in the controller to operate
with standard optical encoders. Or, if you can get your hands on an
additional altitude encoder, you could use it for the azimuth encoder, they
are functionally same. Worst case you could order a whole second
controller/alt encoder set, and have the actual computer for a spare.(If
anyone does this, I would be interested in purchasing the controller from you
for experimentation)
A special note which I thought of recently. It is common to use magnets
as weights on the OTA to help with balance. Care should be taken when
doing this that the magnetic field from these does not affect the encoders.
The tests in the controllers "hidden" menu should help with determining
if your magnet placement is a problem.
3 Altitude Encoder
The altitude encoder is shipped with the intelliscope computer. It
functions identically to the azimuth encoder, but is assembled a little
differently. It comes pre-assembed as a unit, which is mounted on the
rocker box side.
Altitude encoder bottom.
Altitude encoder top.
Altitude encoder side.
In the preassembled unit, the disk with the magnetic material is mounted to a
hub, and rotates within the circuit board. There is a nylon spacer
between the disk and the circuit board. A wafer spring and clip holds the
disk to the circuit board.
The green circuit board is attached with a pair of spacers to the rocker box.
Because it is attached only at the bottom, the top portion of the
encoder can flex towards or away from the OTA. It is supposed to stand
verticle when the OTA is removed. After the OTA is set on the base, and
the retaining knob is firmly attached, the encoder flexes towards the altitude
hub until it makes contact. The disk portion attaches to the OTA hub by
friction
as the retaning knob is tightened. This connection seems very robust.
However, as the encoder assembly is just "hanging out" when the OTA is
installed, there is very high potential for smacking it. Orion includes
a bumper to help prevent this, but extreme caution must be used to prevent
damage when installing the OTA. If smacked hard enough, the disk could
be bent, or the circuit board broken. Either would likely prevent the
encoder from functioning correctly.
Altitude encoder mounted to base.
When the encoder is attached to the base, part of the hub sticks through the
the hole to the outside of the base. This part of the hub is what the
retaining knob presses against to friction fit the encoder disk to the OTA
bearing.
Altitude encoder hub sticking out of base side.
The next set of pictures show what the altitude encoder looks like when
installed with the OTA. They are rotated to fit on the page better.
Up is to the left, down to the right. To the left you can see the
bumper that Orion provides. To the right, the cylinder you see is the
altitude bearing pad. Above, you see the altitube bearing of the OTA,
below the rocker box side. In the middle is the encoder. The first
picture shows the space between the two when the retaining knob is not
connected, the second shows the encoder locked down with the knob.
If you are looking to setup this system on a different dobsonian, I think
the Altitude encoder would attach fairly easily, in the same manner as with a
standard optical encoder. Mount the circuit board off a bracket on the
side of your rocker box with the encoder disk centered on your altitude hub.
Connect the encoder disk to your hub with a bolt or screw allowing
the two to lock together by friction.
4 Cabling
Although not exciting, this section contains all the technical details which
would allow one to actually connect it all up. As shown above, the
encoder boards have a "handset" type modular jack(4 position, 4 contact) which
allows them to be wired up. This is the same connector as is commonly
used to connect the handset to the base of a land line telephone.(in the US
anyway) It's pinout, and that of the RJ11 is shown below.
Modular connector pinouts.
Use caution when looking at RJ modular style pinouts. I have listed above
what I am 99% sure is the industry standard pin numbering. I've dug a
bunch on the web for pinouts of the Meade Autostar, and noticed that most of
the pages out there list the pins in the opposite direction. Also note
that a cable for the Autostar will not function with the Orion computer.
The same applies to the Celestron NexStar.
A cable goes from each encoder board to a "connector board", which is just
that. The connector board has 2 of the handset type modular jacks
for connecting to the encoders, and 1 RJ11 modular jack(6 position, 6 contact)
to connect to the computer. The handset jacks are on the inside of the
base, while the RJ11 sticks through a hole in the side of the base.
Connector board.
You can see on the connector board, that the two connectors which go to the
encoders have pins which stick out the back of the circuit board. This
causes exactly the same problem as with the azimuth encoder, but thankfully it
is not as much of a problem. In this case, simply don't screw the board
fully onto the side. If you do, you will find that the connectors start
to push out of the circuit board. If you want to mount it flush, dremel
a small recess into the side the same as I did for the azimuth encoder.
All three cables come with the computer controller, so I won't go into much
detail as anyone who gets the controller will have a set to use.
However, I will mention the fact that they are all straight through cables.
That is, pin 1 of one end goes to pin 1 of the other. This may
seem like a no-brainer, but take note that regular telephone and handset
cables have pins swapped. That is, pin 1 goes to pin 4, pin 2 to pin 3
and so on. Hence, regular cables will not work.
Connecting it all togather, I've come up with a schematic of the encoder
system. Connector J1 of the connector board connects to the
computer.
Encoder schematic.
The cableing on the base can be seen here:
Base
5 Computer controller
Most people would regard the computer controller as a "black box" which is
to be used as is, and not modified. I couldn't leave well enough alone.
As I don't have anything specific to modify here, and nothing needs to
be done by anyone installing this system on a non-intelliscope, I will instead
just provide the technical information I have learned. The controller
can be seen below.
Computuerized object locator.
The controller is a reasonable size for hand held operation with a very clear
easy to read LCD, and 16 membrane style push buttons. A membrane keypad
is not as nice as regular switches, as it is "mushy", and does not provide the
tactile feedback a click does. In any case, they seem to work just fine.
As others have noted, the power button has a tendancy to stick, as can be seen
in the above pictures. It doesn't seem to cause any problems, but is
just a nusiance. The backlighting for the keys and LCD is easily
adjustable by pressing the power button to scroll through the 6 settings. (you
need to hold the power button to turn it off) The backlight is uniform
and clear for the LCD, but not so much for the keypad. After using the
controller, it is obvious to me that the promotional pictures either have a
slightly different model, or have been doctored. The problem is that
the LED centered below each key illiminates the key primarily in the center,
with much less illumination near the edges. It is less than ideal, but
still servicable. The top panel has two connectors, an RJ11 (6 position,
6 contact), and a handset style modular connector(4 position, 4 contact).
The RJ11 connects to the connector board which in turn connects to the
encoders. The handset connector is an RS232 port.(more later) The
back side is plain with a slide off cover for a regular 9 volt battery.
Now to what's on the inside.
The first picture shows the top of the circuit board, which is located towards
the back of the unit. The second and third pictures show the bottom,
which is located towards the front of the unit. On the circuit board top
side, you can see the majority of the electronics near the top, and the
keypad backlight LEDs. You can also see two metal standoffs. The
screws that hold the case togather do not attach to these, so I suspect that
they are here to hold the circuit board in place when the user pushed against
it. On the circuit board bottom, you can see the trace patterns which
make up the keypad, and the LCD module and backlight diffuser. The
backlight diffuser is a clear plastic piece colored white on the back to
reflect light towards the front. Just below the LCD you can see three
LEDs which shine upwards to illuminate the diffuser. With the LCD
flipped over, you can see it's controller chip mounted directly to the glass.
The black and red wires going off the frame of the picture connect to
the battery compartment which is molded into the case back.
Computuerized object locator closeup.
In the closeup(you'll have to click on it to see the large picture), you can
see that the electronics are quite simple. Perusing the circuit, here's
what I've gotten from it.
They use a single microcontroller, a Motorola MC68HC705C8A, U1. It is a
member of the HC05 family, an 8 bit microcontroller. It is running at
4Mhz. Along with the 8 bit core, it has 31 general purpose pins control
pins, an SCI port, an SPI port, just under 8KB of ROM and a 176-304 bytes of
RAM. The ROM is one time programmable only, so it is likely that this
contains the basic part of the code. Although Orion has hinted that they
will provide downloadable updates, they have not specified what these updates
might be. It is possible that the code is not upgradeable, and only the
database can be updated.(this actually seems likely given the secondary memory
they are using) This is further substantiated by the fact that my
computer powers up and indicates that it is version 1.14, and on the top of
the microcontroller, you can see the text "DSF V1.14" enscribed. Sense
originally writting this, Orion has released several newer versions. The
first change was to increase the poweroff time out. For at least a while,
Orion would allow owners of the original model to send it back to be upgraded
for a fee to the newer version. This provides further evidence that the
basic code is not upgradable. The
microcontroller is run off of 3.3V. I ran the controller through it's
paces, and did not find any active signal on the IRQ signal, so it may be
unused. More detail about the
microcontroller can be found using the links in section 6.
The only external memory device is an Atmel AT45DB021B, U7. This is a 2Mbit
(256KByte) flash device with a SPI interface. It runs off of 3.3V.
It is connected to the SPI interface of the microcontroller. When
communicating to the flash, the microcontroller is running the interface at
1Mhz. This is a sequential access memory, which means that a processor cannot run
code from it directly. Because of this, I think this system has to have
all of it's code located in the microcontrollers ROM, which in turn means that
the user interface is not upgradable. It is possible to store code in
this memory, but as it cannot be run from here, it would have to be copied
into RAM somewhere. There is no external RAM, and the microcontrollers
limited RAM would make this very difficult.(although not technically
impossible) Even still, if this ROM is deticated to only the data base
of stellar objects, that is quite an impressive fit. The stated capacity
of "over 14000" objects would mean that only there are less than 19 bytes of
data per object.(on average) The CS signal is connected to microcontroller
pin PB6. More detail about the flash can be found
using the links in section 6.
A single analog to digital (A/D) converter is used, TI TLC0834, apperently to
read the encoders. U6 is a 4 channel (using multiplexer) 8 bit
successive approximation type with SPI control. It runs on 5V.
It is also connected to the SPI interface of the microcontroller. When
communicating with the A/D, the microcontroller is running the interface at
500kHz. This is the maximum rate for this converter, meaning the fastest
conversion time would allow up to 62500 conversions per second. With 4
channels to sense, this is only 15625 encoder samples per second. This
could be a problem if the system used the standard optical shaft encoders with
2048 cycles(8192 states). Knowing that oversampling is required with
standard optical shaft encoders, it is not unreasonable to guess that a user
could move the scope faster than the computer could keep up. This is yet
another advantage of the peculiar encoders the intelliscope system uses.
In order to keep track of position, the controller only needs to count the
total number of full pulses, and the current analog value. Remember that
there are only 36 full pulses per rotation with these encoders, so
keeping up with such a slow system is no problem. This also may be the
key to where the stated encoder resolution of 9216 comes from. 36
regions per rotation times 256 results in 9216. Using the diagnostic
test "encoder test" built into the hidden functions does indeed show that it
can sense 9216 positions. The absolute count goes from 0xEE00 to 0x11FF,
and the scope can be positioned on individual values. However, I am not
fully certain how the 256 comes about. You might say that the A/D can
determine 256 values, which is true, but that is across the entire voltage
swing. The hall effect sensors are not "railing".(and doing so would
leave a blind spot in the sensor system) This same encoder test also
seems to be showing the actual analog values being read. On my system,
this value varies between 0x44 and 0xC8 on one axis, and between 0x53 and
0xB7 on the other. My best guess is that they are only using half the
dynamic range of the sensors and A/D, but making up for this by using the
fact that both sensors togather can determine 1/2 steps. (actually two
sensors can determine 1/4 steps, but 1/2 of this is redundant to the analog
measurement) This also presumes that they have come up with a good way
to do some tricky math between the pair of sensors to give an effective 128
values. More detail about the A/D can be found using the links in
section 6.
A RS232 level translator chip is used, Sipex SP232A, U2. It is a simple
level translator which runs off of 5V. The associated charge pump
capacitors, C2 and C6, can bee seen next to it. This is
connected to the SCI port of the microcontroller to provide the RS232
interface. More detail about the
SP232A can be found using the links in section 6.
The single crystal is labeled as being 4Mhz. The associated RC load can
be seen as parts C4, R15 and C5.
The only adjustment on the board is R7, a 1Kohm potentiometer. From
where the traces go from it, I suspect that this is driving the contrast
circuit for the LCD.
The LEDs on the board are powered directly off of the 9V battery, wired in
series(for efficient voltage drop), and through a transistor of some sort, Q1
to provide the dimming control. Q1 is controlled by microcontroller pin
PA3. LED dimming is accomplished by pulse width modulation. That
is, the control signal is active for 100% of the time when at maximum.
The next step down is active for 50% of the time at 500Hz, next 25% at 250Hz,
next 12.5% at 125Hz, and the dimmest at 6.25% at 60Hz.
The "missing" chip, U5, looks suspiciously like the pads for an additional
flash device, but I don't believe that it is for the same Atmel flash device.
You see a power
trace connecting to pins 1 and 2, which does not work for this flash.
Also, A bit of digging at Atmel shows this family has a wide range of sizes,
from 1Mbit to 64Mbit, so there would be little reason to have a second
component. (well, there is a little presumption here; ocassionaly memory
components can cost less to purchase two of a smaller size than 1 of a larger,
but this is usually only on the high end, which this part is not) It is
also connected to the SPI port, runs from 3.3V and has a shared chip select
with the flash device. My guess is that this is for a flash device from
a different vendor than Atmel. This way, the producer of the computer
can just buy which ever component is less expensive, and place it in the
appropriate spot.
The conglomeration of resistors, capacitor and small (transistor sized) chips
in the upper left appear to be a dual stage linear power supply. I have
not fully analysed this, it is only an educated guess. My guess is that
U3 and U4 are linear regulators, with U3 dropping 9V to 5V, and U4 dropping 5V
to 3.3V. When measured, these voltages do appear on what appears to be
the outputs.
Transistors Q4 and Q2 form the driver for the encoder power, and are
controlled by microcontroller pin PC4. This also brings to light the
fact that the encoders are not applied continuous power. This is what
makes the above waveform capture of the encoder output look so bad.
Presumably to save power, the computer actually only applies power to the
encoders for about 300usec, then turns them off for about 1.7msec. This
is a period of 500Hz. There is a jitter in this sample rate of about
+/-50us. The encoder values are presumably read through the A/D during
the on time. This is yet another reason why regular encoders would not
work with this computer. Such a low sample rate, of only 500 samples per
second would never work with a regular encoder, but as explained above, will
work fine here. In the below waveform, you can see the encoder signals.
Channels 1 and 2 are the encoder outputs, and channel 3 is the power pin
to the encoders. You can see a current reading of 4V on the channel 1
sensor, and about 2V on the channel 2 sensor.
Encoder power waveform.
The LCD is attached with a ribbon cable to J1 on the circuit board.
Although I cannot identify the LCD from it's labeling, but from prior
experience, it is likely a fairly common module. It appears to have the
controller located on the LCD glass, so that just a simple digital interface
to a microcontroller is required for operation. The microcontroller just
has to send basic commands to update individual characters on the screen.
Without doubt, this is the most expensive component in the computer.
It has been noticed by many that this LCD does not perform very well in cold
weather, as the screen becomes slow, and eventually goes blank. See
section 10 for a trick to help with this.
The RS232 port on the top of the controller does not use the same pinouts
as either the Meade Autostar, or the Celestron NexStar. Pin 1 from the
Orion computer is RS232 transmit, which should be connected to pin 2 of a
standard PC DB-9 connector. Pin 2 from the Orion computer is RS232
recieve, which should be connected to pin 3 of the DB-9. pin 3 from the
Orion computer is ground, which should be connected to pin 5 of the DB-9.
6 Resources
Manuals, Users Guides, Data sheets
Intelliscope. XT6, XT8, and XT10 instructions on Orions website.
Intelliscope computer controller. Controller instructions on Orions website.
Intelliscope controller holster. Controller hoster instructions on Orions website.
Motorola 68HC705C8A. Product folder for the micro controller used in the hand controller. Contains the datasheet and other data. Note that Motorola spun
it's semiconductor division off as Freescale Semiconductor.
Atmel AT45DB021B. Product folder for the flash part used in the hand controller. Contains the datasheet and other data.
TI TLC0834. Product folder for the A/D part used in the hand controller. Contains the datasheet and other data.
Sipex SP232. Datasheet for the rs 232 level translator used in the hand controller.
Allegro 3515. Product folder for the hall effect sensor part used in the encoders. Contains the datasheet and other data.
Web sites
Orion Telescopes. Orion's offical website
Yahoo Group: skyquest-telescopes. A yahoo group for owners of the
skyquest family and similar Chinese made telescopes.
7 Using the computer with a non-intelliscope
To start, let me say that I have not actually connected an intelliscope
computer object locator to a different scope. (I am quite happy with my XT10i)
However, I have extensively investigated the intelliscope system to
provide the information in this web page. In doing this, I have come up
with how I would go about using the intelliscope computer with a
non-intelliscope telescope. So, please feel free to use these
instructions, but recognize that you may be the first person to do this, and
as such, may run into unforseen difficulties. If you embark on this
project, I would appreciate hearing from you. If you have questions
about the system, the yahoo group, or perhaps even the sci.astro.amateur
newsgroup would be a good location to look for other expertise out there.
As I've detailed above, the primary challenge is coming up with a azimuth
encoder. In this section I will presume that you have not gotten ahold
of spare set of the azimuth encoder components. Instead, the base
assumption is that you have purchased 2 of the Orion computer controller sets.
The total price of this, $300, still compares quite favorably to the
other commercial solutions available. If you are able to purchase spare
components from Orion, I would recommend purchasing a second altitude encoder
instead of the azimuth enocoder parts as the altitude encoder functions as a
complete unit. An additional presumption is that you are not going to
modify the software inside the computer controller.
Another question that comes to mind is wether you are trying to attach the
intelliscope computer locator to an alt-az mount(presumably a Dob), or to an
equatorial mount. The controller is intended to operate with a dobsonian
style mount, but I cannot see any reason why you couldn't use it on an
equatorial. The one downside however is that the controller will not
correctly indicate when an object is below the horizon. In the
calibration, the computer will think that you are located at the north
pole instead of your actual location. However, besides the warnings
that some objects are believed to be below the horizon, the controller still
provides pointing directions. No matter what kind of mount you have, the
two encoders need to be 1 to 1 coupled(presumably direct) to your axises.
So, we are presented with the following components:
- Your telescope
- Intelliscope computer controller kit:
- Object locator computer
- Altitude encoder assembly
- Altitude encoder cable
- Azimuth encoder cable
- Coiled controller cable
- Other parts you won't need
Step 1: Buy 2 of the computer controller kits. Yes it seems like kinda a
waste to need to buy the second computer, but I cannot come up with any other
way to get the second encoder. Besides, the total cost of $300 is still
lower than any of the other DSCs on the market, and you will have a spare
controller if the first one breaks.
Step 2: Mount one of the altitude encoder assemblies to your altitude axis.
If you have a standard dobsonian style hub, you will need a bolt
sticking out the side of hub in the rotational center, or perhaps a t-nut
built into the rotational center of the hub. This will allow you to
slide the metal hub on the encoder over the bolt, and be locked down with a
nut. Now you will need to come up with a bracket of some sort to screw
the encoder circuit board to, and to your rocker box. This would be a
similar sort of bracket as one you would use with a standard encoder.
Care should be taken that the encoder is mounted in the correct orientation.
At question, is which hub you mount it to, and which side of the encoder
you place towards the OTA. If you do it wrong, I think you can make up
for this by reversing the sensor wiring on that axis.(but not 100% sure)
On an intelliscope, the encoder is ment to be mounted to that the metal disk
is towards the OTA, and the circuit board away. Further, if you have the
OTA pointed north, it should be mounted on the eastern hub. You can
reverse both of these without problem.(metal disk away from OTA and mounted on
the western hub)
Step 3: Mount the other altitude encoder assembly to your aziumuth axis.
I am not fully familiar with what is common for axis hubs, but can help
explain what is needed. Similar to the altitude axis, you need the metal
encoder disk to be attached to one part of the axis, and the circuit board to
the other. I would envision this to be easiest to do by bolting the
metal disk to your central azimuth bolt(presumably this stays fixed with the
bottom ground board), and attaching the circuit board to your top ground board
with a bracket. From my analysis, with the metal disk fixed with the
bottom ground board, and the circuit board rotating with the top, the metal
encoder disk should be up, and the circuit board should be down towards the
ground. To make sure you get this orientation correct, I would
recommend testing it out first, or mounting it so that you can reverse it if
neccesary. Alternatively, I think you could reverse it by switching the
sensor wireing.
Step 4: Wire it. Ideally you would like to use something like the connector
board which comes with the intelliscope base. However, as we don't have
that, you will have to make something up. You could just take the three
cables which came with the controller(you have an extra set afterall), cut the
ends off, and wire them togather as shown in the cabling section above.
I have included schematics above which should allow you to perform this.
Alternatively, if I was doing this, I would wire up a small circuit board
similar to the connector board Orion provides. This creates a nicer
finish as you have a mounted jack you can plug the computer into, or
disconnect for transport. However you do it, the goal is just to end up
with the connections as shown above.
Step 5: Test out the encoders. Connect the controller, and power it up
into the "hidden" menus described in the instruction manual.(hold enter key
when powering it on) Use the "alt az test" to verify that when you move
your telescope, the correct set of numbers change. The altitude number
(upper right) should increase as you move the OTA towards zenith. The
azimuth number (lower right) should increase as you move the OTA
counter-clockwise. You might also want to try the "encoder test" to
verify that the sensor spacing is ok.(the manual describes what numbers are
accetable) Also verify that neither encoder is slipping as you move the
telescope around.
Step 6: Create a vertical stop. The intelliscope system requires three
positions for proper star alignment. The second and third are named star
positions you choose from a list, and center the telescope on. The
first is "vertical". Actually, being vertical is not required, but
instead that the tube is parallel to the azimuth axis.(or if you are using an
equatorial, parallel to the polar axis). On the intelliscope this is
accomplished by adjusting a spacer located inthe rocker box. This
prevents the tube from going beyond vertical. It is initially calibrated
by leveling the base, and level the top of the tube to place the spacer.
Once set, you only need to push the telescope against the stop. In your
system, you will need to come up with a method of reliably positioning the OTA
parallel to the azimuth axis. The stop seems to work quite well, but if
you wish to maintain the ability to move the OTA slightly past zenith, you
might try a set of lines on one of your altitude hubs which line up when
the OTA is parallel. This alignment is important to be accurate, as
it directly affects pointing accuracy, so this may not be the best method.
If all goes well, that should be it! Take it out, star align it, and
enjoy!
If you decide to use this web page and mount the intelliscope system on a
different scope, please
mail me so that
I can share your success with others. In fact, if you are interested,
I would be interested in helping someone out with this installation to work
out the kinks and add your instalation details to this website.
Update
I was contacted recently by Malte Uhl who had read this webpage and successfully
attached the object locator to a different telescope. You can
read about it here. If you also have
success, please
let me know.
Update
I am pleased to be able to link to another COL user who has successfully installed the COL on his Meade Lightbridge dob! Check it out.
Update
I was contacted by another ingenious telescope modifier who successfully
created his own magnetic encoders for use the the COL. Bill Seiler used
36 permenant magnets spaced around a lexan disk, and wired together the boards
with the sensors. He cut 1/2 inch magnets from the long strip magnets removed from the door of an old refrigerator and reports that he was getting warp numbers from 0.7 to 1.1, but still had more tuning to do.
Altitude and Azimuth Encoders
Update
I was contacted by another great telescope modifier who successfully installed
the Skyview Pro version of the Intelliscope COL to his dob. Mike Scalion
reported that although the encoders were somewhat difficult to mount and position,
the system is working well. For the declination encoder, he found a 1
inch toilet fill tube threaded nicely. The right ascension encoder has
a larger inside diameter thread, approximately 1 5/16 inch.
8 RS232 communications with the computer controller
The RS232 port on the top of the controller does not use the same pinouts
as either the Meade Autostar, or the Celestron NexStar. As such, you
will either need to make your own cable, or purchase the Orion cable(#5222
which you can order by phone if it is not yet on the website). If you
purchase the Orion cable, skip to the next paragraph. To make your own
cable, please use the modular connector pinout shown above in
section 4. Pin 1 from the Orion computer is RS232
transmit, which should be connected to pin 2 of a standard PC DB-9 connector.
Pin 2 from the Orion computer is RS232 recieve, which should be
connected to pin 3 of the DB-9. pin 3 from the Orion computer is ground,
which should be connected to pin 5 of the DB-9. I would recommend using
a RJ11 to DB9 adaptor that many of the electronic distributers carry.
This is a small adaptor with an RJ11 socket molded into one end with wires
hanging out. You simply plug each of these wires into one of the holes
in the included DB-9. You will want a female DB-9. If you are
unfamiliar with this sort of thing, dig around on the web, and you will find
the same sort of thing used in home made cables for the Autostar or NexStar.
Keep in mind that this adaptor has an RJ11 connector, not the handset
style. The pins are compatable, so you can still connect a handset cable
to it, but will just need to carefully center it. You will probably also
want to use a coiled telephone handset cable, so when you wire it up, remember that
this cable has its pins swapped. If in doubt, measure it with a
multimeter. If you would prefer to just solder your own cable, you can
use a standard female DB9 connector, and a handset cable with one end cut off.
Simply solder the pins to the wires to make the connections I have
listed above. With the adaptor I have and a handset cable, you should
connect yellow to pin 2, green to pin 3 and red to pin 5.
RJ11 adaptor
Currently, the IntelliScope is supported by
Earth Centered Universe Pro version 4.0a and up and
TheSky6(not the student
version). If your version does not have support, check the website for
updates. Orion has also indicated that Starry Night Pro will support the
Intelliscope soon. If you don't already have one of these programs, and
are looking to purchase one, you might give Earth Centered Universe Pro a try,
as they offer a 30 trial period, and is a much better deal than the others.
I have found that using ECU with the intelliscope to be very easy and
straight forward. An interesting note that I have found is that ECU is
more accurate at pointing the Intelliscope than the Intelliscope computer.
I suspect that this is because ECU is using full a higher precision in
it's math than the Intelliscope computer is.(likely given that the
Intelliscope computer is running on an 8bit processor.
A trick I learned with using ECU is that if you don't plan on using the object
locator at all, you don't actually need to align it. Power the locator
up in the test mode(hold enter when powering on), and go into the alt az test
mode. This will allow the encoder readings to be sent to the PC.
The big reason why this is so good is because of the 15 minute timeoff feature
built into the locator(if you don't press a button for 15 minutes, it will
turn off). Before you power on the locator, point the scope accuratly at
something stationary, such as the light on a radio tower.(you want as much
repeatable accuracy as possible) If you don't have an object, you could
try using the north star, but will lose accuracy as it moves. Now when
you power into the test mode, and align ECU, you can repeat the setup without
realigning ECU. If the locator powers off on you, simply point the scope
back at that object(again as accurately as possible), and power on the locator
into test mode. The reason this works is because the locator in this
test mode doesn't provide absolute coordinates, but instead just encoder tick
readings with 0,0 at the location the locator was power on. This trick
does not work if you power on the locator in normal mode.
If you are a software developer, and are working on adding intelliscope
communication to your program, I would be more than willing to provide a cable,
technical details, debugging assistance and beta testing for a copy of your
progam. Please
mail me
if you are interested in this.
The interface operates at 9600 baud, 8-N-1, 8 data bits, no parity, 1 stop
bit. Communications appear primitive at best. At powerup, the
computer sends the version number, "V1.14" followed by a carriage return.
The computer does not send line feed, just carriage return.
Unknown characters sent to the computer are responded with by a "?" with no
carriage return. The only two valid commands I can find are the single
characters "P" and "Q". No carriage return or line feed is used.
"P" is responded with "P001". This seems to be the response no matter
what state the controller is. Peter Eschman pointed me to the manual for the
skywizard 3, another Tangent box, where this reports the battery state.
I have not tested to see if this will actually report a low battery,
but I don't think the controller has the circuitry to sense the battery
voltage. "Q" is responded with a pair of numbers
representing the current azimuth and altitude values. When the computer
and scope are aligned, these appear to be close to "real" values, with 0
altitude being horizontal. However, 0 azimuth does not appear to be
fixed. Instead, 0 azimuth appears to be the position the locator was
powered on. Accuracy depends on the accuracy
of the alignment. When in the hidden menus, these values are either
stuck at a last value, or represent the az/alt values shown in the test.
The response to the Q command is "Q" followed by a signed azimuth value,
followed by a tab character, a signed altitude value, then a carriage return.
The signed value always has a "+" or "-", and 5 decimal digits. A
value of 0 has a sign of "+". Each digit represents one of the
measureable steps, or (360/9216) = 0.0390625 degrees. For example,
"Q-02345<tab>+01234<cr>" represents -91.60 degrees azimuth, and
+48.20 degrees altitude. +90 degree azimuth(+02304 reading) is east.
The values do not appear to be limited to +180
to -180, but instead something like +177 to -183 degrees. I have no idea
why, but if you run the numbers they always seem to be correct. Unless
someone else finds more out than I, it looks like a program running on the PC
cannot send coordinates to the Orion computer(so that it can provide the
direction arrow assistance). A PC program can only read the coordinates,
and use that to control the PC display. The program would need the
appropriate location and time information to do it's own az/alt info to R.A.
and DEC conversion.
Update
I was contacted by Peter Eschman, who pointed me to the instruction manual for an older
Tangent DSC which seems to share similarities. This may be of use to some
out there. You can read the instructions to the Skywizard 3
here.
9 Programs supporting the Intelliscope
This section lists computer program which support communication with the
Intelliscope. This list is in order of when the program added
Intelliscope support, and order does not represent anything else.
Earth Centered Universe
Pro ECUPro supports the intelliscope natively, and does not require
any plugins. Communicating with the intelliscope works just as expected.
You can align the object locator and ECUPro, or you can use the locators
test mode, and just align ECUPro. One of the great features of ECUPro is
that you can download a 30 day trial to see if you like it. The trial
version supports the Intelliscope.
The Sky Six
TheSky6 Professional edition and TheSky6 Serious Astronomer edition both
offer support, but the student edition does not. These both support
the intelliscope natively, but you may need to download a update from the
website. I have not tested this, so cannot provide additional details.
Cartes du
Ciel/Sky Charts Cartes du Ciel supports the intelliscope using an
additional plug-in. (the plug-in is called Encoder Plugin 1.2 dated Oct 23
2004) I have not tested this, so cannot provide additional details.
Cartes du Ciel is Freeware, so you can download it to keep for free.
AstroPlanner
AstroPlanner supports the intelliscope in version 1.4.3 and above.
AstroPlanner is a different kind of program to communicate with a telescope.
The other programs here are primarily planetarium programs functioning
like an interactive star chart. AstroPlanner's fame comes from it's
ability to do planning, logging, and telescope control for your observing
session. The intent is to make it easy to choose targets, organize them,
and allow for taking observing logs. The communication with the
Intelliscope allows easy movement to the objects in your list. Go to the
Astroplanner home page for more information and the free download.
Astroplanner works on Macintosh and windows computers. There is a Yahoo
group called "astroplanner" where you can find support or discuss the program.
Starry Night Pro
I understand that Starry Night Pro (Not sure about the other editions of
Starry Night) supports the intelliscope, but I have not heard from anyone
who has successfully used them togather.
10 Tips and Tricks for the Intelliscope
The best trick that I've come up with is on using the intelliscope with a
computer program. I've tested this successfully with ECUPro, but
it has been reported to work on TheSky6 as well. One of the big annoyances
with the object locator is the automatic power off if no button is pressed for
15 minutes. Orion offers a chip replacement to change this to 50 minutes.
Another way to deal with this is to make it easier to realign.
Here's the trick:
With the object locator off, point the intelliscope accurately at a stationary object
which you can point back at with high reliability. A distant radio tower
lamp would be good. You could try the north star, but you will lose
accuracy as the night progresses because the north star moves a little.
Now turn on the object locator in test mode by holding the enter button
and pressing the power button. In the hidden menu, go into the alt az
test mode. Now set aside the locator, and align your program (such as
ECUPro) as normal, and you are ready to go. Now here is where the trick
comes in. If the object locator powers off on you, you don't need to
realign! Simply point the telescope accurately at the stationary object
you chose before, and power the object locator into the test mode going into
the alt az test mode and you are done. No need to realign the computer
program. this can be extended if you do not move your intelliscope
between observing sessions. Again use the stationary object when turning
on your object locator, but this time when you start up your computer program
you can just use the the 1 star alignment instead of a normal one.
If you are curious why this works, it is because the computer program does
not use aligned coordinate data from the object locator, but instead just
interprets the numbers as encoder readings. When you align the object
locator, it provides aligned coordinate data. When you go into the alt
az test mode, the object locator provides coordinate data with the 0 alt 0 az
point being the location you powered it on at. This way, when you
repoint the scope before powering on again, you are setting the encoder data
to be the same.
If you come up with other tips or tricks, please let me know and I'll
share them with everyone.
Update
I was contacted by Bruce Harding who had read this webpage and came up with a
great solution to the LCD becoming unreadable in the cold. He added four
300ohm 1watt resistors to the inside of the COL and wired an extra socket to
power them as a heater. You can
see pictures here in his gallery.
11 Mechanical dimensions
I am including this section because there is a some interest in the azimuth
bearing mechanism, and also to provide the required information for mounting
this hardware on a different telescope.
Click below to see a compressed tif file of the drawing. If your browser
is unable to view this file directly, save it, and use a graphics program to
open it. Sorry if this is an inconvenience, but I was unable to get a
clear enough jpg with a reasonable file size.
