Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Meade LX200 classic Arduino retrofit

Meade mount DIY planetarium software
  • Please log in to reply
68 replies to this topic

#51 mattjowil

mattjowil

    Sputnik

  • -----
  • topic starter
  • Posts: 26
  • Joined: 17 Jan 2021

Posted 12 November 2021 - 08:35 AM

Thanks for your reply Andrew.

Something about autoguiding now:

If I understand correctly a software like phd2 (actually the ASCOM driver) will send to a Meade telescope these commands during autoguiding:

:MgxDDDD# (x = n, s, e, w) with DDDD being the duration of a correction in milliseconds.

 

A couple of questions on this:

1. Is this referred to as pulse guiding?

 

2. Regarding east corrections, assuming the command ":Mge0100#" is sent.

Will this cause the mount to move eastwards for 100 ms at increased tracking speed, e.g. CorrectionSpeed = SetTrackingRate * 1.66?

 

3. In case of west corrections is it correct that the eastward rotation is merely slowed down?

For example ":Mgw0100#" will cause the mount to still move eastwards but at, e.g. CorrectionSpeed = SetTrackingRate * 0.66?

 

4. Does autoguiding also involve dynamically changing the speed of a correction, i.e. the factor that is multiplied with SetTrackingRate (1.66 or 0.66 in my example)?

 

So far I couldn't find a detailed explanation about what really happens under the hood apart from that "correction commands" are being transmitted.

 

Thanks a lot,

Matt


Edited by mattjowil, 12 November 2021 - 08:50 AM.


#52 OzAndrewJ

OzAndrewJ

    Cosmos

  • *****
  • Posts: 8,344
  • Joined: 30 Nov 2010

Posted 12 November 2021 - 03:18 PM

Gday Matt

 

1. Is this referred to as pulse guiding?

Yes. The command is a "send and forget" as far as PHD is concerned.

 

2. Regarding east corrections, assuming the command ":Mge0100#" is sent.

Will this cause the mount to move eastwards for 100 ms at increased tracking speed, e.g. CorrectionSpeed = SetTrackingRate * 1.66?

3. In case of west corrections is it correct that the eastward rotation is merely slowed down?

For example ":Mgw0100#" will cause the mount to still move eastwards but at, e.g. CorrectionSpeed = SetTrackingRate * (1 - 0.66 )?

Yes but maybe

Meade use different mechanisms based on if you are AltAz or Polar

and some firmwares have variable guide rates.

Based on using a GuideRate in arcsec/sec

 

For polar Guiding, the rates used are

RA = Sidereal  +/- GuideRate

DEC = +/- GuideRate

 

For AltAz, some firmwares use

Alt = Az = Current axis speed  +/- GuideRate

ie when you guide, only the respective axis gets adjusted

 

Most later firmwares actually convert the current axis rates

to polar coords then apply rate = AxisRate * ( 1 +/- Rate % )

ie when you guide, BOTH axes get tweaked such that

the resulting move goes in True RA/DEC directions

 

The 497/Audiostars also use different mechanisms

based on how the guide is done ( ie move, pulseguide or ST4 )

 

It can get messy lol.gif

( ooh and forgot, they also have another means of guiding that applies "instant adjusts"

that basically dont use a timed move, they adjust the encoder count required as the target

and move to it quickly, but that isnt used as much now )

 

Does autoguiding also involve dynamically changing the speed of a correction, i.e. the factor that is multiplied with SetTrackingRate (1.66 or 0.66 in my example)?

Not by itself

1) If the handset is set to speed 0 and you do a manual move or an ":Mnx#" arrives

2) A pulse Guide ":MgxDDD# " arrives

3) An ST4 assertion arrives

The mount treats the resulting move as a "guide" and uses a dedicated subroutine.

ie it saves current status, sets up for guide mode, does the guide, reconfigures status on end.

 

So far I couldn't find a detailed explanation about what really happens under the hood apart

 

Which hood lol.giflol.giflol.gif

As i mentioned above, there are semi unused functions for doing guides,

that IMHO would make guiding a much neater exercise

Instead of using time and guide rate, if you are designing your own system,

look as using "step" adjusts, where you send a command to the motor card

to build a delta into the required tracking position and let the motor card do it

We do something like this now for DEC guiding

in the GreenSwamp driver  ( for Synta Mounts )

A pulse guide in DEC is read by the ASCOM driver, but it is sent to the mount

as an axis based "Goto", ie send and forget.

This allows deadly accurate position moves, no timers, and it can run at high

speed to clear lash, thus removing reversal lag.

 

Andrew Johansen Melbourne Australia



#53 mattjowil

mattjowil

    Sputnik

  • -----
  • topic starter
  • Posts: 26
  • Joined: 17 Jan 2021

Posted 07 December 2021 - 11:03 AM

Thanks again Andrew!

 

I am back to PEC now and it gives me slight headaches regarding the precision of the PID controller that controls the RA sidereal tracking motion.

If I understood correctly, a perfect bin on an LX200gps should take 2.4 seconds. This would be the duration if PEC is turned OFF and the scope is just turning at sidereal speed.

 

Do you have any data that, when running at sidereal speed with no PEC, shows

a) by how much the bin duration fluctuates 

b) the actual speed calculated from the RA encoder signal

which you could share?

 

I recorded the bin duration on my system for approximately 5 minutes to get an idea and this is what I got (please see image below).

The y-axis is x1000 ms.

Is this fluctuation around 2000 ms (I have 240 bins, so 2000 ms is the ideal duration) acceptable or does the PID require better tuning in your opinion?

 

PEC_bin_duration.jpg



#54 OzAndrewJ

OzAndrewJ

    Cosmos

  • *****
  • Posts: 8,344
  • Joined: 30 Nov 2010

Posted 07 December 2021 - 03:31 PM

Gday Matt

If I understood correctly, a perfect bin on an LX200gps should take 2.4 seconds. This would be the duration if PEC is turned OFF and the scope is just turning at sidereal speed.

Technically, yes or no undecided.gif .

The non 16" mount has 180 tooth wormwheel and 200 PPEC bins per rev of worm

At sidereal, this gives 478.6894s per rev and 2.393447s per bin

Problem is there is no way to measure ( or use ) this data easily.

as the base loop clock in the LX200 runs at 225Hz, so thats the best time you can get.

As such, a PEC bin in the LX200GPS is properly defined as a set no of encoder ticks,

as that is the only thing you can use as a datum, but that is also fraught with indecision.

ie

The mount has a 50:1 gearbox and 256 line encoder

One rev of motor = 256 * 4 = 1024 encoder ticks

50 revs of motor = 51200 encoder ticks

With 200 bins per rev that gives 256 ticks per bin

However.... 51200 ticks is not necessarily one rev of the worm :-)  )

This is because the gears in the gearbox dont reset properly until 3 revs of the worm complete

and there are some shocking gearboxes out there.

This is partly why Meade went to a 3 turn PEC model ( but that also has its own problems )

Now thats a definition of the perfect world, but back to reality :-)

 

Do you have any data that, when running at sidereal speed with no PEC, shows

a) by how much the bin duration fluctuates

Sort of, but its not real time, as i had to poll the mount to see what happens,

and the data i got made no sense, as it was so ragged, i didnt believe it.

( I thought i was smart back then lol.gif  )

I then did lots of tests ( ref attached example log where i recorded the motor card comms

in different screens with PEC ON and OFF )

Once i started monitoring the motor cards ( vs read the main firmware )

i realised there was a smoke and mirrors exercise going on.

The limit in this case isnt the code in the main CPU,

its the main board PIC and how it reads the data from the motor cards.

I have hundreds of minutes of data collected from my test bench

and what it shows is the rate the encoders get read ( and the time taken to read an encoder )

can change at the whim of that PIC. In many cases, it can get up to 3 seconds between

encoder reads, and this totally destroys any precision in the PEC application.

ref attached plot which shows the end of a sensor detect followed by resuming polar tracking.

At the beginning, it was reading the RA encoder at about a 1sec period and tight clocking

but once it detected and read the sensor trip,

it went to 3 seconds per read and very long read times ( ie 270ms just to do one read ),

all of which destroys any precision ( timewise )

I also tested this by patching the firmware to dump out the encoder position every time it

was read by the main firmware. What it showed was the main PIC simply replied with

the last read encoder value until a new one came in :-)

 

b) the actual speed calculated from the RA encoder signal

Bucket loads, but it is like watching a mad womans chooks.

Most people assume a simple pwm pulse train gets sent, but it is anything but that.

It is a very complex drive system, tho the resulting pwm does smooth it out a bit.

 

I recorded the bin duration on my system for approximately 5 minutes

What is your drive system / gearbox etc, and does it fully repeat every turn of the worm ????

 

Andrew Johansen Melbourne Australia

 

NewBoardPolar.jpg

Attached File  LX200Polar Std30 RA15 Alt15 Locn15 Std15.txt   8.19KB   10 downloads



#55 OzAndrewJ

OzAndrewJ

    Cosmos

  • *****
  • Posts: 8,344
  • Joined: 30 Nov 2010

Posted 08 December 2021 - 01:38 AM

Gday Matt

 

And just for fun, i did a series of tests today on my testbenches for the ETX-125, LX90 and LX200GPS

MeadeTestBenches.jpg

 

All behave differently, in both the way the PWM is applied and the PID loop works.

As you are starting with a clean slate, i strongly suggest you just ignore what Meade does

and write your own code using your own algorithms, as you can then optimise it

to suit the speed of your CPU.

 

Andrew Johansen Melbourne Australia


Edited by OzAndrewJ, 08 December 2021 - 01:40 AM.


#56 mattjowil

mattjowil

    Sputnik

  • -----
  • topic starter
  • Posts: 26
  • Joined: 17 Jan 2021

Posted 08 December 2021 - 04:08 AM

Hi Andrew,

 

let me see if I can give you the right information. All this is still pretty new stuff to me, so I might mix up technical terms.

 

 

What is your drive system / gearbox etc,

I will focus on the RA drive in the LX200 EMC 8" (classic) since that is what I am dealing with.

The mount has a 180 tooth wormwheel and a 60:1 gearbox with a 90 line encoder.

 

One rev of the motor = 90 * 4 = 360 encoder ticks.

60 revs of the motor = 21600 encoder ticks.

I arbitrarily chose 240 bins per worm revolution so that gives 90 ticks per bin and one perfect bin takes 1.995 s at sidereal rate (45.123 ticks/s).

For our discussion, I will change that to 200 bins so it is easier to compare numbers.

 

At the risk of providing too much detail, here is some information on how I control the motor speed:

I use a Teensy 4.1, which is based on an i.MX RT1060 (ARM Cortex M7 @600 MHz) micro controller (MCU).

The two RA-encoder signals are processed by the integrated Quad encoder/decoder peripheral giving the absolute tick count since power-on.

Currently, speed calculation, i.e. ticks/s, is done every 200 ms. That is, the MCU counts the ticks that accumulated during that period and divides that number by 200 ms.

(It probably makes more sense to measure the time between two ticks for the sake of accuracy at low speeds.)

The resulting speed then goes into the PID algorithm which provides an updated output every 200 ms. This output is the PWM duty cycle.

The DC motor is controlled via a L293 half-H driver (1 A output) that receives the PWM signal from the MCU.

 

So, all the computing is done by the MCU. The remaining circuits in the LX200 classic I use are the motor boards that do nothing else but provide the square quad signals.

 

 

 

and does it fully repeat every turn of the worm ????

At the moment I don't know. I have been waiting for a guiding camera to arrive and since then for clear skies to do the measurement.

 

 

 

As you are starting with a clean slate, i strongly suggest you just ignore what Meade does

and write your own code using your own algorithms

This is exactly what I want to do. However, I am not sure I understand in detail how Meade does it and how it could be done in a better way. Need to do some more reading on this smile.gif 

 

 

the base loop clock in the LX200 runs at 225Hz

What loop is this and what is being processed/measured at the frequency of 225 Hz? I don't assume this is the cpu speed lol.gif

 

Thanks for all the information. It's very helpful.

 

 

Cheers,

Matt



#57 OzAndrewJ

OzAndrewJ

    Cosmos

  • *****
  • Posts: 8,344
  • Joined: 30 Nov 2010

Posted 08 December 2021 - 04:40 AM

Gday Matt

 

Currently, speed calculation, i.e. ticks/s, is done every 200 ms. That is, the MCU counts the ticks that accumulated during that period and divides that number by 200 ms.

(It probably makes more sense to measure the time between two ticks for the sake of accuracy at low speeds.)

The resulting speed then goes into the PID algorithm which provides an updated output every 200 ms. This output is the PWM duty cycle.

OK, that is much more coarse than what Meade does at present.
 

and does it fully repeat every turn of the worm ????

At the moment I don't know. I have been waiting for a guiding camera

You dont need a camera, it is a physical result of the tooth counts in the gearing.

ie how many revs of the worm are required before all the gears

are in EXACTLY the same position relative to each other.

 

>the base loop clock in the LX200 runs at 225Hz

What loop is this and what is being processed/measured at the frequency of 225 Hz? I don't assume this is the cpu speed

The LX200GPS has no civil/sidereal "clock", it creates/maintains one using a timer/interrupt.

This timer trips 225 times per second, hence is the smallest granularity you can get for "time".

In the timer routine, the system increments the "clocks" and sets a series of state flags

for things that have changed. It does no actual "detailed" processing, the flags trigger that later.

The main program then runs in a loop that calls whatever is required whenever it is required.

This loop handles processing of preset flags, keypresses, UART data, ST4 data etc.

Its timing depends on whatever else is going on.

It is this loop that talks to the main PIC to give instructions on what to do

ie read encoder, calculate PEC bin, send speed adjust  etc etc etc.

soooooooo, the time taken to read the encoder and determine if a PEC bin has tripped

can vary quite a bit ( in relative terms )

Its all very "loose", when it comes to precise time based operations

 

Andrew Johansen Melbourne Australia



#58 mattjowil

mattjowil

    Sputnik

  • -----
  • topic starter
  • Posts: 26
  • Joined: 17 Jan 2021

Posted 08 December 2021 - 08:11 AM

Hello Andrew,

 

 

OK, that is much more coarse than what Meade does at present.

Do you know how Meade does it and what their accuracy is?

I know, with my current approach I can only control the speed to within +- 5 ticks/s around the setpoint, wich is indeed quite coarse.

So the highest accuracy would be achieved by measuring the time (in ms or even µs) it takes from one tick to the next and then calculate Speed = 1 / Delta_t. Am I missing something here or is this correct?

 

Matt



#59 OzAndrewJ

OzAndrewJ

    Cosmos

  • *****
  • Posts: 8,344
  • Joined: 30 Nov 2010

Posted 08 December 2021 - 04:39 PM

Gday Matt

Do you know how Meade does it and what their accuracy is?

Nope.

Go back to post 18 and look at the black lines near the bottom of each plot.

That is the duty cycle calculated from the motors PWM.

It changes dynamically as it goes, and sometimes stops and sometimes runs in blips

and sometimes runs continuously, but its not a "stable" PWM pattern.

 

I know, with my current approach I can only control the speed to within +- 5 ticks/s around the setpoint, wich is indeed quite coarse.

 

OK, we are talking different things.

You mentioned 200ms for speed calculation, but was also mentioning PID,

From the plots i just linked, you can see that Meades control of the motor PWM

works "within" 6.5ms blocks, ( and the duty cycle constantly changes within each 6.5ms block )

but i dont know how often they actually read the encoder during this process.

The encoder traces can also be VERY odd at times, esp at low speeds

ref attached plot showing "ringing" and slightly out of phase quadrature data

Andrew Johansen Melbourne Australia

LX200Polar.jpg


Edited by OzAndrewJ, 08 December 2021 - 09:19 PM.


#60 Mlei

Mlei

    Explorer 1

  • -----
  • Posts: 57
  • Joined: 13 Aug 2016
  • Loc: Saratoga, CA

Posted 22 August 2022 - 03:18 PM

 

At the risk of providing too much detail, here is some information on how I control the motor speed:

I use a Teensy 4.1, which is based on an i.MX RT1060 (ARM Cortex M7 @600 MHz) micro controller (MCU).

 

So, all the computing is done by the MCU. The remaining circuits in the LX200 classic I use are the motor boards that do nothing else but provide the square quad signals.

 

Hi Matt,

 

Just read thru the whole thread and very interested in the project since I have 8” emc classic from 2000. I have a few questions:

 

From what you mentioned above, do you intend to commercialize this project in the future or just a pet project and may consider open source?
 

From what I heard and tested, Classic model has to have a hand box plugged in at the keypad port in order for RS232 port to work (to finish the initialization). I see you made a hand box connected thru aux port. I am not sure whether the aux port is similar to the rs232 port. Do you need to do something to get the scope past the initialization?
 

I have a functioning scope so if you need some help, let me know and I am glad to help.

 

Clear skies,

Ming



#61 mattjowil

mattjowil

    Sputnik

  • -----
  • topic starter
  • Posts: 26
  • Joined: 17 Jan 2021

Posted 23 August 2022 - 01:54 AM

Hi Matt,

 

Just read thru the whole thread and very interested in the project since I have 8” emc classic from 2000. I have a few questions:

 

From what you mentioned above, do you intend to commercialize this project in the future or just a pet project and may consider open source?
 

From what I heard and tested, Classic model has to have a hand box plugged in at the keypad port in order for RS232 port to work (to finish the initialization). I see you made a hand box connected thru aux port. I am not sure whether the aux port is similar to the rs232 port. Do you need to do something to get the scope past the initialization?
 

I have a functioning scope so if you need some help, let me know and I am glad to help.

 

Clear skies,

Ming

Hi Ming,

 

thanks for your interest.

Currently it is a purely private project I pursue to get into embedded programming and of course to have a fully functional LX200.

 

You are correct: the LX200 with its original main board requires the Meade keypad to initialize.

However, I replaced the main board with a custom made pcb and use a Teensy 4.1 to do all the work, so all that doesn't matter as I started from scratch.

Check out post #49 for a picture of the pcb I designed.

This is the part I am currently working on, that is implement the original features bit by bit.

 

I think the original aux port didn't provide much functionality on the original scope except for providing 5V for an optional fan. So I rerouted its connections on my pcb to accomodate the self-made hand box.

The original hand controller can still be used via the keypad port, I just haven't come around programming the teensy to accept its commands yet. That will come after I am done with the more basic features (pec, goto, autoguiding, etc.).

 

If you have more questions just write me.

Cheers,

Matt


  • Skywatchr likes this

#62 Mlei

Mlei

    Explorer 1

  • -----
  • Posts: 57
  • Joined: 13 Aug 2016
  • Loc: Saratoga, CA

Posted 10 September 2022 - 05:15 AM

Hi Matt, if I read correctly, you don’t intend to use any mechanical (gear box, worm gear, etc) and electrical (motors, electronics, power, etc) from LX200 except the fork enclosure. You may still use original power panel or encoder but they are temporary, will be replaced by the parts you made. Let me know if I misunderstood.

Have you looked at onStep wikis and it’s code base? There are already one or two showcases to implement onStep controller on LX200 classic. Without use of DC motors, it seems easier and more precise to use stepper motors on the RA/DEC and use belt drive to replace problematic gear box. It is said you can ignore the PEC training with auto guide on the onStep controller in AP application.

 

I began to prepare implement onStep on the newly acquired CG4 mount to see how it goes.



#63 mattjowil

mattjowil

    Sputnik

  • -----
  • topic starter
  • Posts: 26
  • Joined: 17 Jan 2021

Posted 04 October 2022 - 08:13 AM

Hi Matt, if I read correctly, you don’t intend to use any mechanical (gear box, worm gear, etc) and electrical (motors, electronics, power, etc) from LX200 except the fork enclosure. You may still use original power panel or encoder but they are temporary, will be replaced by the parts you made. Let me know if I misunderstood.

Have you looked at onStep wikis and it’s code base? There are already one or two showcases to implement onStep controller on LX200 classic. Without use of DC motors, it seems easier and more precise to use stepper motors on the RA/DEC and use belt drive to replace problematic gear box. It is said you can ignore the PEC training with auto guide on the onStep controller in AP application.

 

I began to prepare implement onStep on the newly acquired CG4 mount to see how it goes.

Hi Ming,

 

the things I replaced are:

- the original main board (this is the core of my project)

- both motor control boards (basically I made copies of the original pcbs)

- the meade hand controller (however, I intend to reuse the original one at some point)

 

I use all of the original mechanical parts, the original DC motors and the original power panel.


  • Skywatchr likes this

#64 Mlei

Mlei

    Explorer 1

  • -----
  • Posts: 57
  • Joined: 13 Aug 2016
  • Loc: Saratoga, CA

Posted 07 October 2022 - 11:34 AM

Have you disassembled the firmware on the main board? Since the classic is ancient product, the code might be easy to be read out from disassembly so you can see most of operation details. I think OzAndrewJ may have the disassembly for LX200GPS or he may know how to do it on GPS scope.


  • Skywatchr likes this

#65 mattjowil

mattjowil

    Sputnik

  • -----
  • topic starter
  • Posts: 26
  • Joined: 17 Jan 2021

Posted 10 October 2022 - 03:24 AM

Have you disassembled the firmware on the main board?

Thanks for that hint.

I tried that a while ago but without success and did not follow that path any further.

I mainly use the manual and the meade protocol documentation as a feature backlog and implement everything from scratch in C++.

 

I certainly would be interested to have a look at disassembled firmware from any of the meade telescopes.


  • Skywatchr likes this

#66 OzAndrewJ

OzAndrewJ

    Cosmos

  • *****
  • Posts: 8,344
  • Joined: 30 Nov 2010

Posted 10 October 2022 - 03:51 AM

Gday Mattjowil

 

Just for info, the disassembled firmware we work with doesnt cover the

way the motor cards work, as that is all in the protected firmware on the motorcard PICs.

( And it doesnt cover the way the mainboard PIC works either )

The commands sent to the cards is well understood now and has been published

for many years via the roboscope group ( and others ),

We also know the commands sent from the main CPU to the mainboard PIC

( and they arent the same )

but how the motorcards interpret them is a black box, ( as is how the PIC on the mainboard works )

Ie the main CPU firmware ( which we disassemble )

talks to the mainboard PIC ( which we know nothing about other than the protocol ),

and that PIC talks to the motorcard PICs ( which we know nothing about other than the protocol )

and the 2 protocols have subtle differences

ie its fun at times :-)

 

Andrew Johansen Melbourne Australia


  • Skywatchr likes this

#67 mattjowil

mattjowil

    Sputnik

  • -----
  • topic starter
  • Posts: 26
  • Joined: 17 Jan 2021

Posted 11 October 2022 - 02:39 AM

...

The commands sent to the cards is well understood now and has been published

for many years via the roboscope group ( and others ), ...

Hi Andrew,

 

thanks for your message.

Do you have a link to the relevant discussion in that forum that you can share?

Cheers,

Matt
 



#68 OzAndrewJ

OzAndrewJ

    Cosmos

  • *****
  • Posts: 8,344
  • Joined: 30 Nov 2010

Posted 11 October 2022 - 04:52 AM

Gday Matt

Most of the technical discussions ( and some worked examples )

are on the roboscope group

https://groups.io/g/RoboScope/messages

The basic protocols are listed there and also several examples

where people have designed interfaces to work directly with

the 497/Audiostar type cards.

For the LX200GPS type cards, the best recent discussions are on the

LX200 group  https://groups.io/g/LX200GPS/messages

where a user recently wrote an arduino controller to allow

his 16" LX200 to track satellites etc using his own code

https://groups.io/g/...PS/message/4599

( its long but it shows the logical process behind running the cards )

Note! There is a lot of extra functionality built in to the commands

( ie commands he didnt need to use )

but not sure if its of benefit unless you have a std setup

as the PIC on the mainboard does a lot of donkey work based

on what the cards report, esp re sensor tripping.

 

Andrew Johansen Melbourne Australia



#69 kilodeltafour

kilodeltafour

    Lift Off

  • -----
  • Posts: 1
  • Joined: 17 Mar 2021

Posted 11 April 2024 - 10:33 AM

Has this build information been released to the public, such as at a GitHub site so that others can participate, this seems like a great way to rehabilitate our older LX200 classics.


  • Nowthatsorignal likes this


CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics





Also tagged with one or more of these keywords: Meade, mount, DIY, planetarium software



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics