68 replies to this topic

[mattjowil]

Hi all,
 
I am new here and signed up because my google searches frequently lead me here. I figured this community has the knowledge to help me with my project.

 

1. First, a quick background

 

Some time ago, back in 1994, my father and I bought a Meade LX200 EMC 8" (I believe it is commonly referred to as "LX200 classic" nowadays).
At some point, unfortunately, the electronics died and for many years I just used it manually and eventually not anymore at all.

Astrophotography was something I had wanted to pursue but without automated tracking this was now a tedious task.

 

A while ago, I started programming an Arduino to control my digital camera to take pictures of water droplets fallling on a water surface. I soon realized, that with an Arduino you can do about anything, so I thought, why not replace all the old electronics of the LX200 (except for the motors) by an Arduino.

 

2. The current status - Arduino controlled LX200

 

By the end of 2020, I managed to have an Arduino Mega 2560 control the RA-motor of the telescope in a controlled fashion using the original optical encoder. That is, the motor speed is closed-loop controlled to run at constant speed in order to track celestial objects.

Apart from that I am using a second Arduino Mega 2560 with a touchscreen module as replacement for the original keypad-controller. Together with the selfmade handcontroller, I am currently able to perform the following tasks:

• turn the scope in all four directions (N, S, E, W) at three different speeds by pushing the respective buttons on the touch screen (manual mode)
• turn on tracking and adjust the setpoint to match it to different celestial objects (automatic mode)

Doesn't sound like much but since I am not a programmer by training, I get excited every time I turn it on and it actually performs the very slow tracking motion.

Here are pictures of what the setup looks like:

 

Figure 1: During development and testing. Mounted were the power panel used to be is the Arduino Mega 2560 with the motor shield rev. 3 on top of it. The white board to the right is a rebuild of the original Schmitt-trigger circuit that converts the analog sine signal of the optical encoder to a digital square signal (1 or 0, ON or OFF, HIGH or LOW, ~0 Volts or ~5 Volts).

 

Figure 2: The touchscreen handcontroller in manual mode set to track speed. Pushing the arrow keys will turn the scope in the respective direction at that speed. "Output: 14" on the top shows the PWM value [0 ... 255] send to the motors at track speed. (I have yet to change the keynames to N, S, E, W)

 

Figure 3: With the original power panel back in place, the Arduino is safely tugged away but still accessible for programming via the blue usb cable. The Schmitt-trigger board hides were the main board used to be. Controlling the telescope with the Arduino handcontroller is made possible via the white network cable on the left. The telescope is now mounted on the equatorial wedge and ready for tracking.

 

3. What I am currently working on

 

The next step for me is to connect the telescope (i.e. the Arduino) to my Windows PC, so it can eventually be controlled by a planetarium software and possibly even by an autoguiding application like PHD through an ASCOM driver.

I can think of two options:

 

a) Implement a custom protocol on the Arduino and write the appropriate ASCOM driver

b) Use an existing Meade LX200 ASCOM driver and implement the protocol on the Arduino

 

Option b) seems more realistic to me given my programming skills especially after looking into writing an ASCOM driver for a telescope mount.

 

4. And here is where I need help:

 

I implemented a very small part of the LX200 serial protocol, documented in the LX200 manual, on an Arduino so that it answers to the commands ":GD#" and ":GR#" (without the "") by sending declination and right accension, repectively. Stellarium accepts this and shows a mark at the coordinates currently hard coded in the Arduino when I use the build-in LX200 driver!

However, when I choose an LX200 classic ASCOM driver, which I downloaded from the ASCOM-website, the driver does not connect to the Arduino although COM-port settings are correct and according to the LX200 protocol.

• Does anyone know, what the real LX200 classic sends out via the serial port upon startup to identify itself as an LX200?
• Is there any documentation about what the ASCOM drivers for the LX200 classic specifically expect?

I appreciate any comments, ideas and of course help from people who have tried something similar with an LX200. I am also happy to share any knowlegde and the progress of my project if that is desired here.

 

Best regards and good seeing,

Matt

 

P.S.:If someone happens to be able to post a sound recording of their LX200 classic in tracking mode up-close, that would help me judge if I got the PWM frequency correct.

Edited by mattjowil, 18 January 2021 - 05:45 AM.

[rferrante]

It seems from the photo that you do not have a hand controller attached. The LX200 Classic wants to hear that its hand controller is attached, via a signal from it, before completing its boot-up testing and making itself ready to receive commands through its RS-232 port(s).

 

I don't think the LX200 sends anything out through its RS-232 ports to identify itself as an LX200. As far as I know, the RS-232 protocol is command-response.

 

I'm not sure what you mean when (photo caption) you mention the analog sine wave signal, since the signal sent from the motor encoder boards is a square wave quadrature signal.

 

You may want to look at some information here: http://skymtn.com/ma...stro/decfix.htm

[rferrante]

Ah, I think I misread something in your post. You're taking the signals from the encoder boards, probably, at the test points, which explains your sine wave description. Apologies!

[blp042]

Wow! What a cool project. I have a problem with my LX90. If like to keep up with your progress. Perhaps I can make use of it with my telescope.

[mattjowil]

Ah, I think I misread something in your post. You're taking the signals from the encoder boards, probably, at the test points, which explains your sine wave description. Apologies!

Thanks for your immediate reply. I believe I had misleading information in my original post, which I corrected.

I am not using any of the original electronics except for the power panel; I rebuild the small motor circuit for the RA motor on a breadboard (seen in figure 1) to provide the square signals and these are fed to the main Arduino controlling the motor speed.

I also do not use the original hand controller but a self-made one connected to the main Arduino for basic speed control (manual slewing, and turning tracking on and off).

The power panel I kept for convenience and it just provides power to the main Arduino and the motors and I use its AUX-connector to connect my self-made hand controller (behind the power panel I connected the main arduino to the appropriate AUX-pins so that it receives commands from the hand controller)

 

So, I am essentially trying to rebuild parts of the original LX200 functionality and mimic it using the Arduino platform.

 

 

 

I don't think the LX200 sends anything out through its RS-232 ports to identify itself as an LX200. As far as I know, the RS-232 protocol is command-response.

If that is true (and I think you are right) then I am still wondering why Stellarium accepts my arduino-rebuild (see section 4 of my post) but none of the ASCOM drivers do. I tried this one:

http://download.asco...5.0.4)Setup.exe

 

as well as this one:

http://download.asco...5.0.1)Setup.exe

 

Apparently, the ASCOM drivers send certain commands and expect something in return, but I don't know what it is exactly.

I would be glad if anybody had ideas on this.

 

 

 

 

You may want to look at some information here: http://skymtn.com/ma...stro/decfix.htm

Thanks also for this link. That was indeed my first source of information when I began working on the project and I strongly recommend it to anyone dealing with the LX200 classic.

 

Again, thanks a lot and I hope for more replies, thoughts and ideas.

[mattjowil]

Wow! What a cool project. I have a problem with my LX90. If like to keep up with your progress. Perhaps I can make use of it with my telescope.

blp042, thanks. Let me know how I can help, however, I am not familiar with the LX90 but I guess it shouldn't be so different from the LX200. 

[OzAndrewJ]

Gday Matt

Apparently, the ASCOM drivers send certain commands and expect something in return, but I don't know what it is exactly.

Depending on the driver, most send a series of commands to see if a Meade scope is there,

and if so what type, as the functions available via the driver will change based on type.

 

Andrew Johansen Melbourne Australia

[mattjowil]

Hi Andrew,

Gday Matt

Depending on the driver, most send a series of commands to see if a Meade scope is there,

and if so what type, as the functions available via the driver will change based on type.

 

Andrew Johansen Melbourne Australia

thanks alot. Do you happen to know what commands are sent by the driver (specifically the two that I am trying to use) or a way I can find out?

I would assume that any ASCOM driver intended for an LX200 sends at least a common standard set of commands but what are these?

 

Greetings,

Matt
 

[OzAndrewJ]

Gday Matt

You can load the source of the drivers when you install them

and read the code yourself. I am not familiar with the different drivers but

the first command is nearly always x06 (ack).

If a mount is there it will respond accordingly, then you can use other commands

like firmware dates, version no etc to try and figure out what mount it is.

If you dont read the code of the driver, you would need to use a port sniffer

to see what each driver sends.

You can read all the relevant commands possible via the Meade command protocol documents.

http://www.weasner.c...ocol2007oct.pdf

 

Andrew Johansen Melbourne Australia

[mattjowil]

Dear Andrew,

 

thanks for your help.

I used a port sniffer and found that two things are sent down the line by the "Meade Classic and Autostar I Driver":

1) #

2) :GS#

 

I can also see those commands in the source code in a file called "Telescope.cls" but I am unable to find what is expected by the driver as a response, expecially following the single "#" command.

The Arduino is programmed to respond to " :GS# " by returning a bogus sidereal time in the form " 12:32:45# " but that does not seem to satisfy the driver to move on with the initialization process.

Since I just started with ASCOM drivers, I might be looking in the wrong place.

 

(A few hours later...)

I just now found another ASCOM driver for the LX200 / LX90 posted in this thread:

https://www.cloudyni...lems/?p=9895826

 

This one works and based on the commands it sends, showing up in the port sniffer, I can implement the functions one by one on the Arduino.

No idea, why the other one does not work. I'd still be interested to know why that is the case. Probably there is something wrong the way I tried to use the driver.

 

Have a good evening,

Matt

[OzAndrewJ]

Gday Matt

I am unable to find what is expected by the driver as a response, expecially following the single "#" command.

OK, When in normal mode, ie not download or safeload mode

( Nearly) all Meade commands start with a ":" and are terminated with a "#"

( x04 and x06 are the 2 oddballs )

The commands come into a ring buffer and once a "#" is received,

the system copies the ":<cmd>#"  string into a "next command" buffer

which then gets processed in the next interrupt.

Sending a "#" by itself will effectively terminate/flush any trash in the ring buffer,

so the following ":GS#" gets a clean run.
 

The Arduino is programmed to respond to " :GS# " by returning a bogus sidereal time in the form "12:32:45#"

That response seems OK to me.

 

Andrew Johansen Melbourne Australia

[mattjowil]

Andrew, thanks again for your input. That's one of the reasons I am doing this project, to learn new things and of course to eventually have a working computerized telescope.

To anyone who is interested:

I managed to hook up an optical encoder from an old printer to an arduino. This gives me an additional measurement of the RA axis speed. What is nice about this is that the encoder disc attaches directly to the RA-axis, which is the speed that should be controlled in the first place:

 

 

Maybe this can also be a way to determine the periodic error and shed some light on the quality of my speed control, which is based on a simple PID algorithm. Unfortunately, the spacing of the bars on the disc - although individual bars can barely be seen with the naked eye - is still quite large. I get a signal roughly every 10 seconds, which is not frequent enough to use as controller input I think.

I am just letting it run for now to record some data and see if that can be used in any way further down the road.

Edited by mattjowil, 21 January 2021 - 05:06 PM.

[nitegeezer]

Rather than treating everything as digital, try reducing the intensity of the light source so you don't saturate the detector. If you can characterize the analog signal, you should be able to improve your position resolution so that you could detect the periodic error.

[OzAndrewJ]

Gday Matt

 

You appear to be having fun

Maybe this can also be a way to determine the periodic error and shed some light on the quality of my speed control, which is based on a simple PID algorithm.

Too many variables, esp as you dont know the encoder characteristcs.

Best thing is temporarily mount an OTA, then go outside and use PHD/PEMPro/Metaguide

to grab a long duration unguided data set.

That will give you a baseline of what yr gears and PE/Tracking look like.

You can then use that to compare what yr encoder gives.

Otherwise, you are comparing green jelly to red jelly :-)

 

Andrew Johansen Melbourne Australia

Edited by OzAndrewJ, 21 January 2021 - 08:26 PM.

[mattjowil]

Thanks Andrew and nitegeezer. Indeed, I am having a lot of fun :-)

I realized, however that the possibilities regarding what functionality to implement are quite vast and this project requires a more structured development approach. As a result I stopped coding for the moment in favor of writing a feature list and requirements.

 

Something else has been on my mind since the start but I couldn't find concrete information:

Does anyone know how the original LX200 electronics drive the motors? Is it done with PWM and if so, at what frequency.

Any help on this is greatly appreciated.

 

I am currently running both at approx. 60 Hz PWM frequency, which seems to work just fine. However, I remember the motors being barely audible with the original electronics when tracking at sidereal speed.

As I still have quite a long way to go until I will have implemented autoguiding capability for long exposures, I am currently not bothered by the possible vibrations this low frequency might cause. However I see it as a potential candidate for problems.

 

Good night,

Matt

[OzAndrewJ]

Gday Matt

 

Does anyone know how the original LX200 electronics drive the motors? Is it done with PWM and if so, at what frequency.

Not 100% sure of the LX200 "classic", but all other Meades are certainly driven by PWM.

As to freq, its very odd and has several levels/methods of control in it,

but for the LX200GPS and ETX125, it uses approx 20kHz.

Andrew Johansen Melbourne Australia

[mattjowil]

Andrew, great thanks.

 

 

As to freq, its very odd and has several levels/methods of control in it,

but for the LX200GPS and ETX125, it uses approx 20kHz.

I would be interested if you elaborated on the different levels/methods. Does that mean  for example, adaptively changing the PWM frequency depending on the rate that is set; or are there also different ways beside PWM or a plain DC power source to drive a DC motor?

I did try different frequencies (changing it by orders of magnitude) but found that I had to settle with a very low one to realize decent sidereal tracking speed. The motor axis has to turn at a rate of approx 7.5 rpm given the gear ratio of 1:10800, which is quite slow.

 

Matt

[OzAndrewJ]

Gday Matt

Does that mean  for example, adaptively changing the PWM frequency depending on the rate that is set;

No. The PWM has a pretty fixed freq and it gets applied in 6.5ms blocks

but they then vary the duty cycle dynamically within that block.

Ref attached logic analyser plots where i logged the motors and encoders ( with calculated duty cycle ).

You can see how dynamically the blocks of PWM change duty cycle during start and ramping

 

Andrew Johansen Melbourne Australia

Steady tracking at medium speed

Start up at guide speed in DEC (polar)

Start up at max speed

 

 

[rferrante]

Here is an oscilloscope screen grab of the difference of the two dec motor terminals. I moved the actual signals off screen for simplicity, this red trace is A ch - B ch. Both grounded to the motor encoder board's ground terminal. 1.00 ms/div horizontal, 2V/div vertical. This was captured for South commanded movement, at CNTR speed.

--Rob

 

 

Attached Thumbnails

• 

[rferrante]

Continuing..

 

Seems to be varying the pulse width and interval, and possibly amplitude as well though it also could be shooting for about 2V, and we're just seeing a lot of motor inductance related overshoot. This is when a constant speed has been requested, so it looks like the encoder output is monitored for speed and the motor given more or fewer pulses as needed to maintain speed. Very messy signal though, I'm going to try setting the probes somewhere else.

 

--Rob

[rferrante]

LX200 Classic by the way, just to be clear.

[OzAndrewJ]

Gday Rob

Understood re "classic". I dont have one to test, so can only use the later models.

That said, the data you have only swings about 6V max, and looks semi analogue.

Can you set a much finer time axis to see if there really is some form of PWM in there

and its getting averaged out or not displayed due to pixel scaling???

Also, dont use A-B, just A and B relative to ground.

 

Andrew Johansen Melbourne Australia

[mattjowil]

Andrew, Rob,

 

thanks a lot for your posts.

Rob, it would be really great if you could provide some more screenshots of your measurements on the motor.

It would be very helpful to know how exactly the motors where driven by the original electronics of the LX200 classic so I can transfer that to the arduino.

Since mine don't work anymore I cannot do a lot of reverse engineering here.

 

Really looking forward to more insights.

 

Matt

[rferrante]

Here are a couple of shots of the two teminals of the motor relative to ground, no math. One is at 1ms/div, the other at 200us/div, and both at 2V per div vertical. So they are centered around 8 volts or so.

 

 

Attached Thumbnails

• 
• 

[mattjowil]

Thanks Rob,

 

I'm still contemplating your plots. Was this at CNTR speed as well?

Just so I understand (and some thinking out loudly): you had placed two oscilloscope probes one on each motor pin and each relative to ground. So the difference of the two signals is the voltage drop over the motor pins, which is essentially what makes the motor turn in one or the other direction.

 

If that is correct I am wondering why the yellow curve is sometimes above the blue one. I'd think that this would cause the motor to turn in the opposite direction but then again all this happens on a very small time scale. Given the motor's inertia this probably just results in further slowing the motor down in the set direction, thus actively applying a brake.

What do you think?

 

As to whether the LX200 classic uses PWM to drive the motors, it is not so clear to me. It doesn't look like it but to know for sure I want to reproduce your measurement on my dec motor and see what the signals look like with PWM.

 

@Andrew: does the LX200GPS have DC-motors as well or did Meade use stepper motors in those models?

 

Matt