DIY digital setting circles

Looking for somebody to say this can't be done...

I have a relatively inexpensive GEM with the usual nearly useless setting circles. I'm thinking about building my own digital setting circles using rotary encoders I can get from eBay and an Arduino board to count the pulses.

Connecting the encoders will be tricky - I could use the other end of the shafts that the slow motion cables attach to, but mechanically connecting them to the mount will be tricky.

I'm a programmer so writing software is not an issue.

Be neat if I could pull this off and get it to talk to Stellarium or Cartes du Ciel. If nothing else, it should be a fun challenge.

If it works, it would be a lot cheaper than buying a motorized mount. If it works, I know it pretty much precludes putting clock drive motors on this mount.

google for David Ek digital setting circles . An older project but nothing has changed in the meanwhile.

It can't be done.

I went the David Ek route. Mixed results due to abuse of the circuit board.

But has you pointed out, attaching the encoders will be tricky. But I want to say I've seen someone do that here. A search may be fruitful. Don't forget to check our archives. We've had to move a boat load of stuff over there recently.

I first built a system back in the earlier 80's using a Conmadore C-64 and then a later version that I still use today using a BASIC STAMP.

- Dave

google for David Ek digital setting circles . An older project but nothing has changed in the meanwhile.

That was the inspiration for this project. I was thinking of substituting the Arduino to simplify Ek's way of doing things.

I did some searching on this forum, wasn't aware some posts were archived. I'll do some more digging around.

before he posts it himself

http://www.clearskyo...le/20-telesc...

I built a Ek clone using a Programmable Integrate Circuit (PIC). I use it on my 16" home made dob.

I was lucky and was given a set of low resolution encoders for free so the whole project did not cost me that much to complete. Plus it was fun. New encoders are relatively expensive.

Initially I used a Palm Pilot and free software Palm Pilot by Doug Braun. Palm Pilots are getting harder and harder to find so I recently upgraded my Ek clone box with blue tooth, so now I use Skysafari on my Driod phone.

The Ek clone box output is picked up on the phone via bluetooth which displays where in the sky my dob is pointed on my phone.

Go here for an article describing my Ek clone project:

http://www.clearskyo...igital-setti...

Hi -

I've just been through this on an EQ2. Project details - mechanicals and arduino s/w is here:

www.astrobling.weebly.com/digital-setting-circles.html

The encoders are homemade. S/w still has some bugs in! But maybe will be of help.

Simon

Thanks for thinking of me Danny

no problem, anything for a local

Here's a link for ya...

http://bellsouthpwp..../dholko/dsc.htm

This is fun - lots of different designs that converged to a similar solution.

Three processors, one for each encoder and one to process the data.

BTW, I found that the arduino was plenty fast enough polling encoder pulses rather than using an interrupt approach. Easier software to write! It manages a 60Khz polling rate on the encoder states, which is fine given the 18k encoder ticks per axis revolution. Code written in C as well, so hardly optimised.

Encoders attached directly to the axes so no problem attaching clock drives where they normally go.

No reason why you couldn't couple a slewing motor to the encoder gearing and make a GOTO if you wanted.

Simon

This is fun - lots of different designs that converged to a similar solution.

....

BTW, I found that the arduino was plenty fast enough polling encoder pulses rather than using an interrupt approach. Easier software to write! It manages a 60Khz polling rate on the encoder states, which is fine given the 18k encoder ticks per axis revolution. Code written in C as well, so hardly optimised.

Encoders attached directly to the axes so no problem attaching clock drives where they normally go.

....

Simon

So would the final product be one that would mean not having to use a PC for coordinate display and using an LCD matrix instead for that purpose. That's what I'd like to see. It's getting old having to drag around a PC every time I want to use my scope.

>>using an LCD matrix instead for that purpose

Yes - that's what this project does:

www.astrobling.weebly.com/digital-setting-circles.html

Simon

I've recently been looking into possibly doing this also but on my lightbridge. What I finally settled on was a combo of using the Skyhub box from HubbleOptics. For ~$135 shipped it gives the ability to connect either via Bluetooth or USB. That'll allow me to use it with either Skysafari on my Android tablet/phone or to my pc using Stellarium or Cartes du Ciel.
As for encoders I was planning on using these capacitive encoders. They are the cheapest I've found and are programmable to several different resolutions via onboard dip switches. Given that they don't have a fixed shaft these may be easier to adapt to what you're wanting.

www.astrobling.weebly.com/digital-setting-circles.html

What you have there looks pretty awesome AND flexible.
I already have Dave's Ek DSC interface/s and as I said before, lugging a laptop around simply to read coordinates gets old. Would it be easy to incorporate the Ek interface and have the 3rd CPU doing coordinate conversions, act as a display driver, etc.? Since my encoders will be driven directly from the shafts of each axis, I won't need to worry about compensating for backlash in the mechanical system. Any idea as to what it would take?

Thanks, Jeff

A couple of thoughts on digital setting circles system since I have built two from scratch. One used a Commadore C-64 and had the NGC and Messier catalog in the data base and display the cooridinates of were the scope was pointed. It used a two star alignment code. It took a good amount of time to write the code and debug the system. My second system is an interface built around a BASIC STAMP. It is very similar to the Ek DSC box or what JMI sold as their BBOX. It reads the encoder and outputs a ASCII string that has the as format as the NGC-MAX computers use. So any device, App or software package that uses an the NGC-MAX protocall can work with my interface.
If you have used both a direct readout device like an NGC-MAX or SKY Commander and then use a system that displays the night sky, like an App on a smart phone or software on a laptop you'll soon find that being able to see the night sky on the device is big plus. It allows to see what objects are around the one that you are viewing, many of which you many never have observeed befor. Since your using a push to system on your scope it take no time to hunt them down you take a look. The result is that you will have observing more objects.
From a technical stand point, while it is fun to build a direct read out device, it is going to take a fair amount of time while if you built an encoder interface you can take advanatge of the software already written, much of which is free or inexpensive and all the power of the devices they run on.

- Dave

From a technical stand point, while it is fun to build a direct read out device, it is going to take a fair amount of time while if you built an encoder interface you can take advanatge of the software already written, much of which is free or inexpensive and all the power of the devices they run on.

- Dave

The point of having a direct read out device that incorporates the use of the Ek encoder interface is to keep the options open of using either a dedicated read out device OR a PC/hand held device. It's quite often in a remote location that I'll simply set on an object and be parked there for a very long time(AP for example). A PC is simply overkill for what's needed and out in the boondocks using a handheld device for anything other is simply worthless.

Hi Jeff -

I don't know much about Dave Ek's DSC interface I'm afraid. I understand (I think) from some of the links posted here that the DSC interface counts encoder ticks and then transmits the counts on command from the computer.

So far so good. The control CPU s/w in my project could be changed to do this - currently the head-end CPUs repeatedly issue the counts over their 9600 baud serial links without being instructed. The central CPU just has to listen when it wants an encoder position update.

The other issue is what is the format of the data on the serial links: this project expects an encoder count in a specified format - 8 ascii hex digits and delimiter characters.

All easy enough to change - the software C source is available on the site if you want to have a go.

An easier approach if you are not bothered about the EK i/face would be to connect your existing encoders to the head end units: the business end of these expects a 5V signal wiggling up and down representing encoder ticks.

This is pretty much a standard output from most encoders I think. Any idea how many counts per axis rotation your encoders give ? I won't say plug and play, but could be close.

If you are going to make a control and display unit you might as well make the head end units as well - they are actually a lot simpler than the control unit.

Simon

I don't know much about Dave Ek's DSC interface I'm afraid. I understand (I think) from some of the links posted here that the DSC interface counts encoder ticks and then transmits the counts on command from the computer.

So far so good. The control CPU s/w in my project could be changed to do this - currently the head-end CPUs repeatedly issue the counts over their 9600 baud serial links without being instructed. The central CPU just has to listen when it wants an encoder position update.

The other issue is what is the format of the data on the serial links: this project expects an encoder count in a specified format - 8 ascii hex digits and delimiter characters.

Well,... that's another problem for me right there: The serial link.
The Ek interface I was/am presently using is being utilized with an old PC laptop running XP which has a serial port, but I don't know how long I can keep it limping along. I've since switched platforms from PC to MAC, and of course, the MAC has no serial port. I've ordered the USB version from FAR Circuits, but I've yet to build it. I suspect I'm going to be in for a big surprise.

Being that Dave's interface works with a number of software packages, I get the impression that it has to be some sort of standard transmittal format. Digging through all of Dave's pages I could have sworn I came across the source code for the PIC, or at least a link to it, but I can't seem to find it now. Maybe it was your's and I'm simply confused. Nothing unusual there.

All easy enough to change - the software C source is available on the site if you want to have a go.

Years ago(25 or more), I had designed up, prototyped/breadboarded, and started building a circuit to interface and count the pulses coming off of the encoders but never got past the programming of the processor that did all the math and ran the displays stage. That's when I learned that spaghetti code was my forte and that I should stick to designing hardware. Which is one of the reasons for the second line of my signature.

An easier approach if you are not bothered about the EK i/face would be to connect your existing encoders to the head end units: the business end of these expects a 5V signal wiggling up and down representing encoder ticks.

This is pretty much a standard output from most encoders I think. Any idea how many counts per axis rotation your encoders give ? I won't say plug and play, but could be close.

No, shouldn't be a problem. They're 1000 cpr before encoding to 4000. I'm seriously thinking of purchasing the 10,000 cpr units from Wildcard Innovations.

Not to get off the subject, looking at the gearing and hardware you built up, it reminded me that back when, I realized that with some additional hardware and an extra two sets of IR receiver/transmitters offset a quarter phase, one could get an encoded output of 8X instead of the standard 4X. Never got around to trying it out, but it looks like your setup could be easily amended to do as such.

If you are going to make a control and display unit you might as well make the head end units as well - they are actually a lot simpler than the control unit.

Simon

If it wasn't for the serial interface issue, your circuit would be a serious contender, but I sill need that USB interface,.... or do I? Maybe I should look a bit more deeply into the bluetooth interface Dave has up on his site and just find a way to keep my iPhone charged.

"Being that Dave's interface works with a number of software packages, I get the impression that it has to be some sort of standard transmittal format"

The Eck interface is using the NGC-MAX format and it is this format that has become the standard output format.

- Dave

Thanks for the reply David,

In a cursory search I did find this:

"When the NGC-MAX is operating in 'BOX' mode, it blanks its own display and does nothing but pass the shaft encoders' values over the serial port. It multiplies them by the encoder ratios (the latter set in the NGC-MAX setup function), and scales them such that 00000 is the position at power-on, and 32767 is just under 1 rotation.

Communication is at 9600,8,N,1. When the NGC-MAX powers on, it sends a hello message such as 'V2.94'. When the attached computer sends a character (the sample program uses 'Q' but anything seems to work) down the port; and the NGC-MAX replies with 13 characters of the format '+00000t+00000' where the 't' is ASCII 9, and the 00000s are the two encoder values."

And this: http://www.atmsite.o...dsc_old/dsc.asm

Do you think this is a good start or is there other, better info out there.

Most of that information is correct. The MAX units that I have worked with do require a "Q" to be sent and not just any character to get them to respond so many software packages send the "Q". There are other characters that can be sent as well and again some software packages do use them to check on the communication to a device to be sure it is working. Also the ASCII string sent back is zero padded so it always has to be 13 characters long and some software packages are looking for the leading zeros and not just a null character to decode the string into numbers. The older NGC-MAX units scaled the encoder reading bewteen +/- 32767 while the newer units scaled them bewteen +/- 1/2 encoder resolution, so 4000 count encoder would produce a count of +/- 2000 counts.

- Dave

If it wasn't for the serial interface issue, your circuit would be a serious contender, but I sill need that USB interface,.... or do I?

I just built an encoder interface for a work project using an ARM Mbed card - USB out. It does other stuff - like watching for alarm signals from a 1750 C furnace, and displaying information on a big LED bargraph...not what you want on a scope ;-)

Here's the source code !

DDM4 is my display device. Stick a printf statement in where that is, and you have encoder to USB.

#include "mbed.h"
#include "ws2801.h"
#include "HTML_color.h"
#include "QEI.h"
#include "SerialRPCInterface.h"
//The magic bit
QEI head_position (p8,p9,NC,10000,QEI::X4_ENCODING);

//P8 and P9 are pins on the Mbed for the encoder. NC is the //index pin, not used.

main()
{DDM4(0.0);
head_position.reset();

while (1)

{
wait_ms(250);


if (PosReset==false)
{head_position.reset();
while (PosReset==false);
};
height=head_position.getPulses();
height=height/206.8;
DDM4(height);
}

}