Re: ATM stand-alone driven Dob

[jackb@ricochet.net (Jack Brindle)]

Olivier;

You raise some pretty good questions. Let me try to answer some of them,
and give you some insight where our work is heading.

>        Why do everybody want to take his/her laptop when observing?  I
>live in a country in Europe, where laptops are still expensive ($2,000 is
>a "bargain"), and I want to carry as few things as possible when
>observing.

I agree fully. I happen to have an Apple PowerBook that I can use, but I'm
not too sure that I want to take it all the time. There are some pretty
big advantages to having a laptop in the field, specifically the ability
to run star chart programs. There are some downsides, beyond the one you
mentioned. Current laptops use a flourescent backlighting system, which
is way too bright for use at a dark-sky site. There is a limit as to how
dim a flourescent light can glow; unfortunately that threshold is still
too bright. Current laptop computers like to use batteries. Want to stay
out all night? Better take four or five backup batteries, since most
laptop's batteries give out after about two hours (when new). You could
connect the laptop to a large storage battery, adding another large item
to haul to your favorite mountaintop. The last item, which I will also
discuss down the page, is the problem that laptops have with cold. If
you plan to do any observing below freezing (0C), you had better find
a way to keep the laptop (and it's LCD) warm.

Now, having said that, the advantage of the starchart software is an
overwhelming reason to use laptops in the field. I guess I (and many others)
will be getting carts to haul around our oversized storage batteries...

>Therefore I am drawing plans for a STAND-ALONE Dob drive: no
>needs of an external PC, input is directly possible from a small keyboard,
>output is written on a cheap small LCD display.  The parts would not cost
>lots (the encoders would be the most expensive parts (dunno the actual
>cost of them), the rest are "off the shelf" electronic parts, excepted the
>CPU, ideally mounted onto a SBC (Single Board Computer)).

I agree here also. The current MacDobs system will support this operation
quite well. In fact, it will probably do it better than you imagine. The
reason is our approach to using multiple microcontrollers to handle the
tasks. There are some pitfalls, however. As I mentioned above, watch out on
the LCD. Most LCDs are rated down to 10C. There are some down to 0C, and even
slightly lower, but they tend to be expensive. The fluid that makes LCDs work
doesn't like the cold, and, like people, will stop working when it gets too
cold. You will definitely need to plan for some way to heat the LCD.
Backlighting is also a problem. There are LCDs with LED backlight panels, but
they are usually yellow in color. I have yet to find a red backlight system.
I would like to use LEDs for the backlight to help conserve power. Oh - one
other point. LCD panels to to draw lots of power. This is surprising to
most people. You have to pay for that nice display somehow, and not just
in money...

>        The software is uploadable via a serial link, and stored in EEPROM
>or RAM.  I think a 486 CPU will do the job well, but I do not know how
>much power it dissipates (I want to dissipate as few as possible).

This is where we differ. The 486 requires way too much in the way of support
and power to make this system work well. Our system is based on low-cost
68HC11 microcontrollers. These have a surprising amount of processing
power. By placing a microcontroller at each device on the scope (one at
each stepper, one for the shaft encoders, and another for the hand
controller), we can spread the processing load out, while still having a
system with lower chip count and cost than a PC-based design. And, because
there is real-time control local to each device, we have more precision
in the actual control of the scope. Interestingly, this system allows the
use of a laptop OR a handcontroller (or both) due to its network
communications design. It also is designed with power in mind to help
reduce the size of that storage battery I discussed earlier.

>Oh yes, the job consists of tracking RA and DEC after finding the scope's
>position by means of the 3-star algorythm, and eventually field
>correction.  I have studied Mel Bartels' system and Dan Gray's design, 
>and I think Dan's system already does _almost_ everything I want.
>Combining both and eliminating the PC link (which will still be an option)
>would achieve the job (well, I hope).

Dan has a very interesting system, which bears a very close look. I would
venture that his design has been about as important as Mel's in inspiring
our work. I am fully convinced that his use of chopped motor drivers is
better than the "normal" unipolar approach that we see so commonly. Note
that while Mel's system supports DSC encoders, Dan's system currently
does not. It is really cool to watch it work, though.

>Has anyone here done something like, or is intending to do so?  Any
>suggestions and comments are welcome!

Obviously yes. Our small group started out as several individuals wanting
to use our Macintoshes to control our scopes in the same way that Mel
uses his PC. It still has those goals, but has evolved into a system
capable of much wider usage. Because it uses serial RS-232 communications,
it should be somewhat easy to adapt other systems (Windows, Linux, etc)
for hosting. Progress has been slow, but we are beginning to see the
fruit of our efforts. For example, the DSC module is now functional, and
I expect to see the stepper modules running my scope within the next few
months.

I also know that several others are building small systems as you describe.
I am unaware of anyone else using a distributed processing approach to
such a system.

I am also forwarding this email to the ATM group for the current network
telescope discussion. I believe that the MacDobs system will provide an
interesting approach to such a system that should be investigated. The
design of the system already supports multiple telescopes on a single
local telescope network (someone just needs to write the host software
to coordinate multiple scopes simultaneously). Adding an ethernet or
other network interface should be a relatively simple task. I would
suggest that a Java-based interface might be the best way to go for
now and the future, extending the distributed processing methodology.
One big advantage to the design for this use is that all real-time
support and control takes place at the scope, so that remote commands
may be loaded into the controllers with pretty good assurance that they
will be executed at the proper time and order. And, feedback is available
so that the host can determine if things did happen as expected.

Someone is bound to ask about the cost. I don't have specific figures to
give right now, but for stepper modules, the current cost of the pc board
is equal to the cost of the electronics in the module.

Oh, and one last item. Currently our project is not a commercial venture.
We have planned all along on making just a few systems to meet our
requirements. We are open to changing this situation, however. The main
consideration would be our enjoyment in continuing the project. If it
isn't fun, is it really worth doing?


Jack Brindle
jackb@ricochet.net
ham radio: wa4fib/6