A number of folk have commented they would like to see more build threads and also that making astronomical equipment is more interesting to some than the pretty pictures.
I am part-way through a project to convert an ordinary EQ3-2 equatorial telescope mount into a full GOTO system – one that I can hook up to my computer, align and then tell it to find various objects in the sky without having to use setting circles or 'star hopping'.
The project will be a combination of tweaking and adjusting existing parts, making small gearboxes and motor drives and the electronics to control it.
At the moment I just have a simple 'proof of concept' tracking drive. This thread will summarise that and then follow through as I make the finished GOTO system.
I may drop in a few other related accessories along the way.
If ever there was a non-cost-effective of obtaining a GOTO system this has to be it … Don't account for your time … remember this is amateur work in the most noble sense of that word.
Just to whet the appetite, this is the current right ascension drive. I've since modified it a bit. Note the use of gears scavenged from old computer printers. Also an Arc Euro 'Bristol' handle. I will take some photos of how the slightly modified version is put together.
I now know its it a mount that make the telescope point to a particular place in the sky, but is the name GOTO because its 'goes' to where you tell it?
Just to add to the topics confusion, should this thread been in the 'build' section rather than related hobbies?
I now know its it a mount that make the telescope point to a particular place in the sky, but is the name GOTO because its 'goes' to where you tell it?
Just to add to the topics confusion, should this thread been in the 'build' section rather than related hobbies?
Ian P
Q 1&2 Yes, same as that, although 'goto' mounts track as well.
Surely it is a 'computer controlled telescope mount'. The GOTO part is just a software feature that is optional. Other software functions might be auto tracking, or star following, or parking at the end of a viewing session.
I a sense you are right Bazyle, because once I have a box that can respond to the commands from a computer (there are a number of standards) all those functions and more become available. I still need to make the gubbins that go between motor and computer, and it's my aim to include at least a basic goto function in it so I don't need to have a computer with me.
My intention was to include the electronic part as this is an upgrade to an existing tracking setup. For a start, it requires a second motor.
My motivation is the frustration of trying to find things a few evenings ago when poor seeing made it difficult to star-hop, and my skills using the setting circles are poor. By the time I had my target centralised in the camera and the camera rotated for a decent framing, I took a test picture and it came out entirely blank.
But this also allows me to focus on other areas that may be of interest. I won't make an extended discussion of the software, for example, unless pressed to do so.
My starting point is an EQ3-2 mount fitted on an EQ5 tripod, fitted with my own gearbox for RA drive using a medium sized stepper motor. The reduction ratio is greater than normally used so the 'slew rate' is modest but the drive is smooth which matters more to me. I have a control box that allows solar, sidereal and lunar tracking rates and fast slewing at various different speeds. I also have a motor/gearbox combination for declination, but I haven't wired it up.
I plan to cover areas such as:
The choosing of gears and a gear ratio making of the simple plate-backed gearboxes. This should be of interest to anyone thinking of using a motor of any type to drive a relatively lightly loaded reduction gear train.
The use of a Polulu stepper driver board, and how to calculate the appropriate drive rates for different output speeds.
My method of designing and making printed circuit boards.
Making a case that is both robust and practical and suitable for mounting directly on the tripod.
Dismantling and regreasing the mount.
Making a practical and usable handset.
Making a stepper driven focuser.
Making a portable 'power pack' with outputs suitable for driving other accessories (such as dew heaters).
I will also looks at thing such as casing the gearboxes – this would be an ideal task for a 3-printer, I may resort to plastic card or sheet metal, or I may try producingan STL file then leaning on someone with a printer
My initial aim is to simply be able to centre a 'known object' and then enter its co-ordinates. I can then either enter a differential move or an absolute move to take me to another object. I shall make the electronic hardware so communication with a computer so I can access other functions through 'Stellarium' or a similar program. I will also include an interface to allow an 'autoguider' to be plugged in and allow more accurate tracking.
Not quite the same, but could be adapted for the job, a few years back on the Stirling Engine Forum there was quite a long thread for a tracking device for a reflector for a solar powered Stirling Engine, the method we came up with in that case consisted of a solar cell that ran a motor until the relector cast a shadow over it, then as the sun(earth) moved the motor started again. Manual reset for the next day. A computer operated system, with auto reset would be much better.
Neil, were you intending to make/adapt an ASCOM driver for it? Seems it should then be able to interface easily with all sorts of astronomy software, much of it free. One example here.
Ian, on a visit to Jodrell Bank, I encountered a small radio telescope attached to a chart recorder. Using the joystick, I got it to point to the Sun, and the chart pen recorded a rise in the trace. An observer said, "How did you do that?" I said, "Easy, just move the dish until the shadow cast by the central aerial mount disappears, then its pointing at the Sun"
Later, when I set up an old Sky dish to do this myself at home, I had a dish with an offset feed, so I had to invent a device to show which way the dish was pointing. A few strips of wood created a false shadow-caster, and it worked really well!
The problem with Ascom is that despite being open source, they are too clever for their own good.
Instead of having simple set of documentation for the communications, you have to download a byzantine 'platform' and try and extricate them from different parts of it. Its a classic example of object-oriented programming – imaging trying to understand how a body works if presented with a set of jars each containing an isolated organ.
After emails asking about access to a single document explaining the standards to the Ascom team went unanswered, I gave up trying to find the wood amongst the Ascom trees. (<Can you tell I'm grumpy?>
Instead I found "iOptron® Mount RS-232 Command Language 2014" which has all the features I need and is compatible with Stellarium.
Yiour sun-finders remind me of primitive IR detecting guided missiles.
Neil. Can I offer the arduin-mega/RAMPS/POLOU. As the guts of your build..if polou are strong enough.. Using the marlin firmware developed for 3d printers this assy. Gives you. Three 5amp outputs ..used for heaters ( add a thermistor and you xan regulate the dew heaters etc to a pre programmed temperature. Five stepper drives..4 synchronized at a time. Programming in G code familiar to cnc.. Onboard programm storage. .in sd card. Headless use..without pc host..with display and control knob… Five rc-servo outputs Six end stop inputs.. And thats just the easily accessible bit ( g code)…
I'm already stocked up on polulus – geared down ~10:1 a modest stepper has no problems turning the handles.
As for Arduino, I'm a died in the wool AVR addict – the chips in Arduinos. I already have an ATMEGA644P20 lined up – technically obsolete and a bit smaller than the one in the Arduino Mega, but more then enough I/O, timers. PWM etc.
I would still consider the Ramps/ mega combo… It is “cheaper” than the components. . And if well versed on arduino ide the marlin firmware is readily tweeked..
Now if you wish a challenge ..converting the carteaseian co-ords to polar or vise versa might be fun .. but for example the rostock and scarda 3d printers do this on the fly.. Well cart to polar..anyway… But even ignoring marlin or grble ..I do suggest a look at ramps boards for value.
The problem with Ascom is that despite being open source, they are too clever for their own good.
Instead of having simple set of documentation for the communications, you have to download a byzantine 'platform' and try and extricate them from different parts of it. Its a classic example of object-oriented programming – imaging trying to understand how a body works if presented with a set of jars each containing an isolated organ.
After emails asking about access to a single document explaining the standards to the Ascom team went unanswered, I gave up trying to find the wood amongst the Ascom trees. (
I use a spirit level and a compass. It's surprising how accurate that can be. What's wrong with Meade's protocol. It's compatible with just about everything and is in all of their scope manuals.
A couple you may not be aware of and both pretty powerful.
These nuts use x m l and are talking about thin clients but there is some use of a 'pi around. The other problem is that the insist people run bleeding edge Linux distro releases.
I'm inclined to agree with you about ASCOM Neil. What it's actually doing is buried too deep. I'd wonder about iOptron in terms of their method of aligning especially in unfavourable conditions, if you go that far – it swing back and forth between 2 stars. Celestron like the scope pointing at the meridian. Meads horizontal and pointing north.
I use a spirit level and a compass. It's surprising how accurate that can be. What's wrong with Meade's protocol. It's compatible with just about everything and is in all of their scope manuals.
A couple you may not be aware of and both pretty powerful.
These nuts use x m l and are talking about thin clients but there is some use of a 'pi around. The other problem is that the insist people run bleeding edge Linux distro releases.
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
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.
Instead of having simple set of documentation for the communications, you have to download a byzantine 'platform' and try and extricate them from different parts of it. Its a classic example of object-oriented programming – imaging trying to understand how a body works if presented with a set of jars each containing an isolated organ.
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.