6502 Telescope Interface

[cbmeeks]

I have a couple of telescopes. I've wanted one of those expensive "GoTo" scopes for years but it's not in the budget at this time.

There are plenty of Arduino-based projects online for interfacing to telescopes so that you know what's in the eyepiece.

But has anyone here ever interfaced a 6502-based computer to a telescope?

Would be mega-awesome to interface my SBC to my equatorial-mount scope.

[GARTHWILSON]

I know C64's were used for the purpose.

[whartung]

What precision of math would such a controller need? It's a combination of the resolution of the scope motor plus the necessary precision of the geo location math.

In the end, I bet you don't need more than a couple digits behind the decimal point. Truth is, you can probably do the whole thing with an embedded EhBASIC once you can hunt down the equations. I bet it's FP is good enough. 16K of EEPROM for BASIC and control program, 4K of RAM (assuming EhBASIC can run in 4K), a UART for an external interface, telescope motor interface (need to be able to point the scope and read where it's pointed), SPI Keypad, SPI LCD display (w/backlight, amber would be nice), 1 or 2MB SPI Flash chip to store "galaxy data" downloaded via the UART.

Use a modern 6502 that can WAI to save power.

That would be a fun project.

If only the '134 could have it's ROM programed by an end user. It would be a good choice for this out of the box. Dunno if 512 bytes of ram is enough for BASIC, though. Wonder how much RAM could be saved if BASIC didn't have to use the parser and tokenizer (since you'd ideally already have the tokenized BASIC in ROM).

Even without it though, it would still be a good choice.

[cbmeeks]

I think the math is a little more involved. From what I understand, you have to calculate Sidereal time and other things (I don't pretend to know what they all are).

But you're probably right...EhBASIC could probably handle it. The decimal places may have to be a little high, however.

I believe my SBC would be up to the task. I already have serial, VIA, LCD and PS/2 keyboard working. But a simple keypad would be cool.

The GoTo scopes have an option where you can select an object you want and it will go into a "homing" mode. Showing deltas on screen and as you move the scope, it goes down to 0 on both axis until the object is centered. That would be a cool option.

I think the part that would be the hardest for me is capturing the movement of the scopes. I've seen some advanced homebrew options that use stepper motors to move the scope. I'm not looking for that. But maybe some pots, GPS, etc. to send data to the VIA.

It does sound like a fun project.

[GARTHWILSON]

What's the power of the telescope? 16-bit scaled-integer makes each step .0055° (or 19.8 arc-seconds) which I expect will always be more than enough to keep the target in the image, but may be a bit jerky in the movement if it also has to command stepper motors that make up for the earth's rotation. But maybe that part is not done by steppers. 24 bits would make each step about .077 arc-seconds.

[whartung]

Apparently Meade and Celestrons mounts have documented serial protocols that can be used to drive them. I didn't look at them in detail, however.

I should mention your controller would also need a real time clock.

As I understand it, many of the scopes are calibrated by pointing and 3 known stars. Combined with the current time of day, that's enough to pin point the scope on the surface of the planet. Obviously access to a GPS make that particularly easy.

I don't know what the math is involved to make the calculation properly. (ie. the actual formulas). Then you have, as Garth mentioned, the issue of precisely controlling the mount position. That may be a different level of precision.

However, is should be noted also that the amount of precision provided by the controller can be compensate by properly gearing the mount motor. If 19.8 arc seconds aren't enough, you can using gearing to increase resolution vs having to increase the actual precision of the data.

All depends on how raw you want to go. GoTo and tracking scopes have been around for decades, so numeric precision of the controller processor I don't think is a core issue.

[cbmeeks]

Well, the main purpose of anything I would want to build would be informational only. Meaning, I wouldn't want the computer to control the scope. But the other way around. The computer would display what was in the field of view as I moved the scope around (with my hands).

I'm not sure on the precision. That's something I have to investigate. Time to dust off my astronomy books.

[whartung]

cbmeeks wrote:

Meaning, I wouldn't want the computer to control the scope. But the other way around. The computer would display what was in the field of view as I moved the scope around (with my hands).

Ah!

Well, again, I guess it depends on what assumptions you want to make.

I saw on Google one project where a guy had a Dobsonian scope that essentially did what you want.

You're basically turning the scope in to a mouse. A couple of rolling sensors, a known "we're at zero" point, then some calibration.

I wonder if a GPS, a clock and "here's is the North Star" is enough to calibrate the scope for your purposes.

With 3 stars, you can certainly eliminate the GPS, but, ideally, you could eliminate the clock too.

[BigEd]

Nice idea to use a mouse: two high precision rotation sensors, and a nice serial interface!

[BillO]

I did this back 28 years ago for my father.

It was a program to run the telescope (an 18" Newtonian reflector) as an automated astronomical photometer. However, it ran on a PC, not a 6502. We used external stepper motor drives and the computer only needed to supply direction and pulse (step) information. The declination drive was my own design, but the RA drive we outsourced in order to get something that could micro-step for smooth tracking. Interfacing consisted of only 4 8-bit parallel ports (3 of which you would not need). The computer calculated the actual object positions from their RA and DEC along with the current date and time. The RA and DEC of each object was read from a file, the actual position was calculated then the number of steps to be taken, direction to take them, the acceleration and deceleration ramps for in each axis were computed, then the scope was moved to approximate position. The scope was then centered on the object using a CCD camera through a separate tube (a 6" refractor). If it could not be centered, it was assumed there was an obscuring cloud and the next object was read from the file and attempted. If an object could be centered, tracking was enabled and the photometric readings were taken using a pin-diode photometer and B, V, I and R filters. This was done several times for each object before moving on to the next. Once the file was done, the scope was returned to 'home' and the roof was closed.

The code was written in ANSI C and could not have been more than 1500 lines. While it compiled to more than 64K, there were a lot of bells and whistles in there that you would not need. I'm sure it could be fit into the memory space of a 6502 - and speed would not be a real issue.

I can't seem to find the source code though. That would save you ages. Well, weeks anyway.

Edit: Depending on your scope magnification and how accurate you want to be (object in frame or object in center) you may need a whole lot more precision than what is afforded in EhBasic. We were using 16 digits of precision using 64 bit math libraries. We may not have gotten away with 7 digits, but not sure how close 6 digits will get you to what you want.

[BigEd]

BillO wrote:

...Depending on your scope magnification and how accurate you want to be (object in frame or object in center) you may need a whole lot more precision than what is afforded in EhBasic. We were using 16 digits of precision using 64 bit math libraries. We may not have gotten away with 7 digits, but not sure how close 6 digits will get you to what you want.

Once you've got the bones of a program running with vanilla floats in your Basic of choice, perhaps move up to a higher-precision float library?

• Calc65: a BCD floating point package (Uses 8 bytes and BCD to give 12 decimal digits and 3 exponent digits.)

[bogax]

cbmeeks wrote:

Well, the main purpose of anything I would want to build would be informational only. Meaning, I wouldn't want the computer to control the scope. But the other way around. The computer would display what was in the field of view as I moved the scope around (with my hands).

I'm not sure on the precision. That's something I have to investigate. Time to dust off my astronomy books.

So as I understand you, you're going to look for interesting things and you want the computer to tell you
what it is, or at least where it is.

What are you going to use as a position sensor (sounds like it's going to need to do 16 bits or better)

[Tor]

I've never interfaced to a telescope, but back in 82/83 I and a co-worker implemented program tracking for a satellite dish (to track polar orbiting satellites). Not a telescope, but somewhat similar: The computer would position the dish so that it pointed to a specific point in the sky, although this would be updated continuously to make the dish move (to follow the satellite). My co-worker built the hardware and I wrote the software.

The code was 6502 assembly, and it would output 10-bits or 12-bits coordinates (I don't remember anymore if it was the former or the latter, one would give 1024 - 1024 resolution and the other 4096 - 4096 resolution). This was fed into a D/A converter (well, two actually) which provided 3-phase 115V to the dish for position, with the necessary feedback etc. built-in so that I didn't have to do that in code.

This is all from memory as I don't have the documentation anymore. I may have the actual software stored on some old floppy somewhere, but deep below the surface if so.

[Dr Jefyll]

Tor wrote:

This was fed into a D/A converter (well, two actually) which provided 3-phase 115V to the dish for position, with the necessary feedback etc. built-in so that I didn't have to do that in code.

Do you recall any further details, Tor? Sounds like this may have been a synchro aka Selsyn setup.
https://en.wikipedia.org/wiki/Synchro

[Dr Jefyll]

Somewhat related to a Telescope Interface, the following thread may interest some of you: Radar Controller hacks 6502 illegal instructions. "We used illegal opcodes and a piggy-back board to add instructions to the 6502 processor. [...] This was instrumental in the Forth interpreter we used to control a custom radar dish."

-- Jeff