Building a GOTO Mount

Hmm - at a glance the ioptron and meade commands seem to be compatible, aside from each one has a few extensions...

My 'new style reticle' polarscope seems pretty good for PA. A quick and dirty setup still gave me only 32 pixels of drift in over an hour using a 400mm lens - that was with me guessing where polaris should be.

The danger for me is I get sucked into writing ever more complex software instead of using the thing - but I do want to roll my own

Neil

PA is ok if you can see it Neil. Dead north of me is B'ham city centre. i generally can't see it at all. If clear south is "ok".

In some ways there isn't much difference how each set up is aligned. iOptron, point at pole star and then their 2 star alignment. Done that way I assume so that the axis can be set more accurately. Vixen if I remember correctly telescope level and pointing east west. Celestron pointing at the meridian and Meade level and north south. Vixen were the first as far as I am aware to offer solar system alignment including the moon pointing out that it wouldn't be terribly accurate. They also offered a button press that could be used later once something had been centred. I think both Meads and Celestron offer much the same now. Celestron offer some gizmo that can be plugged into the scope and it will align itself. It recognises star formations. It seems they are still updating it and it wont work on equatorial mounts. They have probably nicked some open source plate solving software. The main manufacturers offers the same methods in alt az or equi. Not iOptron though - equ and alt az come with different controllers.

Really they are all just setting basic angles as a starting point. For instance if some one didn't know how to set for the merdian they could use a digital level and set the scope with that. The same could be done with iOptron for the pole star if it can't be seen. A lot of it goes back to the initial methods. The scope chooses which stars to finally align on and centres them roughly for the user to adjust. Now they usually offer a choice and 1 star, 2 stars and solar system and a later correction as per Vixen have for a long time - apart from iOptron but I would need to check that. I don't think it offers a choice of which 2 stars it will keep swing to,

The problem with iOptron is that they are the new kids on the block. All sorts of thing offer the facility to work with Meade., both old and new stuff and the protocol is simple, Not sure about Celestron protocol.

I thought the 2 links I posted might be of interest. They control goto scopes and add things like auto focus and complete remote operation including camera control. They drive the scope by sending stellar co ordinates. The 2nd link is the more interesting one. The work horse is a rasberry pi and graphics and star charts plus guidance via a tablet. It works remotely over wi fi. It uses dslr control software from the open source community and other bits and pieces from the same source. The Indi one is professional observatory stuff and uses x m l to set what a driver actually does. The driver is sort of generic and can drive anything. Great but x m l is complicate and many complain that there isn't even a decent editor available for it.

I'd guess you are aiming to say that the scope is aligned on the pole star using a polar scope and then working from that but I suspect you will still need to add corrections and the sums to go with it even then. I'm not sure if that facility is built into stellarium software. I get the impression it's built into the mount / controller.

John

-

Sounds similar to the typical open-source build documentation. Done in the form of a wiki with multiple hypertext links fanning out in a branching tree structure. Virtually impossible to construct a decent document package out of it for use in the workshop. Total abuse of the hypertext philosophy imo, where the links ought to be used as footnotes and explanatory detail rather than the main thread of the documentation.

ASCOM as it is now comes from the days of dev kits. Every software man and his dog just had to have a dev kit 'cause microsoft did them and they too masked what is actually going on. It's worse these days as C++ and various compiler outputs are supposed to document the code. There has also been a period when documentation was done by what in real terms are not software people who may not even really know what is actually going on. It leads to extremely wordy documentation that would even have page after page of the so called philosophy used to generate the code and hardly and use orientated docs at all.

John

-

I have no objections at all about this thread, and similar, but can I put in a plea for them to be written in English ?

> I thought the 2 links I posted might be of interest.

They certainly are, but over the weekend I had to put in about 12 hours of work on my 'other job' whilst juggling with various issues on here...

My problem for alignment is that LP, trees and buildings mean that my sky is like looking up a well. Getting two stars

I suspect that the best bet for me is either autoguiding, so PA is less important, or any system that only needs a couple of stars in limited locations.

The advantage of 100% homebrew is I can just add what I need, when I need it. Bear in mind I will enjoy working out my own software as much as enjoy using it - I even feel using a Polulu is a bit of a cheat

Very busy week now pulling MEW226 into shape. I am hoping that next week I can get some serious workshop time to at least line up my three priority projects ready to go: the mount, my 'ancient engine' and the Adept.

Neil

If you are interested in this area you will have to make use of the web to find out what terminology means. Often wiki what ever it is will produce some information. Unfortunately due to the way some one wrote the software that runs this site I can't put the letter x m l together as one word as it will assume I am not posting plain text.

John

-

Neil,

Referring back to KWIL's comment, and my follow-up [on page 1]

Thinking about it further: Your mount may well be used for imaging deep-sky with a camera rather than a telescope, and therefore I revise my recommendation ...

"Building a GOTO mount for the Telescope Astronomy" would be an exemplary title for the thread.

MichaelG.

.

P.S. ... I simply suggest this as a practical way of helping people to navigate the site.

When I entered goto mount into google I had 1.5m hits and all I can see is details of goto mounts. Even one pointing out that they might be called go to mounts as well.

Now I have added more trash to the thread that doesn't have any relevance to the subject..

John

-

OK, I have put together a schematic for the mount driver. It's not going to work as a picture, so if anyone is interested, here is a link to it as a PDF, produced in Eagle.

Goto_Scope_Schematic.pdf

Comments welcome.

Neil

Neil

Curiosity has got the better of me, is the purpose of JP4 or the switch so that you can test the PSU?

IanP

Well spotted Jason, I would normally put 100R resistors in there for Justin (Justin Case).

Also I used the order code for the mosfets instead of the part number! It's RFD14N05L.

> again the ramps has decoupling and power planes ...

All my decoupling is sitting up at top left!

Will see what the layout looks like but will be sure to have some caps by the carriers and keep their 12V well away from the 5V bits - ah, just noticed none of my decouplers are 12V - moved one down by the carriers and changed it to the 12V net.

Next challenge is the layout, hope to be able to do it SS.

Neil

Edited By jason udall on 24/11/2015 15:52:16

> Flyback/catch diodes for the mosfets loads.

Resistive loads only.

> To appease Justin. I might also suggest header/dip switch for ms0 -2..

I have it under s/w control at the moment, but if you switch from one step mode to another and back you lose your place. For this application lost steps are a big no-no and at 20 MHz I can stall the stepper at maximum microstepping anyway.

> vref on the stepper carriers..lead it out because accessing it on the polo is fiddly.

The onboard pot isn't too fiddly, set and forget.

Neil

I'm good at fiddly bits.

Neil

They show drive currents up to 20ma per pin but some where in the data sheet there will be a limit on total drive current across all ports - well there should be but I can't see one so if at work I would ask.

A bit naughty on the mosfets Neil. The port pins are floating during reset and till you do something with them so there should be pull down resistors. Where I come from there would probably be a cheap inverter in the way back to the processor and a pull up resister on the front of that, The port pins do have clamp diodes on them though so should be ok without the additional gate. I'd looks and see how well the fets switch with 2k in the gate circuit and not go lower unless really needed.

The automotive industry use truck loads of IR avalanche rated logic level mosfets for solenoid driving, hence some being dirt cheap. No clamp diode needed for inductive loads. Increasingly high side drives are used from the same source so some of those should be dirt cheap too. You may well find these have other advantages ie pull ups and resistors in the way etc. Things have gone that way as it keeps the power source in the ECU rather than trailing about all over the place.

John

-

I'm not minded to build in extra components for the purpose of protection that isn't needed for the application in hand. I'm not switching motors and with a lead-acid battery a few hundred mA into the dew heaters at switch on isn't going to cause any woes.

I can find plenty of examples of no or much smaller gate resistors, and the transistors I've chosen are meant for direct drive.

Now I've wasted lots of brain power on trying to work pout what actually happens (I'm not blessed with SPICE).

With 100R a first estimate value for the peak current would be 5V/100R=50mA and a gate capacitance of 700pF means the time constant for the gate is 30nS, so after 30nS the current will be 24mA.

But the maximum current from the I/O pin also depends on the rise time and for an AVR that is about 20+(0.1 x load-capacitance-in-pF) or about 90nS.

Modelling it as best I can using excel, the gate voltage lags the output voltage and assuming the output voltage rises linearly, the maximum current through a 100R resistor is 15mA, around the middle of this graph.

, so the peak current would be limited more by the rise time of the gate than the resistor and is unlikely to approach the 40mA limit, even for nanoseconds.

Equally, pull down resistors are only an issue if the mosfets being switched on could cause problems - unlikely here.