It's the third Monday of July, which means it's time for -- you guessed it -- the second and final installment of this month's "According to Pete"! Last time, Pete asked what you wanted to hear about, and the people demanded more projects. We are nothing if not enthusiastic, so in this segment, Pete talks potential projects: equatorial telescope mounts, tonal frequency guitar LEDs, and pickup coils, oh my.
Vimeo link here.
There you have it! As always, if you have any questions or suggestions, feel free to leave them in the comments section below, and we'll see you in early August!
Pete,
Now that I've had a day to think more about this, I thought I'd share some thoughts on telescope control, based on my experiences.
Computerized telescope control has long been one of the more interesting embedded projects luring unsuspecting computer enthusiasts to try their hand at. In connection with this, it is best to remember the warning posted many years ago in an article in Dr. Dobb's Journal, "Underestimating the magnitude of a task is almost a prerequisite to attempting it." This is certainly true of telescope controller design.
First of all, this is your project, so You get to decide how you want to it, and how complex you want the software. You may not need every single possible error correction taken into account. It depends on what you want to do with it.
Second, there already is a fair amount of software out there to do telescope control, of various complexity and use. However, I've found I get the most enjoyment out of making my own system the way I want.
Third, there are several ways to start out. Let me list out some good old-fashioned reference books/articles. Use these as your fancy dictates:
For basic 'setting circle' functionality, you may find #3 is quite sufficent. However all the others are good references as well, depending on how much work and time you want to devote to it. #5 has a second edition available, and outlines several successful projects as examples of what can be done. (Source code is included.) It also has the advantage of listing the amount of pointing improvement that can be expected by each type of error correction. That way you can choose what error corrections you want to include in your system.
Fourth, decide on what is to be done, and why. Simply wanting to connect a computer to a telescope is not going to be enough. Do you want astrophotography, or just enjoy short sightseeing tours?
Fifth, think about telescope resolution for a few moments. A six inch mirror gives a theoretical resolution better than one second of arc. There are 1,296,000 seconds of arc in a circle. So an ideal optical encoder would have to give at least that much resolution, if not better. And that's only for a six inch! Optical encoders of that resolution are expensive. The standard encoders available to amateurs come in resolutions of 2160 to 8192 pulses per revolution. A 8192 pulse encoder means that each pulse covers over 2.6 arc minutes. Even with a 1 to 8 gear ratio to increase the counts to 65536 per circle, each pulse would equal nearly 20 arc seconds. If you want to use optical encoders, a good sourcce is US Digital. (I like the older style at http://usdigital.com/products/s2)
So, the needs and purpose of the system need to be decided on first to determine the required resolution.
I remember years ago discussing the requirements that had to met by some software engineers at a professional observatory. They had to guarantee that their system would aim the telescope perfectly 'blind', as the light from the observed distant very faint galaxy was being directed right to the entrance slit of a spectrograph. There was no eyepiece to aim the system with, and they had to keep that accuracy thru exposures lasting the entire night. They were seriously concerned about the cumulative rounding errors in the compiler's double precision floating point routines! You probably don't need that much accuracy, but it is something to keep in mind. 16 or 24 bit floating point libraries may not be sufficiently accurate.
Getting back to the encoders, if money is going to be spent on them, go ahead and get the highest resolution possible. (You could just drive stepper motors in open loop mode, and count pulses to the motors instead of encoders!) Lower resolution means that the object could jump all over the field of view of the eyepiece, or even go beyond it, as the motors move the scope around. Encoder gearing can help improve this further, but watch out for backlash. Accuracy can actually be lost if care isn't taken. Direct drive of the encoder shafts is easiest to start out with, so it's best to start there. Play with gearing later.
It's also best to leave off the motors until the rest of the system is proven to work first. Just read encoder position on the telescope controller display for initial pointing tests.
Sixth, expect the need to write interrupt driven code for any degree of high accuracy. The main timing problem with any type of telescope computer system is with keeping track of the telescope's position.
To understand this, let's take an extreme example. First, assume a maximum clock speed of 40 MHz.
A telescope has two axes of rotation. Each axis has 360 degrees of rotation, or 21,600 minutes of arc, or 1,296,000 seconds of arc. Even a small 6-inch telescope has a theoretical resolving power better than one arc-second, so ideally one would want to resolve position to a tenth of an arc-second.
It is required to have the telescope be able to track an object across the sky. This is quite doable with the design parameters listed above. The problem comes when the telescope is commanded to slew from one object to another.
The ideal telescope should be able to move as fast as possible to point to an object. Unfortunately, the realities of the universe have conspired to keep this from being an instantaneous event. First, the telescope inertia itself must be overcome to start moving from one position to another. Once moving, the telescope must also slow down as it approaches the final position. Between these endpoints, the computer system must keep up with the rapid influx of encoder pulses from each axis as it races along.
If one allows 30 seconds to move 180 degrees, then in one second the computer must process some 216,000 pulses from each encoder! At 40 Mhz that leaves at most 187 clock cycles for any interrupt latency under worst case conditions, and for the interrupt service routine's execution time. Remember too that other tasks have to have some time to run, which leaves even less time allocated to the encoder ISR. This seems to pose an incredible design requirement for the system.
Fortunately there is at least one factor in our favor. One desires these higher resolutions only with larger telescopes. For smaller telescopes and scopes with no motors, lower resolution encoders will most likely be used. For example, a manually positioned telescope could realistically have an encoder of only 8192 counts per 360 degrees. If that same 187 cycle limit was imposed, the telescope could be moved 180 degrees in as little time as two tenths of a second! So realistically, much more time is available with lower resolution encoders for the encoder ISR to work.
But this also means that if a very high resolution system is designed, then that system's slew speed is going to have to be adjusted so that it will never outrun the MCU's ability to keep up with the encoder interrupt service routines. Of course one could solve this problem by including a hardware encoder pulse counter for each axis. That would add to the complexity of the design, which is not desired either.
Another timing consideration is time itself. Keeping track of time accurately is at the core of any telescope tracking algorithm. Without that, one might as well just guess at where to point. The reason for this is that the celestial sphere continually changes position as the Earth rotates on its axis, as you know. This results in a multitude of time scales that have to be dealt with, all simultaneously. There are local time, Universal time, Greenwich Sidereal time, and local sidereal time, to name a few, and don't confuse the local date with the Greenwich Meridian date. Get the picture? :-)
To help with this, a real-time clock chip (RTC) is highly recommended for a design. Initialization of the RTC from a GPS receiver also simplifies the in field initialization.
Having built two controllers, and working on my third, I've had to deal with all these issues. I'd be glad to offer my expertise if you have any questions. Just email me privately. Then again, you most likely already know enough to get going now.
Dave
...OK, I've gone a little glassy-eyed. I'm in over my head, huh? I guess that's about the time you start making assumptions and start building something blindly. Can do.
Having never built anything like this before, I've never had to deal with any of it. But this is pretty eye-opening. I may track you down.
Do you really need diffraction-limited tracking all night long? Or do you just need the target to stay in the eyepiece for 20 minutes at a star party? Lower-performance designs may be adequate. Jim's Mobile sells a "Track-N-Train" rig that doesn't do any math; you just visually dial in the speed the two motors need to turn to track a given target (approximately). That's so primitive there's no gee-whiz to it, but it serves a purpose. Personally I would like to crack open a Celestron NexStar mount, and use those electronics to control a much larger telescope.
For visual astronomy, very likely no.
For most of us, we don't need diffraction-limited tracking. I would like to observe planets under moderate to high magnification without seeing them fly through the field of view, however.
That is why I selected the 10000 count encoders, as I believe I can achieve my goals with them without breaking my budget.
If you are planning on using your Dob as an imaging platform, that is when things start to get quite complicated.
Frankly, I would think it better to select an equatorial mounted telescope for imaging, as with alt/az imaging mounts you need to not only control the azimuth and elevation rates with high precision, you also need to spin the camera in the eyepiece holder at a precise rate that varies with the distance the object is located from the celestial pole as well as the observer's latitude.
If you are considering developing a field de-rotation system, this site may be helpful: http://www.stargazing.net/yizen/fieldrotation.html
Pete:
To help offload the work of keeping track of the counts on the optical encoders, I would suggest using a distributed approach using a PIC processor like the PIC18F2331 for each encoder, which has a peripheral that interfaces directly to a quadrature encoder and makes it a trivial matter to determine the present position of the encoder shafts whenever one wants. They are less than $6.00 in single quantities and available in DIP and surface mount packages, so breadboarding is also easy. If one were going for mass production, you could use a cheaper processor, but for a homebrew system these look great to me. I wrote a small c program which uses these to output the present position of the encoder pairs 10 times a second on a serial interface that I am willing to share with anyone who is interested.
I wrote the program so two identically programmed PIC processors output can be combined to form a single serial stream using a wired "or" of the serial output. This allows a single serial port on a PC or embedded controller to receive the data from both the azimuth and elevation axes.
So, my basic plan is to 1. Get my encoders mounted to my scope axis, 2. Use a laptop with a C program to process the serial stream of encoder information from the scope to provide digital setting circle capability. 3. Port the setting circle c code to an appropriate embedded processor to provide the same setting circle capability without requiring a laptop. 4. Start working on the selection and mechanical issues with the drive system.
By using a distributed processing approach, you get the ability to develop the solution in small, easily testable parts that provide functionality that is useful to the user in phases with less risk of having to re-do the entire design due to hitting a performance limitation with a single processor based control system.
The low cost of microcontrollers that are available today makes this strategy more viable then it was in the past.
David listed a very good set of references to go to, I would suggest one more, Telescope Control by Mark Trueblood & Russell Merle Genet http://www.willbell.com/tm/telecont.htm
A project of this sort offers one a chance to learn new things, and get the pleasure of tangible confirmation that you got it right, or have to learn a bit more.
That is why I am interested in doing this, as it would be much simpler to just order off-the-shelf systems that already are available to do this.
If you do decide to use optical encoders, be sure to make it easy to remove them from the scope as moisture has caused many optical encoders to fail. If it is simple to remove them when not in use, they are more likely to be removed and protected from the environmental hazards that could cause them to fail prematurely.
THERE IS A FAR SIMPLER WAY TO MOTORISE A DOBSONIAN TELESCOPE.
Yeah, I know - where is the fun in that!?!
Instead of motorising the pan and tilt axes on the scope, which will require knowledge of where you are and what you want to point it at, you can make a far simpler single-axis drive, similar to an equatorial mount. You also don't have to modify the telescope (much)!
A Dobsonian Wedge (or equatorial wedge) is a platform that your telescope sits on. The platform is angled according to the latitude you are at (so if you stay in one town you can make a fixed-angle platform). You align the platform to north (or south if you are in the southern hemisphere like me). Perhaps glue a compass to the base as there is no star like North Star at the celestial south pole. The platform has one rotation axis aligned to north and sloping at your latitude angle, so points right at the north star. You then have a drive (at a constant speed) rotating the platform around that axis - just like with the standard EQ mount.
You don't have to modify the telescope, except that some rotation brakes will be needed to keep the telescope pointed at the object you are looking at, particularly as the whole base will be on a sloping platform - depends how loose your bearings are. Depending on your latitude you might also want to have some clamps or similar to hold the telescope onto the platform.
The big disadvantage is that, depending on the size of your platform, the rotation might only last for an hour or two, then you have to "rewind" the platform back to the beginning. A fast drive option is handy for that.
I've been thinking of doing this with a worm drive driven by a stepper motor. A switch selects normal speed forward or fast speed rewind. A trim pot would allow for tuning the forward speed to the earth's rotational speed. A limit switch at each end of the travel.
The big disadvantage of Dobsonians for astro-photography is that the eyepiece also needs to rotate, and both mounts have that issue. Another stepper to rotate the camera in the eyepiece holder is desirable for either method.
Haha! I cut out wooden pieces to build a Poncet platform in 1983 - but I had no clue how to join them together, nor did I have a motor drive design, so that was the end of that. The true Poncet design bears the weight on slides moving across an angled board, and it works best above 45 degrees latitude. For lower latitudes, the weight rides on the edge of a segment of a large disk, which is actually a truncated horseshoe mount.
Either way, the result accomplished is true equatorial motion, so there is no image rotation.
Pete: You mentioned magnetometers to detect the scope's orientation, but the scope will most likely not be exactly level so accelerometers would also be necessary.
One technique that has been used for Alt/Az digital setting circles is to use encoders on both axes of the scope and to point the scope at two known stars on each setup. A transformation matrix is computed between the scope's orientation and the polar axis of the Earth that allows conversion between the scope based az/alt encoder counts and each desired RA/Dec coordinate pair.
This uses no magnetometers, no GPS, no accelerometers. If the encoders are attached in such a way as to allow the drives of the axes to be disengaged while the encoders still being able to detect rotation of the axes of the scope, the scope can be manually slewed to the vicinity of the next object without waiting for the scope to slew there.
If you want to get really fancy, least squares techniques can be used to compensate for the optical axis of the scope not being exactly aligned with the mechanical axes of the scope and any orthogonality errors in the mount itself. This involves making many observations of widely spaced known objects once and doing offline calculation of the correction factors to adjust for the errors in the mount. (This assumes these errors will be fixed, which may or may not be correct for a Dob given how the primary is mounted)
A paper on this method is available at: http://www.brayebrookobservatory.org/BrayObsWebSite/BOOKS/matrix_method_rev_d.pdf
If you want to track and locate fast moving objects like planets and the Moon, you do need to know what day and time it is, so a GPS is useful, and nowadays quite inexpensive.
Instead of a worm drive system, you might consider a belt or cable driven system with a tensioner that allows the drive to be disconnected for fast manual slewing between objects. This is since you want slow to medium speed drive for both axes for most object tracking with fine precision. Getting this precision and fast slewing speeds may be difficult to achieve.
One thing to be aware of is that with Alt/Az mounts the required tracking rate for objects approaches infinity as the object approaches the local zenith. This causes Alt/Az mounts to not be able to track objects as they pass directly overhead of their location. A circle around the local zenith of non-trackable objects exits with Alt/Az mounts whose size is determined by the maximum azimuth speed of the mount.
I look forward to seeing how you plan on proceeding with this project, as I am a Dob owner as well and wish to make my own tracking system as well.
I plan to do it in parts, first thing is to get a working digital setting circle system, then I will work on the drives.
Wow, thanks for all that. Definitely some ideas worth exploring, and the thought of a belt drive hadn't occurred to me. Obviously, I haven't worked all of this out yet. And I haven't decided if I want to build on the work of others or try to forge my own wheel, as it were. But the more I talk about it, the more jazzed up I get to do it.
Something else to consider is the use of a web camera and plate solving software to assist in precise pointing of the scope, one such software package is: http://www.astrometry.net/use.html This software can be used for personal use without a fee.
This software takes a image from some camera source of the sky and outputs the RA/Dec coordinates of the center of the image as well as its rotational orientation. It does this without needing any information as to where the scope is located on the Earth, or when the photo was taken. However, you can give the software a hint as to where to start looking in the sky to reduce the time required to get a plate solution.
This would allow you to home in on the exact area of the sky you wanted to look at by making a series of short moves between plate solves as you get closer and closer to the desired location.
At a minimum, this would be useful to quantify the accuracy of your telescope pointing control system.
The paper you refer to is not the latest revision, which is at: http://www.geocities.jp/toshimi_taki/matrix/matrix_method_rev_e.pdf
Also, there are web pages outlining basic equations, etc: http://www.geocities.jp/toshimi_taki/aim/aim.htm and http://www.geocities.jp/toshimi_taki/matrix/matrix.htm
Please note that trigonometric matrix algebra is not for the faint of heart. (I've taken Taki's original BASIC program published in Sky and Telescope, translated it to C, and then optimized and translated to Forth for telescope control.)
Whoa! : FORTH LOVE IF HONK THEN ;
Whoa! Geocities? That takes me back a ways...
yea pete ur a fan of perry the platypus(phineas and ferb)yipeee
Is there a south star for those of us in the southern hemisphere?? On a serious note though, as you say the math would be complicated so would be good to include for those wanting to do a tad more with Arduino than blinking LEDs :-)
Southern what, now? Yeah, sorry about that. Sometimes I forget how much bigger the world is beyond my tiny piece of it. And yes, I'll be including the math. And I'm fairly certain it will be wrong...
Finding the south celestial pole isn't hard. Project a line through the long arm of the Southern Cross. The pole is two and a half times the length of the cross "down" that line.
Hey Pete,
Here is a similar guitar project I found.
http://hackaweek.com/hacks/?p=365
-Doug
Thanks everyone for all the comments on the telescope project. I had no idea that we had so many people that were so well versed on the subject. I've clearly underestimated the size (not gonna say "scope" again) of the project... but I pretty much knew that I was. My fist inclination with any project is usually "Come on, how hard can it be?" Really freaking hard, apparently. But that's not going to stop me.
Hi Pete (and all),
Instead of using a magnetometer to determine orientation, you might consider using a search technique developed to deal with the big sky surveys (SDSS, LSST); it takes pixels from an image, finds centers of features (stars/galaxies) and uses the relative lengths of 4-tuples of nearby features to infer the orientation of the camera (and lense properties that affect the mapping). The approach is described in this paper and there's a really good video presentation and slide set to go with it. Plus, there is source code and even a free web service available. Your tax dollars (US NSF, US NASA, Canadian NSERC) at work!
If your considering doing floating point math instead of integer math on the telescope mount without a co-processor and drive motors, you may want to consider using the Parallax microprocessor. I did a solar project that use Lat, Long and Time as you mention and does all the trig to create output for servos. The code ( at http://obex.parallax.com/objects/807/ ) includes detailed comments and references to some good formulas such as the "Power From The Sun" online book that talks about translating directions relative to lat, long and time.
Pete: My telescope related project is much more... fun? I plan to make my own camera for deep space/planetary imaging. Got a couple of CMOS image sensors which i need to make breakout boards for (They're a PITA smd QFN variant package which is gonna kill me to DIY it so i'll need to get some boards made). Gonna hook it up to an SD card and USB 2.0 (the 480mbit one) via an FPGA with probably an arduino for overall control. BTW i'm surprised sparkfun dont carry the Xess fpga boards since the Xula one is open source.
Oh? We'll check that...
oh yeah, and I had considered making my own equatorial mount but there's too much mechanical engineering there and the last thing i need is more distractions..
5:57 I laughed so hard. "Ehhhh... And, uh, you know. Les Paul necks are good, but ehhh... I dunno."
Well, the truth is, I love Les Pauls. I just felt like I had to say something because I said the Jackson neck was wide. I dunno... it just doesn't feel right to me, but maybe that's cuz there's always weight in your hand (it's not balanced).
Oh great... as i needed one more hobby to spend my money on! Don´t you dare getting me interested in telescopes. :p
No-one has made a decent equatorial mount without some serious machine tools. You can make a trapezoidian equatorial mount without machine tools, but it's not going to track accurately & it's going to take forever to align.
Know what else you might play with? I've always wanted to build my own magnetic sustain on my trash Ibanez (like an e-bow with an FFT and some brains) Of course, you run into the fast processor problem (approaching something more easily handled with an FPGA than a uC maybe)
I'm a bit confused by your description of the magnetic guitar pickup. Guitar pickups are actually potted for the purpose of avoiding picking up anything microphonically. If you were interested in acoustically sensing the sound of the guitar, I'd look into a more surface vibration dependent (and significantly cheaper) solution than using MEMS mics. You guys have a piezo element that, not knowing the frequency response of, I'd be inclined to try.
I see where he's coming from in terms of microphonics in coil pickups, the body-shape and weight can effect the response of the strings (depending on what weight strings you play) and that makes it's way into the coils (the coil/string system acts as a frequency filter sympathetic mic).
But I'm with you on the piezo front. If you're looking for the resonant effects of the body, the piezo will be most reliable at reproducing those sounds. BUT, I think you'll get wacky waveforms from the MEMs Mics too...
Actually, you know Pete... if you think about the microphone being physically affixed to the guitar body, you may end up with a vocoder situation where the sound reaching the mic over air is being modulated by the (much hotter) sound being mechanically transferred into the mic. Under the strings that could mean some strange buffeting effects but I'd like to hear it.
I see feedback in your future.
Interesting. Well, I don't know anything until I hook it up, but I'll let you know the progress. I'll probably start in the next day or two.
In my continuing support of MOAR Pete, let's see that ink, man!
Hey Pete--would you consider documenting the process you go through when you build the telescope mount and posting it somewhere? I love astronomy and electronics/programming and I'm excited to see the telescope project, but I'm not much good at mechanical engineering :P
I have messed around with all the data base of corrections and similar approaches. Nothing has ever worked as well as closed loop autoguiding and there are a lot or nice little autoguiders out there now on small refactors or that pick off a guide star with a little prism. There is a very old yet really cool method from a 1960's book "The Scientific American Book of Projects for the Amateur Scientist". Expensive, even in paperback reprint. A disk that is opaque on one half spins in a plane normal to the optical axis and the target is a photomultiplier. The output of the PMT will be constant if the disk is centered on a guide star so that half the light is blocked all the time. The deviations are related to angle of the disk and adjust the drive motors. The same book had a prism moved by coils (like a Sony TRV900 MiniDV for anti-shake) to counteract faster atmospheric deviations. I have not seen the prism idea adopted in modern high end amateur equipment, so it might not be significant. Worth looking at - it is nearly Steam Punk.
I don't think I have a choice but to document everything. Some amount of the mechanics will undoubtedly go into the calculations, so I'll have to talk about everything.
Pete: I would really like to see how you decode your GPS for the data/day
That's just parsing the NMEA data. You look for certain characters (or count comma's in most of my cases), then start grabbing ascii and translating into numbers, blah, blah, blah... It's messy and a pain, and I'm sure just about everybody does it better than I do. But yeah, all the code will ultimately be posted somewhere.