A poor man's Argo Navis

[kinetic (Steve)]

Hi,

I recently upgraded my mouse encoders and the way they mechanically interface
on the GEM to radically improve the pointing accuracy.

Using mice internals on scopes is not new.
There are several great sites showing how to home brew your own
'poor man's version of an Argo Navis system'.

Mine are part of the Bartels Stepper Drive system I built years ago.
I have used mouse encoders on my homemade GEM for years but
it was only ever accurate down to 1/5 of a degree. This is quite accurate
for general viewing and wide field pointing accuracy but for deep sky, narrow
field it's not.

This improvement gives me approximately 8500 counts per 360 degrees on DEC axis and
a whopping 25,000 counts per 360 degrees on the RA!
That's 0.042° or about 2.5minutes DEC (was previously about 12 minutes)
and 0.0144° in RA or about 0.85 minutes.

Here's what I did:

I selected a 320dpi mouse with fine slotted wheels instead of the more common coarse 180-250 dpi
types. These types have better IR transmitter / detector pairs suited for fitting higher
resolution encoder wheels.

Using an old PS/2 mouse (with mini Din6 connector), I cut the two transmitter / detector pairs
off from the mouse circuit board with a Dremel.

I carefully chose the placement of the two cuts so that minimal re-soldering of broken tracks
was needed. The paths for the two cuts are shown as yellow dotted lines.
The only wire link I had to re-instate is also shown in yellow.

For the DEC axis: I used a 144 slot optical window wheel I found on the back of
a DC servo motor years ago. I kept this optical wheel knowing I might use it for
just this purpose
The rubber capstan wheel and shaft assembly are from an old photocopier and
fitted to a piece of aluminium extrusion with a pair of nylon bushes.
The encoder pair is mounted on an adjustment plate to zero out false counts.
Once wires were soldered to the pair, I made the fine wiring safe with some
5 min Araldite.

The DEC encoder assembly fits exactly where the lower res version sat.
That is, resting on the outer circumference of the old original setting circle
disks.

For the RA axis I used a small reduction gearbox/ optical wheel assembly I
pulled out of an old hand scanner I pulled to bits years ago
This gear train is perfectly suited for this purpose and that's also exactly
why I held on to it!

A rubber capstan and shaft were also fitted to another little box section extrusion
and the detector pair fitted to an adjustment plate.

In the Bartels software, encoder increments are just entered as an integer for
ALT and AZ (DEC and RA on a GEM) and you're away!

I have tested this all for about a week and the pointing accuracy is a huge
improvement.
After initializing on a known star and entering the co-ordinates, I am able
to drive to the galaxy or object of interest nearby and it's now always
in the field of the DSI Pro II on the live view.

Steve

[Starkler (Geoff)]

Well done with the tinkering to produce a poor mans encoder set, but the thread title is somewhat misleading.

[kinetic (Steve)]

Originally Posted by Starkler

Well done with the tinkering to produce a poor mans encoder set, but the thread title is somewhat misleading.

thanks Geoff (I think). Are you aware of what the Bartels system is?

I submit these sort of ATM ideas in good faith.
Maybe my choice of title was wrong.
As it's about fitting fairly high accuracy feedback to a Bartels Stepper
system, maybe the title should have been: 'poor man's AN and ServoCat'

Steve

[bojan]

Hi Steve,
Thanks for this post, those are very interesting ways to use at-hand parts :-) . The result is same functionality, with a bit of tinkering (which is a great fun per se), at virtually no cost :-)
This is what amateurism is all about, IMO :-)

[toryglen-boy (Duncan)]

Originally Posted by Starkler

Well done with the tinkering to produce a poor mans encoder set, but the thread title is somewhat misleading.

bit strong aint it?



i think anything like this is to be commended, well done. i only wish i had the savvy to know how to do something like this

nice one

[Starkler (Geoff)]

I in no way wanted to detract from your achievement here Steve and I regret my moment of pedantry.
Sorry

[alistairsam]

Originally Posted by kinetic

Hi,

For the RA axis I used a small reduction gearbox/ optical wheel assembly I
pulled out of an old hand scanner I pulled to bits years ago
This gear train is perfectly suited for this purpose and that's also exactly
why I held on to it!

Steve

hi Steve,

I know this thread is over a year old, but came across it while looking for DIY optical encoder designs.
just a comment on the gear reduction in the pics.

is'nt the gear reduction at the 2nd stage inverted?

tracing from the capstan shaft to the encoder wheel.


(using arbitrary values for illustration )

gear ratio from capstan shaft to next gear - 8:1
gear ratio from 2nd gear to 3rd gear - 1:8 - (this gear should ideally drive the next stage from a small to large gear)
gear ratio from 3rd gear to encoder wheel - 8:1
gear ratio from 3rd gear to encoder gear - 1:8

don't really understand how you get gear reduction, from what i can see, you'd effectively have no reduction.

not sure if I'm correct or if you'd noticed this.
if I'm correct, you might get better resolution if you correct the gear reduction. thought it might help.

but thanks for the info.

[alistairsam]

Originally Posted by kinetic

Hi,


This improvement gives me approximately 8500 counts per 360 degrees on DEC axis and
a whopping 25,000 counts per 360 degrees on the RA!
That's 0.042° or about 2.5minutes DEC (was previously about 12 minutes)
and 0.0144° in RA or about 0.85 minutes.

Steve

Steve,
could you please also explain how you got the figures above, just trying to understand it as I'm working on a bartels system as well and am stuck at the encoders.

you mentioned 8500 ppr on the DEC using a 144 slot wheel.
to get 8500 ppr using quadrature, would'nt you need 8500/4 = 2125 slits on the encoder wheel?

for the RA, you mentioned 25000 ppr. but you're using the slotted wheel from the mouse which I'm guessing is 160 slits? (320 dpi)?
so if the gearbox is reducing and you really slow down the encoder wheel rotation, unless the slits are extremely fine, there won't be pulses when the light beam is between the slits and the encoder is slowly turning till the slit edge is reached?
for 25000 ppr, would'nt you need 25000/4 = 6250 slits on the encoder wheel?
this is the part that confuses me. how do you cram so many lines even if using laser printers? only other option would be to reduce it photographically.
I found a nifty program that is specifically for optical encoder patterns if you're interested.
http://www.iceinspace.com.au/forum/s...ad.php?t=62537

I'm going to try printing a wheel using the professional printing outlets provided they have high resolution lasers printers.

[bojan]

If I may jump in :-)
The encoders actually have up-gear .. meaning instead of slowing down, they are actually speeded up.
This way, you can get numbers Steve was mentioning in his post.

In my own implementation of Bartel's system, I use 120mm diameter wheel, on which 6mm dia roller is riding, coupled with 48 slot encoder plate (from serial mechanical mouse).
This is ~20x up-gearing.
This way I am getting ~7500 ticks per axle rotation.

[alistairsam]

Originally Posted by bojan

If I may jump in :-)
The encoders actually have up-gear .. meaning instead of slowing down, they are actually speeded up.
This way, you can get numbers Steve was mentioning in his post.

In my own version of Bartel's, I use 120mm diameter wheel, on which 6mm dia roller is riding, coupled with 48 slot encoder plate (from serial mechanical mouse).
This is ~20x up-gearing.
This way I am getting ~7500 ticks per axle rotation.

cool. now it makes sense. but I guess the only drawback if any would be that you can't use the index pulse to reset the counter at 360 of the encoder wheel.

how do the us digital encoders work as I believe they have an index pulse, in that case, the encoder resolution would be based on one revolution of the encoder strip?

[bojan]

Not necessarily..
Bartel's system deals with incremental encoders, which are relative... and no index pulse (sometimes referred as z-channel or c-channel)
So, after powering up the system, you find a bright star in database, you point your scope to it and "reset" coordinates.
Software is taking care of the rest as long as the application is running.

[alistairsam]

thanks.

is there a thread for the bartels system as I had some questions related to the electronics.

if i used the attached codewheel (image is not high resolution on screen, but is on print) which has 700 tracks (350 black, 350 white), if I use a 10x step up gear, would that be adequate for the bartels system, as 700 track is effectively 3200 ppr with quadrature, and 10x step up gear would mean 32000 ppr. is this correct?
will try to print to transparency laser paper and rig up something like what steve's done here.

[bojan]

This is 350 tracks.. with Ek's box this will give you 1400 ticks per rev.
10x step up and this is 14000.. more than enough.

[alistairsam]

Hi, for direction, two sensors are required, do the ones from mice as in Steve's design below and your design come with two? how is direction handled here as I can see only one sensor, and for the second channel, the second track would need to be offset, but there is only one track?

else is it done by tangentially mounting two sensors using one track, that way one is leading the other? but in that case the two sensor positions would need to be precisely positioned so one is over a dark and the other one over a clear.

[bojan]

The sensors in serial mice have two channels (already at appropriate distance), so there is no real need for arrangement like on your wheel.
Also, the sensors must be positioned (and they are) such that when one is at the centre of the track (black or white, doesn't matter) the other one must be between the two (just changing state).
This is called quadrature position, and this is how mouse (and Ek's box) know in which direction the wheel is moving.

[kinetic (Steve)]

Thanks Bojan for stepping in, cheers....
Alistair, as B says, it's quadrature encoders and works beautifully with
the Bartels system. All reductions and counts are as I've stated in my post.
No doubts at all here, tested under the stars.
It's seriously a very good cheap system for the home dabbler with a bit
of practical , hands on ability. It is a very accurate positional system when
set up correctly...and half the fun is actually knowing how the workings
of a quite complex system work.

I'd suggest reading up a bit on the Bartels stepper (or servo) system to see
how versatile it really is.

Steve

[alistairsam]

Hi Steve, I have read up on it and am halfway through building it. was stuck at the encoders. but now that the concept is clearer, i should have it working soon. just need to figure out how to drive the alt/az axis for my dob mount. i've built a fork mount but will be a little while before i convert that to go to. but it does have tracking using microcontrollers and is working well. needs some fine tuning though for longer exposures. you mentioned you cut the pcb and then joined it later, that would effectively use the mouse electronics to interface to the bartel. i'll check if this is detailed on the bartels site. i was planning on just using IR transmitter/receivers to a simple circuit to produce CMOS level logic signals. will do more reading.

[bojan]

Alistair,
I had a bad experience with mouse electronics.. the serial interface part and driver.
Nothing wrong with it per se, but these days it is hard to find adequate mouse drivers for DOS (no acceleration and so on).
Also, it seems there is a problem with handling mouse interrupts within the Bartel's software, resulting in the current position not updated properly while in tracking mode ((for example, if the scope was pushed unintentionally while tracking, the software would try to correct this by moving the telescope back to original position, but because the mouse driver was not working OK, sometimes - not always - it would overshoot, even 2x.. and the current position would be lost)
However, all those troubles went away when I switched to Ek's box interface.

[alistairsam]

Thanks.
I understand the concept that Ek's box stores alt/az positional information and sends it to the PC when called, but how exactly is this sent, is it in binary? The Ek's box has ascom drivers, but is the driver actually used for the bartels system?

I know I don't have to reinvent the wheel, but I've designed a circuit similar to Ek's box using a picaxe which can output position values down to arc secs either to LCD or as binary.
Hence the question on how ek's box talks to the software and how it relays positional values.

[bojan]

Ek's box sends data as text (and it supports couple of formats).
Bartel's scope.exe deals with this directly, without special driver.

have a look here:
http://eksfiles.net/digital-setting-circles/

I wouldn't try to reinvent the wheel here.. really no need.
Ek's box can't be simpler in terms of h/w.. and firmware is available as well (freeware.. even as a source code.. but you have to ask David for this first)