AstroEQ and the EQ3-2 - early testing results

[Avocette]

I have started this as a new topic to avoid cluttering up or diverting the other very long AstroEQ thread on this part of SGL.

I am motorising an SW EQ3-2, intending in a later step to upgrade to direct drive for the RA axis and belt drive for the DEC axis. As a first step however I have obtained some second hand SW motors from an EQ3-2 kit from which the hand controller no longer operates and am driving these from the AstroEQ interface. I have installed Cartes du Ciel and EQASCOM on my laptop (Thinkpad Core 2 Duo 2.5GHz running WIndows 7 home premium 32 bit) and I configured my AstroEQ for the appropriate EQ3-2 motor reduction gear and wormgear ratios.

I place the scope in the 'Home position' pointing at the North Celestial Pole with the counterweights vertically below, connect CdC via EQASCOM to the AstroEQ and set the scope the task of slewing to Mars. Sure enough the mount motors turn, the DEC adjustment is made most speedily and then the RA locates the scope and continues to track the object. In the (inevitably) cloudy conditions I use a compass and Wixey to confirm that the scope is pointing in the correct ALT and AZ directions.

After an hour of continuous running the motors are quite warm (not exactly hot) to the touch and the scope seems to be correctly tracking the object from measurements of the new ALT and AZ angles.

Now I stop the motion and instruct the EQMOD controller to 'Park at Home Position'. After some time the scope is pointing at the NCP but the counterweights are at some arbitrary angle away from vertical.

Is this what I should expect or should the scope return literally to exactly the Home position it started from?

If so, would anyone have any suggestions for a step by step test procedure? I realize that there are many software, firmware and hardware components in the chain here, and getting the mount to move and track precisely may require some patient tweaking!

[RichM63]

See if this helps.

Before connecting to CDC/EQMOD physically set your scope to the home position as above.

Then when you connect to EQMOD BEFORE unparking click the button to clear stored align points etc in the full EQMOD control panel.

Now when you unpark and goto objects via cdc, and subsequently go for a park to home, hopefully the rig will go back from whence it came.

Do the usual, disconnect scope, exit cdc for a correct shut down.

I also have this problem sometimes, there must be a reason, but I can't find it.

My weights can sometimes be anywhere from 7o'clock to 9 o'clock on a park to home. ???

hth,

Rich

[Avocette]

Hi Rich,

Thanks for getting this thread started! Do you get the same 'random' 7 o'clock to 9 o'clock effect with both your EQ3-2 and NEQ-5?

[RichM63]

Yes, it would seem that it has nothing to do with the mount, which is just a lump of moving metal.

The moving telescope icon in cdc tracks across the sky, lands on Polaris/home,where it then remains, but the RA/weights continue for a while before stopping high, and then announcing PARKED, showing 06.00 and 90.00 in the circle displays.

Clearly there is a glitch in the control side of the system, but I'm stumped in trying to find it.

A problem with PARKED high is that this then becomes the start point for a further slew from home thus throwing everything out.

Hopefully one of the guys, Chris/EQMOD, Tom/AstroEQ, QM, or Oily will be able to chime in.

Meanwhile, I'm going to try HNSKY to try to rule out cdc.

Frustrated,

Rich

[Avocette]

Hopefully one of the guys, Chris/EQMOD, Tom/AstroEQ, QM, or Oily will be able to chime in.

Yes - that would be great. Like you I was trying to eliminate CdC but found that the telescope options in the Stellarium plug-in are limited. I'll look up HNSKY.

[Oily]

Not using EQMOD any more but I'll try and help if I can.I used this video to help me setup a 'park' position

https://www.youtube.com/watch?v=hvOFj63rvLo&list=PLBB117AE85EB6BF04

[Quatermass]

Put the mount into its homeposition first then reset the park position counters. Also use astro tortilla as this really helps get your mount bang on your target. Lots of info on my blog as I was doing all this.

Sent from my Nexus 7 using Tapatalk

[Quatermass]

Would not bother with stellarium stick with CDC its much better suited I feel.

Sent from my Nexus 7 using Tapatalk

[Avocette]

Put the mount into its homeposition first then reset the park position counters.

Sent from my Nexus 7 using Tapatalk

Just trying to figure out how to do this. The EQMOD ASCOM assumes the default Park position is with the scope pointing towards NCP and weights vertically below. So surely provided I start with the scope in this position, when we request 'PARK to Home Position' it should end up in an identical position and not with the counter weights at some arbitrary angle away from vertical?

[RichM63]

You would think so, I am just as frustrated as you, but I think that we both must be doing something wrong.

Yes I have put the mount into home and reset, even created a custom park position 06.00/90.00 and used this, but still get random parking positions.

OK, so, if the scope starts from position X (home/Polaris) then moves to position Y (M52), then from M52 all the way over to position Z (M37) then I issue a Park to Home command why does the scope/mount not return to the exact physical position from where it started? 

Is EQMOD not 'remembering' the total degrees previously moved, but is now slewing back to home from the calculation of M37 to Polaris, if this is the case then I could forsee the potential cause of the problem in a less than perfect Polar Alignment.

IE, the scope will move until the number of degrees are 'used up' from the calculation of 'last object to home'. in this instance M37 to Polaris. Where Polaris is not exactly physically perfectly aligned.

However when the telescope tracker in CdC lands squarely on Polaris, why does the Slew not stop with a PARKED indicator flashing, and possibly a Warning message. ((Parking Incomplete))  (I do fully understand the difficulties of linking different softwares).

It would be great if Chris could confirm this method because all frustration would be explained, and I would then know that it is my fault.

Rich

[Quatermass]

I think Chris needs to answer this one for you :-)

Sent from my Nexus 7 using Tapatalk

[Avocette]

As I wrote at the top - this is potentially an error in software, firmware, hardware and, I guess, possibly an interaction between them.

There's quite a lot to get working in this system, so mount movement of any kind seemed initially like success, but of course it is the precision of this movement which is critical.

My personal hunch at the moment is that my AstroEQ is not always precisely controlling my motors since I sometimes hear a high pitched whine coming from one but there is no movement of the mount. I can imagine that this is due to short pulses of power which the motor cannot respond to fast enough but which the position memory includes in its count. Just a guess......

By the way, I think there's a small error in the gear ratios given on the AstroEQ website for the SW EQ3-2 mount motors. The DEC motor drive has a 120:1 reduction gearbox but this is followed by a 51:34 meshed gear set (i.e. 3:2) so the effective ratio is 80:1 overall (given on the website as 79.2:1).

[chrisshillito]

OK, so, if the scope starts from position X (home/Polaris) then moves to position Y (M52), then from M52 all the way over to position Z (M37) then I issue a Park to Home command why does the scope/mount not return to the exact physical position from where it started? 

Is EQMOD not 'remembering' the total degrees previously moved, but is now slewing back to home from the calculation of M37 to Polaris, if this is the case then I could forsee the potential cause of the problem in a less than perfect Polar Alignment.

IE, the scope will move until the number of degrees are 'used up' from the calculation of 'last object to home'. in this instance M37 to Polaris. Where Polaris is not exactly physically perfectly aligned.

However when the telescope tracker in CdC lands squarely on Polaris, why does the Slew not stop with a PARKED indicator flashing, and possibly a Warning message. ((Parking Incomplete))  (I do fully understand the difficulties of linking different softwares).

When it comes to parking to home EQMOD doesn't really have to remember anything. When the mount is powered up it is assumed to be in the home position and its software encoders (stepper positions) are automatically reset to '0' .  A park to home simple consists of telling the mount to go back to '0' - this is always the same irrespective of where the mount is actually pointing. If you powered up with the mount not in the true home position then a park to home will return the mount to that position instead. Moving the mount at any point with the clutches disengaged will naturally change this (as EQMOD as no means of detecting that this has occurred).

Not quite sure what Polaris has to do with any of this. The home position has is not pointing at Polaris - it is pointing at the NCP. You cannot have a park position associated with a star - home positions are fixed orientations of the mount RA and DEC axis - stars move and require a variable position of RA axis for the mount to point at them.

So a park ho home should always cause the mount to move back to its power up stating position. If it doesn't then either there is something wrong in the AstroEQ setup with regard to the number of steps for each axis rotation or your clutch has slipped.

Chris.

[RichM63]

Many thanks Chris, therefore the mount should always return to its power up start position no matter what it was, providing that the clutches have not been disengaged at any time in the process.

I don't think that both of my mounts have slipping clutches and I used the following values in setting up. Reconfigure depending on mount used but 90% of the time EQ5

EQ3-2

The following are ratios for an EQ3-2 or CG4 mount fitted with the 'Dual Axis Kit' motors.

  Right Ascension Declination Motor Step Angle 7.5 degrees 7.5 degrees Motor Gear Ratio 120:1 79.2:1 Worm Gear Ratio 130:1 65:1 Microstepping Disabled

Top

EQ5

The following are ratios for an EQ5 or CG5 mount fitted with the 'Dual Axis Kit' motors.

  Right Ascension Declination Motor Step Angle 7.5 degrees 7.5 degrees Motor Gear Ratio 120:1 120:1 Worm Gear Ratio 144:1 144:1 Microstepping Disabled

When it happens again, I'll punch up the ASCOM trace log to see if the condition is noted.

(my error, on Polaris, I know it should have read NCP, excuse, no edit feature and the telescope tracker in CdC is over Polaris more or less).

Cheers,

Rich

[chrisshillito]

Many thanks Chris, therefore the mount should always return to its power up start position no matter what it was, providing that the clutches have not been disengaged at any time in the process.

I don't think that both of my mounts have slipping clutches and I used the following values in setting up. Reconfigure depending on mount used but 90% of the time EQ5

EQ3-2

The following are ratios for an EQ3-2 or CG4 mount fitted with the 'Dual Axis Kit' motors.

  Right Ascension Declination Motor Step Angle 7.5 degrees 7.5 degrees Motor Gear Ratio 120:1 79.2:1 Worm Gear Ratio 130:1 65:1 Microstepping Disabled

Top

EQ5

The following are ratios for an EQ5 or CG5 mount fitted with the 'Dual Axis Kit' motors.

  Right Ascension Declination Motor Step Angle 7.5 degrees 7.5 degrees Motor Gear Ratio 120:1 120:1 Worm Gear Ratio 144:1 144:1 Microstepping Disabled

When it happens again, I'll punch up the ASCOM trace log to see if the condition is noted.

(my error, on Polaris, I know it should have read NCP, excuse, no edit feature and the telescope tracker in CdC is over Polaris more or less).

Cheers,

Rich

Hi Rich,

i doubt the ASCOM trace log is going to show you anything. Whatever is going wrong is happening at the AstroEQ / motor / axis level. A park to home from the EQMOD user interface are nothing to do with ASCOM and simply results in AstroEQ being directly  instructed to move the motors to a step count of  '0'. It is AstroEQ that maintains stepper position and that implements the necessary movement.

Gotos are a little different as EQMOD must read data from AstroEQ that tells it how many motor steps constitute a full rotation of the axis. EQMOD can then read where AstroEQ things the motors currently are - calculate where they need to be and send an appropriate movement command to AstroEQ. If the data AstroEQ gives EQMOD is wrong then the calculated amount of movement will be wrong. So if your gotos are accurate you can be sure AstroEQ is reporting the correct data to EQMOD. If your park isn't accurate then it would seem that somehow AstroEQs notion of there the mount currently is has slipped with respect to where it actually is. This is a problem with these open loop systems and AstroEQ has know way to know if a step to the stepper motor actually delivers a steps worth of angular movement at the axis itself -  it can only assume it does.

Am I correct is that on returning to home it is the RA axis only that is out of position?  This would be consistent with your hunch that when tracking the mount isn't always moving correctly - but then again in your initial post you implied that object tracking was maintained (but you really need to check this visually)

Chris.

[Avocette]

Hi Chris and thanks for your clarifications. Rich has a lot more experience of the problem than me, and so far I haven't had a chance to test the tracking visually. I guess we'd best leave Tom (TCWORLD) to complete his final exams and then see if he has any suggestions for corrections/adjustments or tests we can carry out to isolate the problem issues.

[RichM63]

So if your gotos are accurate you can be sure AstroEQ is reporting the correct data to EQMOD. If your park isn't accurate then it would seem that somehow AstroEQs notion of there the mount currently is has slipped with respect to where it actually is. This is a problem with these open loop systems and AstroEQ has know way to know if a step to the stepper motor actually delivers a steps worth of angular movement at the axis itself - it can only assume it does.

 The above paragraph accurately describes the behaviour.

Hence my reference to 'remembering'.

Where multiple gotos have been issued between various objects without parking between them, the individual gotos appear to be OK, but when a subsequent final shutdown command of Park to Home is issued this is then where I am experiencing random parking positions in RA with the weights anywhere between 7o'clock and 9o'clock.

I've not noticed the problem with single gotos followed by a PTH command.

My work around, is simply to manually reposition the mount after powering down and start from 0 next time out.

It is not something to lose sleep over in my case as I am not running an obsy. EQMOD and AstroEQ are great assets, and I guess that this is not a widespread problem, otherwise the boards would be full of similar posts.

I'm more intrigued as to why this happens rather than anything else.

Thanks again,

Richard

[TCWORLD]

Does it only happen after one Go-To movement, or after many? I'm wondering if the internal counters are overflowing, but that shouldn't happen unless you enough goto movements that the mount has moved several sidereal days in one direction without moving back the other way. Unless it is something to do with the large gear ratios making that distance shorter than I thought.

Another week and an half before all of my deadlines are out of the way, so after that I'll have a play with my mount and test board and see if I can replicate the issue.

[TCWORLD]

(I've just done a quick calculation and for the EQ5 with dual axis, you would have to move it in one direction for over 1800 degrees before the counters overflow, its an even longer distance for an EQ3-2)

[RichM63]

Tom, don't sweat it, at the moment I can't really get outside, it will be August before it goes dark again.

It happens after, A to B to C to D.... without a PTH in between.

Best wishes for the exams.

Rich

[Avocette]

Another week and an half before all of my deadlines are out of the way, so after that I'll have a play with my mount and test board and see if I can replicate the issue.

Good luck with your exams!

I'm back to using my (manual) Dob in the brief cloud-free moments, and it won't be until the end of the month before I can try out my EQ mount and motors again, so no rush from my side either.

[Avocette]

Hi Tom,

Hope things went well at Uni. I note that you are back in action building the next batch of AstroEQs and preparing a software update, so perhaps you could think about our problem again now and see if we can find the solution?

As promised I'm back into full Cartes du Ciel - EQASCOM - AstroEQ - SW EQ3-2 motor drives test mode again.

Test 1 - solar tracking. I set up the scope and mount on a south facing terrace, and used the DEC and RA clutches to point the scope into the Park position (counterwieghts down - scope looking in the direction of the NCP). I then clicked on the Sun as the target in CdC and clicked on the button to set the mount Slewing. I had set the slew rate to level 3 which is 64x siderial rate. After slewing it was pretty close to the correct orientation, judging from the size of the shadow cast by the Sun. I set EQMOD to 'Solar' tracking and left the whole system for an hour. At the end of this time judging from the size of the Sun's shadow again, the tracking looked pretty accurate. I then asked the mount to 'Return to Park position'. The DEC motor seemed to return to its origin (or as close as my judgement suggested), but the counterweights reached only about 7 o'clock as if the RA motor stopped short of its correct final rest position.

Test 2 - locating Jupiter then the Sun. I reset the mount physically to the Park position, and took advantage of the sunshine to set the mount precisely N/S when the Sun was AZ 180 degrees. I then clicked on Jupiter in CdC and asked the mount to slew. It did so and seemed to find approximately the correct pointing direction as measured by a compass and Wixey. I then clicked on the Sun, and asked the mount to slew. The DEC axis motor did so but the RA motor didn't move at all although I could hear an audio 'fizz' coming from it. When CdC was indicating correct alignment on the Sun, the noise from the RA motor changed to the more normal tracking sound (occasional 'clicks'). I swung the scope on the RA axis using the clutch until the Sun's shadow was minimised again (suggesting that the DEC axis was probably in the correct position), relocked the clutch and the mount seems to be tracking again.

I have heard a 'fizz' from the stationary DEC motor at times, but this has been when I wasn't expecting it to rotate the mount, and I haven't recognised any particular pattern to whether it occurs or not.

Initial thoughts from my side are that AstroEQ is not fully driving the motor(s) steps so that the physical position reached is a little short of what the software count believes.

I'm guessing that this may be due to a mismatch between the stepper motor driver and the SW motor. But there may also be some occasions when the stepper motor driver is not cleanly switching off, hence the 'fizz'. By the way the motors are pretty warm (in the sunshine) but not excessively so.

[TCWORLD]

You may want to try a slower speed - the skywatcher motors are only really good for up to ~50x - I now on the ones I used to have they could get to 52 before stalling, so it is possible that they are skipping steps (the problem with an open loop system).

Simple test, set the mount moving at 64x and see if it stalls if apply a small amount of resistance to movement.

My last exam is on Thursday next week, so almost free from Uni. I'll have a detailed look at the problem then. In the mean time, could you try this:

http://www.astroeq.co.uk/AstroEQ7-ConfigUtility.zip

Its the beta version of the latest release I am working on. It would be good to know if you have the same problem with that version.

[Avocette]

Thanks Tom. I'll try your test and also slewing at a slower speed.

[Avocette]

Eureka! Looks like you've highlighted the problem issue here. It seems to be the slewing speed that the SW motors can provide. Now I've set the GoTo rates in the AstroEQ configuration programmes (version 6 or 7 beta) to 48x siderial the scope/mount has (at least once) returned correctly to the Home Park position! There are a couple of things that weren't self evident when I was first setting up my system.

Unfortunately I can't check out what happened the first time that I ran AstroEQ config v6 a few weeks ago, and what happened today with v7 but I have a feeling the GoTo rates set by default today may have been 364 for the RA and 445 for the DEC axis. After reading your post I ran v7 a couple of times. First time with default GoTo rates the motors just buzzed and didn't move. The second time with values of 48 set, then the drives worked and the Park position was correct. I ran AstroEQ config v7 again and noticed that the default values of the GoTo rates has changed to 46 for the RA and 49 for the DEC. Is this to be expected?