Re: New User - Encoders

John Petterson


A little bit of background is probably valuable at this point.  I have not looked at the code that is servicing that interrupt for a while so it is possible this has some wrong information. If my memory is right the current code updates a second location pointer as the mount is moving, not simply counting pulses but rather recalculating the pointing location as pulses come in. This second encoder location pointer is accumulated on the microcontroller that is running the encoders and network and not directly available on the main processor so doing anything with it is a bit more complex than it looks at first glance.

At some interval depending on your settings it will compare that encoder location with the mount's position and update the mount's position with the encoders reported position if the difference is over a specified value.  (It also moves the data in the other direction when you do an alignment action, setting the encoder's reported position to the mount''s position.) I think it does not do that update during moves however (probably because the time required to move the data between processors makes it less accurate during the moves) but only during tracking, and the comparison value used to determine if it should be updated is generally too high to be valuable in correcting tracking. 

So based on that you may rethink your desire to even use the encoders.  I am happy to have them because I have a Losmandy AZ8 and can point the mount manually wherever I want very quickly and it will resume tracking correctly - not easy to do with an alt-az mount without those encoders.  It also has clutches that allow slippage unless you really lock them down so minor slips are correctable during slews (I simply hit the slew button again a second after it stops and the mount corrects to the right target.) 

If you decide to go forward with the encoders, given the discussion above I think I would be more inclined to try to use a divide by 8 or divide by 16 circuit on each of the two sides of the encoders, seed one of them with half of that number at startup to keep them close to evenly spaced, and feed that output back into the existing software rather than redesigning the whole thing to accumulate counters somewhere else and then try to figure out how to update the pointing position.


Join to automatically receive all group messages.