68 replies to this topic

[OzAndrewJ]

Gday Matt

 

The LX200GPS use DC motors, but they are much bigger/better quality.

The ETX and LX90 use toy motors like in the classic

but it would appear the drive mechanism changed between the classic and the ETX.

 

Andrew Johansen Melbourne Australia

[mattjowil]

Good evening Andrew,

 

but it would appear the drive mechanism changed between the classic and the ETX.

I am not familiar with the ETX series. Did they make mechanical changes, e.g. concerning the gearbox or did they change the way the motors are driven electrically/digitally?

 

Matt
 

[OzAndrewJ]

Gday Matt

Meade had a huge range of different small mounts.

( DS,DSX,DS2000,ETX,LX90, LXD55/75, plus some "DH" add on motor drive units )

The ETX started as small plastic fork mounts with short refractors then maksutovs.

They all had different forms of plastic gearboxes, but they used the small DC motors.

With the advent of the LXD75 and LX200GPS, they moved to better quality DC motors

with integrated gearheads.

I have no idea of the drive mechanism for the "classic", but the ETX were driven

via the 495/497 and use proper PWM, as per some of the plots i posted.

( My plots used a logic probe on each motor line relative to ground so actually showed

a full voltage swing. ie in the ETX/LX200, when the motor is powered,

( as per Meades patent diag, its a std HBridge )

a PCh mosfet opens fully on the +12V side and an NCh mosfet is driven

via a TTL level PWM feed in order to provide the motors ground )

The CRO plots for the classic dont look anything like that

but i have no idea of its drive circuitry either.

 

Andrew Johansen Melbourne Australia

[OzAndrewJ]

Gday Matt

 

Found a few links to the schematics for the classic

One here

http://skymtn.com/ma...iner/Analog.gif

would indicate the classic did/does use a complicated analogue drive.

 

That said, there is another vendor who refits LX200 Classics with Autostar boards

He leaves the motors/encoders in place and as such simply changes to the later simple PWM drive

so the motors should be OK to take it.

Based on the fact you are designing your own drive controller as well

i would suggest the simple pwm might be the way to go,

esp with the plethora of cheap new generation motor driver chips.

 

Andrew Johansen Melbourne Australia

[rferrante]

Was also CNTR. There is a lot of inductance (and inertia) associated with the motors, and I would not assume that the yellow curve being above the blue is because it was commanded to be. My guess is, the amplitude is set for the slew speed desired, and the pulse frequency or width is varied to keep the motor's encoder reporting the proper speed.

 

I don't think that the GPS uses stepper motors, they are servo like the classic since they have encoders. Andrew would know for sure, though.

[mattjowil]

Hi everyone,

it's been a while and I have been busy bringing one of the original motor circuits back to life for use with the Dec motor. In the process I had to realign the Dec-encoder mask, which was quite a pain. (Note to myself: never open the gear box again!)

That said, the scope now provides a position/speed reading from the Dec-axis again.

Finally, we also had clear skies, so I could test the tracking with my PID controlled RA motor. So far it is sufficient for visual observation and exposures of up to 10 seconds. However, over a period of approx. 10 minutes objects noticably move out of the center of the eyepiece for which I guess the periodic error is partly responsible.

 

This brings me to PEC, which will be the next thing to implement but I am not entirely sure how that works in detail. My current understanding is that during an 8 minute training session of the RA-drive you use the E and W keys to either speed up or slow down the tracking rate, respectively.

But what exactly happens when either of the keys is pressed?
Is the current rate increased(E) /decreased(W) by a constant value?

I read in the LX200 manual that in Guide rate, pressing E will move the OTA at 2x sidereal rate, while pressing W will slow it down to 1/2 sidereal rate.

Is this correct and does that also apply to a PEC training session?

 

The figure below illustrates my current understanding of a PEC training session:

 

I would much appreciate your input on this.

Matt

Edited by mattjowil, 22 February 2021 - 04:41 AM.

[OzAndrewJ]

Gday Matt

I cant talk for the "classic", but with the LX200GPS, when you train,

it uses sidereal +/- XX%   ( where XX is normally 66% )

You can also only use speed 1 to do PEC training, or it gets ignored.

PEC bins are not based on time, they are based on a set no of encoder transitions,

soooo you basically find out how long it takes to do a set no of transitions when guided

and compare this to the time for perfect sidereal, and work out an averaged rate for the bin.

The way the LX200s do this is actually quite crazy, but it is based on the fact that

the mount cannot read the encoders in a suitable timeframe, so makes "assumptions"

based on the time a key is depressed, ( vs the real encoder position )

Its a dogs breakfast based on guesses of what happened

Andrew Johansen Melbourne Australia

[mattjowil]

Hi Andrew,

 

thanks alot. I have to keep reminding myself that I am not restricted to how it was done in the classic.

So, I could implement PEC training in any way suitable. What would your idea of a proper training functionality be? Is there anything you'd like to see done differently/better than, e.g. in the LX200GPS?

I have no experience with PEC since I never used it and thus am not aware of any shortcomings arising from Meade's implementation.

Matt

[OzAndrewJ]

Gday Matt

What would your idea of a proper training functionality be?

Accuratel measure error over a set no of encoder transitions.

( but read the later paragraph re "orrible" :-)

 

Is there anything you'd like to see done differently/better than, e.g. in the LX200GPS?

Heaps.

Basically, in the LX200,you have a CPU that talks to a PIC ( on the mainboard )

That PIC talks to a PIC ( on the motorcard ) that counts the encoder steps.

The CPU to PIC comms are around 10x per sec

but the PIC to motorcard might only be one time every 3 secs for position data

( and inbetween, the PIC  on the main board just lies, by sending the last read data )

What should happen is the motorcard should be told to reset the speed

every time a certain no of encoder ticks has ocurred, rather than wait for the main CPU

to request a position and see if it has tripped.

This simply cant happen due to the slow comms involved.

ie The current comms method used in the LX200 is sooo glacial, you simply cannot get good data

and the playback mechanism doesnt match the recording mechanism so you

invariably get drift built into the playback.

Its like herding cats.

Also to try and get around the 8/3 error in the gearbox, they went to a 3 turn PEC model

( very novel and sneaky how they do it ), but the errors introduced by the tooth spacing

errors on the wormwheel swamp any benefits of this for most mounts.

Its just plain 'orrible.

Andrew Johansen Melbourne Australia

[rferrante]

Andrew,

 

I'm wondering, could it be possible the base drive speed is controlled closed-loop by the motor control board itself? There is a crystal there, so I'm not sure there is a reason why the PIC could not accurately control the tracking speed? Then the CPU would only need to send PEC corrections and ask for worm position so it could keep the PEC corrections in sync. And manual slew commands of course.

 

This is a purely hypothetical question, I don't have any knowledge of the motor control software on the GPS scopes.

 

--Rob

[OzAndrewJ]

Gday Rob

 

I'm wondering, could it be possible the base drive speed is controlled closed-loop by the motor control board itself?

That is exactly what happens with the GPS scopes.

The main CPU sends a speed request to the motor card, and the card does the rest.

 

Then the CPU would only need to send PEC corrections and ask for worm position so it could keep the PEC corrections in sync.

And thats exactly what happens.

HOWEVER

an LX200 has a 180 tooth wormwheel and 200 PPEC "bins" per rev of the worm

ie one rev of the worm is 478.6894 seconds, and one "perfect" bin is 2.4 seconds.

I have dozens of hours of logic analyser plots of what "really" goes on

and in cases, it can take over 3 seconds between position reads.

Soooooooo, when does a bin start and stop so you can work out the guides sent inbetween???

Meade dont use time because of this,

they count the interrupts a guide direction was asserted in the period

and assume this applied perfectly at the defined rate,

in order to come up with a true PE "error" in arcsecs for the "bin"

But they still dont really know when the bin trips, so its all mushy after that.

Andrew Johansen Melbourne Australia

[rferrante]

Thanks Andrew, I think I see... maybe :-)

 

So in each bin, there is a number of encoder pulses that were captured during training. A usual amount corresponding to normal sidereal rate, and a bigger or smaller number, depending on whether the trainer pressed or released the East or West button during that bin. Then the ratio of the normal count to the actual count gives the speed relative to sidereal, for that bin. But the interval being used during training jumps around and is not reliably 2.4 seconds, and can be off by a significant amount. It's possible some of it averages out over the entire 8 minutes, as long as the bin length averaged out to 2.4 seconds over the 200 bins. But even so in the meantime it would be exposing pixels that should not have been.

[OzAndrewJ]

Gday Rob

So in each bin, there is a number of encoder pulses that were captured during training.

Getting technical here, but no :-)

The worm and gearbox can both have quite large errors,

and have no "datums" to determine position,

so the only known constant for a Meade is the encoder on the motor.

The absolute definition of a "Meade" PEC bin is thus based on a set no of encoder pulses.

 

The Meade LX200GPS has 51200 "pulses" per rev of the worm

( 256 vane encoder and 50:1 gearbox = 50 * 256 * 4 )

sooo, one PEC bin = 51200/200 = 256 quadrature pulses EXACTLY.

The PEC data is actually stored as a speed multiplier "factor"

ie when a PEC bin trips, the system uses PECSpeed = Sidereal speed * PEC factor

 

The problem comes in how to calculate the PEC "factor.

Most other mounts can read positions dozens of times per second

so can use actual time taken vs theoretical time taken in order to get a percentage.

Because Meades read rates are sooooo glacial, you cannot get accurate trip times

or real bin trip positions, so they sum/count the time the slew keys were down

and use that to "assume" an error and reverse engineer a rate.

As such, the initial calcs are a bit woofy,

Then during playback, the real bin transitions can also be off by up to half a bin

so affects the time * rate corrections sent

Its all very rubbery, and guiding then hides the residuals ( as always    )

 

Andrew Johansen Melbourne Australia

[rferrante]

I see.

 

Wonder why they don't just do the PEC training in the PIC? It seems it could count and time things accurately with no communications delay.

Edited by rferrante, 24 February 2021 - 03:52 PM.

[mattjowil]

Hi Andrew,

 

could you please elaborate on the 8/3 error, I wasn't able to find anything that explains what that actually is and I am not familiar with this.

Does 3 turn PEC model mean that a PEC training session covers 3 worm revolutions = 24 minutes?

 

Thanks a lot,

Matt

[OzAndrewJ]

Gday Rob

Wonder why they don't just do the PEC training in the PIC?

The motor cards do a lot of other stuff like sensor detecting etc

and are very basic early model PICs.

My guess is there was no space left for code or EEProm for data.

 

Andrew Johansen Melbourne Australia

[OzAndrewJ]

Gday Matt

 

could you please elaborate on the 8/3 error, I wasn't able to find anything that explains what that actually is and I am not familiar with this.

The Meade LX200s use a cheap 50:1   Igarashi gearbox on the motors.

The gearing used inside the motor means the gears only truly line up in exactly the same spots

after 3 revs of the output shaft.

As such, any "PE" in the gearbox itself only repeats every 3 turns of the worm

and if the Gbx PE is large ( relative to the worm PE ) it affects the total model

The same problem afflicts a lot of Celestrons.

 

Does 3 turn PEC model mean that a PEC training session covers 3 worm revolutions = 24 minutes?

It does now.

Earlier firmwares used single turn PPEC at 8mins,

When the RCX models came out, some smart cookie figured out how to synchronise

a 3 turn model using only a single sensor on the worm.

Once that was done, they merged the method back into the LX200s.

In theory this is good, but in practice, the tooth form/spacing errors on the wormwheel

create far bigger errors and as such the model breaks down.

 

Andrew Johansen Melbourne Australia

[mattjowil]

Hi Andrew,

 

thanks for your explanation.

So if I understood correctly it would be necessary to do a PEC training for 3 worm revolutions in order to also capture the entire PE of the gearbox?

 

 

When the RCX models came out, some smart cookie figured out how to synchronise

a 3 turn model using only a single sensor on the worm.

Does this mean counting the Hall sensor pulses until the count equals 3, or am I thinking too simply here?
 

Apart from that, I think for the Arduino implementation there is no problem getting an exact and immediate encoder count (at rates up to center) as I am polling them at ~ 64 kHz. For slewing rates higher than that I saw that it misses pulses so in the long run I will probably need a second micro controller that only does the counting.

 

Matt

[OzAndrewJ]

Gday Matt

So if I understood correctly it would be necessary to do a PEC training for 3 worm revolutions in order to also capture the entire PE of the gearbox?

Correct, but as mentioned, the PE of the 3 different teeth used can be dramatically different

as the gears are a relatively low quality straight cut.

ie the modelling of the gearbox can often get mixed into the noise of the teeth

and the model ends up worse ( on average ).

That said, as you have a classic, you dont have the Meade LX200GPS gearbox so its all moot.

Maybe just reclarify what drive train you plan to use

and we can proceed from there.
 

Apart from that, I think for the Arduino implementation there is no problem getting an exact and immediate encoder count (at rates up to center) as I am polling them at ~ 64 kHz.

In that case, you have free reign to do what you want,

All the stuff we are discussing at present is how the LX200"GPS" works

and is limited by the slow comms.

If you could poll even at 100Hz, i personally would go back to a simple time based calculation.

64kHz is a no brainer to go back to simple time calcs.

 

Andrew Johansen Melbourne Australia

[mattjowil]

Hi Andrew,

 

thanks again for your input. I very much appreciate it.

I think I might have expressed myself unclearly in earlier posts. Let me try to clear up the possible confusion.

 

1. drive train

That said, as you have a classic, you dont have the Meade LX200GPS gearbox so its all moot.

Maybe just reclarify what drive train you plan to use

and we can proceed from there.

If by drive train you mean the motor- and gearbox-unit: I use the "classic" hardware. (I'm not a native english speaker but the translation left me assuming that that's what we are talking about)

 

So, I am limited to the mechanical hardware, which is that of the LX200 classic.

I meant the software/microcontroller part when I mentioned I am free to implement PEC training in any way suitable.

 

2. Encoder polling rate

If you could poll even at 100Hz, i personally would go back to a simple time based calculation.

64kHz is a no brainer to go back to simple time calcs.

You mentioned time based calculation but I am not sure if that was related to PEC training. The 64kHz is the frequency at which I currently poll the small motor circuits that output the square encoder signal. This is not fast enough for slewing at 6 or 8 deg/sec. On the classic I measured ~96000 pulses/sec at the highest rate (8°/s).

 

3. PEC training

With your information and measurements I did regarding the reproducibility of encoder pulses per worm period, I think it makes sense to base the binning of PEC training corrections on the encoder pulses.

Would this be the preferred method or are there better ways to do this?

It seems to me that a time based binning must rely on a constant worm period (8 min), which cannot hold once the user starts correcting thereby increasing/decreasing speed. 

 

Matt

Edited by mattjowil, 01 March 2021 - 06:16 PM.

[OzAndrewJ]

Gday Matt

 

If by drive train you mean the motor- and gearbox-unit: I use the "classic" hardware.

Yes, i meant the "mechanical drive train/gearing, as i have no idea what is used in a classic.

Basically, if all the gears in the geartrain dont fully repeat in one rev of the worm,

then making a PEC model will be affected by any errors in the geartrain.

 

You mentioned time based calculation but I am not sure if that was related to PEC training.

....

I think it makes sense to base the binning of PEC training corrections on the encoder pulses.

Yes. I only meant use the time delta for training, but the master bin definition is still the encoder count.

ie The first thing to do is define how many encoder transitions make up one rev of the worm.

Decide how many bins you want to break that into for the purposes of PEC.

Work out the exact bin time for a perfect mount tracking at sidereal

When you train, you use the bincount to define a bin and use the  time taken / perfect time

to come up with a speed percentage.

On playback, you still use the bin count to define the bins and then change speeds accordingly.

 

It seems to me that a time based binning must rely on a constant worm period

As per above, we never use time for actual playback or bin definition.

We just need to know how long the bin took "when being trained"

so we can work out a speed factor.

ie once the PEC train is done, we never use "time" again, only bin position.

 

Andrew Johansen Melbourne Australia

[rferrante]

I'm curious about the following:

 

When the user enters a correction, it is after the error has accumulated enough to be noticed in the eyepiece. It may have accumulated in the last seconds, or slowly over 10-20 seconds, but finally it is noticeable against the reticle and the correction entered. Maybe it would be better to spread out the corrected counts over the last few bins rather than put it all in the bin where the correction happened? You might be able to do something like measure the total time of the correction input, that would be the consecutive bins with more/less counts than ideal. For longer corrections, spread them out over more previous bins, and for shorter corrections spread them across fewer recent bins.

 

You would never know exactly where the error accumulated of course, but you at least know it had accumulated before the user noticed it and corrected for it, so putting your correction earlier than that would at least be an improvement over simply replaying the corrections when they happened.

[OzAndrewJ]

Gday Rob

Most people just autoguide and it picks up errors very quickly.

It also averages out the playback, so no matter where in the bin the error happened

it will get smoothed out on playback.

As to slight delays, yep, but thats where apps like PEMPro come into play as they

measure the unguided PE, make a model and then play it back before it happens :-)

 

Andrew Johansen Melbourne Australia

[mattjowil]

Hi everyone,

since my last post, I have been quite busy moving away from the arduino mcu and replaced it with a custom designed PCB holding a Teensy 4.1.

This step became necessary since I noticed that the 8bit 16MHz MCU was beginning to miss encoder pulses

as more computations involving floats and 32bit ints came into play.

 

Maybe it was caused by my inefficient programming skills but having an ARM Cortex-M7 opens up a range of new possibilities.

The most important features are probably the hardware Quad encoder and the FPU, aside from the insane speed (600 MHz) and the fact that it is a 32bit architecture.

I was also getting tired of all the loose cables running to the arduino pin headers - another reason to design a PCB from scratch. Now I can use the original connectors.

 

At the bottom is a picture of the board. It fits nicely underneath the powerpanel.

 

Currently I am implementing the Meade protocol and the functions that are invoked by the different commands.

I just finished the goto-functionality, which works quite nicely together with Stellarium using the Meade Generic Ascom driver.

 

A question arose: How is the periodic error accounted for during a goto-operation? Does this even matter? I assume that pointing accuracy will be affected by the PE.

Does anyone know if and how Meade takes care of this?

I guess the telescope model doesn't really matter for now since I can basically implement features that the LX200 classic didn't have provided these don't rely on sensors that the old hardware doesn't have.

 

As always, thank you for your help.

 

[OzAndrewJ]

Gday Matt

How is the periodic error accounted for during a goto-operation?

I dont know for the classic, but in the LX200GPS, above a set speed, PEC is ignored.

Once the goto finishes, the new PEC bin is calculated from scratch and the speed factor is modified accordingly.

 

I assume that pointing accuracy will be affected by the PE.

In the LX200GPSs, they do try to build the PEC model back into the "theoretical" encoder offset

but not for the 497/Audiostars

 

Andrew Johansen Melbourne Australia