56 replies to this topic

[Centaurus Curiosus]

This seems to be a complicated issue. For me, it also occurs at high speeds when I move several short steps in quick succession. But the problem is generally difficult to reproduce. Last night it did not occur at all, the night before constantly.

 

I have the impression that it is more a software problem than a mechanical defect. The clunk noise is clearly mechanical, but I think it's probably not the cause but just one of the effects, but of course I don't really know.

 

Richard, I'm glad you brought this up. Even if we don't find a solution here, it's always good to know that I'm not the only one with this problem 

[Rac19]

Richard, I'm glad you brought this up. Even if we don't find a solution here, it's always good to know that I'm not the only one with this problem 

That's the way I see it too. It seems that it's mainly a question of learning to live with it, and hoping that one day a firmware fix (even an unannounced fix) will occur one day.

[Rac19]

An update on Firecapture. AutoAlign is a better choice than Autoguiding in Firecapture because it moves the ROI frame and doesn't slew the 'scope. Generally, it is necessary to manually re-centre the target between captures, but AutoAlign does a good job of stabilising the image during a capture. 

Edited by Rac19, 09 August 2021 - 04:23 PM.

[mlord]

Recently I've been experimenting with the backlash settings, but can't confirm if they help.

Non-zero settings for backlash can actually cause erratic slewing behaviour at the lowest motor speeds, especially for short duration movements like fine-centring of a star in the eyepiece.

 

So for those experiencing erratic slewing, first try setting both backlash settings to zero, and see if that takes care of the issue or not.  If so, you then know what's happening, and can better decide what backlash settings are most appropriate for the situation.

[Rac19]

Non-zero settings for backlash can actually cause erratic slewing behaviour at the lowest motor speeds, especially for short duration movements like fine-centring of a star in the eyepiece.

 

So for those experiencing erratic slewing, first try setting both backlash settings to zero, and see if that takes care of the issue or not.  If so, you then know what's happening, and can better decide what backlash settings are most appropriate for the situation.

Thanks mlord, I have backlash set to zero so that doesn't seem to be the the the cause.

 

I seriously wonder whether or not, with small movements at very slow speed, the software (or firmware) senses either position or speed overshoot (in feedback from the encoders) and overreacts.

 

Anyway, from my experience last night, AuotAlign, instead of AutoGuiding, is a good work-around for Firecapture. It possibly works better in fact. For manual slewing, we possibly just need to learn how to live wth it.

[Notdarkenough]

I check mine monthly. I stopped using CPWI and it has yet to reoccur. 

Update: I was messing around last night and decided to recalibrate StarSense as the initial alignment was off. I chose Arcturus; an easy target with few equally-bright stars in the field. Upon starting the StarSense Calibration I used a higher motor speed for course centering and all was well. I moved through the my eps in increasing magnification just fine. At the fine centering culminating Up-and-Right move, at 6mm and Motor speed 2, my first slew command was to the right, and the anomaly resurfaced. I don't think "clunk" or "thump" are exactly what I heard in the past, or again last night. My best description of the anomaly is an electric, binding, sound. The view shifts dramatically off field and that noise. As I lost the target, I had to go back up in ep to relocate the star. I finally finished the Calibration with zero problems, but I didn't use speed 2. After the StarSense realignment, I selected Arcturus again for GoTo to check my work. I tried speed 2 again with no problems. However, at speed 4 the anomaly reoccured, but with a wrinkle; as the anomaly occurred I held down the slew button. The target that had shifted out of the field snapped back into the field as long as the slew button was held down. When the slew was released, the target snapped back to the out-of-field location. The same electric-binding sound occurred, but it was in 2 phases that corresponded to the slew button hold-and-release operation mentioned. 

 

Those were the only occurrences all session, which spanned 3-4 hrs. Seeing was below average (according to Astrospheric and verified by observation limitations) but I could get some productive minutes with Jupiter and Saturn. I looked for RS Ophiuchi with no success (I used the 17h50m13.2sec, -06°42'28" coordinates from space.com, I think). I also got some dim views of NGCs 6402, 6517 and M31 - all with no anomaly at all.

 

For gear, I have what you can see. I have no wedge, no cameras of any kind. I use a 2" Maxbright ClickLock diagonal and have for 6 months. When the anomaly occurred I was using either the Original Nagler 9mm or the Planetary Zoom 3-6mm, so weight isn't an issue. I was setup on flat grass with a level tripod. I was exclusively using the StarSense HC the entire night, so my earlier theory about a CPWI issue was debunked. Incidentally, because of the anomaly, I had reset all alignment data in the HC, and forgot to enable Tracking when the first anomaly occurred. I enabled the sidereal tracking for the next attempt when the hold-and-release operation and anomaly occurred, so that isn't a concern either.

 

Anybody solve this yet?

Mike

[Rac19]

I have had this problem for at least a couple of years and have inconclusive correspondence with Celestron, in the CPWI/Team Celestron forum.

 

My theory (guess), at the moment, is that the motor control board firmware can overreact (at slower speeds) to what it sees as either a position or speed overshoot. If so, a mount firmware update would be required to fix it.

 

My reasons for thinking this are purely circumstantial in that the problem doesn't seem to be at a "higher" level such as the HC or CPWI.

[Notdarkenough]

As mentioned, it happened with the HC last night, and my first experience with it was with CPWI. I, too, think it is software related. That is just my feeling based on nothing! I have never had it happen via SkySafari, yet! The Tech Support answer I got was to record it on video so they can figure it out, as if I am recoding me using the scope, at all, let alone all the time in the off chance IT happens! Thankfully it isn't more frequent! 

 

Mike

[Notdarkenough]

Update: My Evolution, which has been making this sound for 10 months, is going to Celestron for warranty repair. I finally got the noise on video, so hopefully it can be fixed. I'll update this thread again when I get it back.

Mike

[audioengr]

Open it up and have a look at the gears.  Sometimes they work loose from the factory.

He's right here.  I have Evo as well.  I tightened the gear-mesh on the ALT gear and worm and also tightened the nut behind the friction plate for the clutch on the ALT and it never does this now.  When I manually use the HC for fine tuning or using PHD2 on-screen keypad for fine-tuning it is solid.

[Rac19]

My problem happened again a few nights ago and I think that the coordinates that I saw before and after the event might be significant, although I am not sure in what way.

 

I started from the wedge index position which for me is Az 0 degrees (due North) and Alt 52.25 degrees (the compliment of my latitude in Southern Hemisphere). I then did a StarSense manual align but skipped finding any stars. I had planned to start from this approximate alignment and refine it with Sharpcap plate solving, something that has worked well in the past.

 

Before doing that, I slewed manually to the Zenity (approximately), using the gamepad control through CPWI, so that it would be easier to fit Hyperstar. The next time that I looked at CPWI was showing Az 180 degrees (due South) and Alt -52.25 degrees.

 

It's as though the manual slew to the Zenith caused the alignment model to flip or reset to a default value. I used to gamepad so that I wouldn't be bypassing CPWI. thereby confusing it.

 

EDIT: Attached is an image of CPWI. It was a little after the event so I assume that some tracking had occurred, moving off the précis coordinates described above. It would seem though that the change occurred at the beginning of the manual slew and that the CPWI coordinates became frozen at that time because the OTA was pointing approximately at the Zenith when the screenshot was taken.

 

Attached Thumbnails

• 
• 

Edited by Rac19, 26 December 2021 - 04:59 AM.

[kannassee]

Update: My Evolution, which has been making this sound for 10 months, is going to Celestron for warranty repair. I finally got the noise on video, so hopefully it can be fixed. I'll update this thread again when I get it back.

Mike

where they able to find out why is this happening? I have the same problem. I sent it to Celestron, they changed the a control board and the next day it was doing the same thing again.....

But the weird thing is that not all mounts do it, just certain ones.

[Wdh]

I'm glad to hear it's not just me! My Evo is back at Celestron for a second attempt at repair, and they say they can not reproduce the problem. I already paid for a new motor control board, and it came back worse!!!

 

It happens from both hand controllers, CPWI, and ASIAIR!

 

I'm at my wit's end.

[Notdarkenough]

where they able to find out why is this happening? I have the same problem. I sent it to Celestron, they changed the a control board and the next day it was doing the same thing again.....

But the weird thing is that not all mounts do it, just certain ones.

My Evo was fixed during that first repair. I asked what they found, and they said it was simply regressed and checked out. I haven't had the glitch since. However, to be honest, I picked up a CEM70 for my nightly sessions and only use the Evo when I do outreach and star parties. In short, they fixed it, but I am not sure how long that fix holds. Sorry there is nothing more definitive.

[kannassee]

Well, "if" I am really lucky and I find out why my unit is doing it, I will post it here.

 

There is this loooong thread (8 pages) where a lot of possible causes are considered....

 

https://www.cloudyni...on-scope/page-5

 

....It seems it may have to do with:

 

1-the unit's production date,

 

2-if they used in particular "spring loaded worm blocks" ????.....

 

3-and also in the Software version, the newer versions being more prone to exhibit this behavior......

 

4- and other stuff too that wont apply in my case like balancing the OTA, adjusting the backslash limits, letting the mount to rotate in order to lubricate the system, etc etc etc..(I have tried all those solutions before to no avail)

 

I have used a friend's Evo before extensively and no matter what backslash I used it never did this.....

 

In my case, well, I am waiting to see what Celestron will say.

 

I suspect that it has to do in my case with the software versions and dates and updates.

 

My unit did it from the beginning and then I updated the drivers using the Nextstar control that came with it, and the problem seemed to disappear.....!!!

 

Since I also had a Starsense camera, I then downloaded the latest drivers that had to do with the Starsense hand control, much recent drivers and.....and I got the problem again.....I never installed the older drivers back since I "assumed" that the newer drivers should be the better ones!!!!

 

I will try now to go back somehow to the drivers that were downloaded with the older Nexstar hand control......

 

If I am lucky the problem will disappear again.!!! I will try that tonight.

 

I really wish that I wont have to send the unit back again to Celestron since it takes like 3 weeks to get it back.....

 

I suggested them that maybe they should send me a new mount,

 

But if I can fix mine with the older software, I would be fine with that.!!!!

Edited by kannassee, 21 June 2024 - 02:19 PM.

[Wdh]

Well, "if" I am really lucky and I find out why my unit is doing it, I will post it here.

 

There is this loooong thread (8 pages) where a lot of possible causes are considered....

 

https://www.cloudyni...on-scope/page-5

 

....It seems it may have to do with:

 

1-the unit's production date,

 

2-if they used in particular "spring loaded worm blocks" ????.....

 

3-and also in the Software version, the newer versions being more prone to exhibit this behavior......

 

4- and other stuff too that wont apply in my case like balancing the OTA, adjusting the backslash limits, letting the mount to rotate in order to lubricate the system, etc etc etc..(I have tried all those solutions before to no avail)

 

I have used a friend's Evo before extensively and no matter what backslash I used it never did this.....

 

In my case, well, I am waiting to see what Celestron will say.

 

I suspect that it has to do in my case with the software versions and dates and updates.

 

My unit did it from the beginning and then I updated the drivers using the Nextstar control that came with it, and the problem seemed to disappear.....!!!

 

Since I also had a Starsense camera, I then downloaded the latest drivers that had to do with the Starsense hand control, much recent drivers and.....and I got the problem again.....I never installed the older drivers back since I "assumed" that the newer drivers should be the better ones!!!!

 

I will try now to go back somehow to the drivers that were downloaded with the older Nexstar hand control......

 

If I am lucky the problem will disappear again.!!! I will try that tonight.

 

I really wish that I wont have to send the unit back again to Celestron since it takes like 3 weeks to get it back.....

 

I suggested them that maybe they should send me a new mount,

 

But if I can fix mine with the older software, I would be fine with that.!!!!

I just spoke to Celestron and asked for a new mount too! We'll see what they say. I've wasted months on this- I use the C8 Evo for planetary AP, and small tweaks in skew are critical. Every time I speak with them it's as if they've never heard of the issue.

 

It happens with my StarSense and NexStar+ hand controllers, CPWI, and ASIAIR. I'm really fed up.

[Rac19]

As the OP I thought that I would provide an update. Basically no change.

 

As I attempt to zero in on a target, at very slow speed, the OTA will "snap back" after performing a micro slew, making a very audible clunk. It simply refuses to move onto the target. The only way out seems to be to slew off the target at a much higher speed, very frustrating.

 

I wonder if it could be a software/firmware problem possibly being over sensitive to position or speed overrun at very low speeds causing an over-correction. I say this even though the problem sounds very mechanical.

 

I use CPWI and have my mount on a wedge, by the way.

[mlord]

If the mount backlash settings are all zero, then the only possibility is that CPWI is issuing commands to produce the effect.  Which you can verify by tracing the messaging using your HBG3.   No need for guessing.

Edited by mlord, 23 June 2024 - 04:59 PM.

[mlord]

If the mount backlash settings are all zero, then the only possibility is that CPWI is issuing commands to produce the effect.  Which you can verify by tracing the messaging using your HBG3.   No need for guessing.

And if the traces do show CPWI causing the jerky movement, then it may be possible for me to add a workaround for that to the HBG3 firmware..

[Rac19]

And if the traces do show CPWI causing the jerky movement, then it may be possible for me to add a workaround for that to the HBG3 firmware..

Thanks Mark,

 

I am not using HGB3 at the moment because I somehow managed to break the Micro USB port. I have tried using both direct WiFi and Bluetooth through HGB3 but neither seems to be reliable. I can't seem to use wireless for direct control n my backyard. I gave up on Evolution WiFi years ago. The most reliable connection method that I have at the moment is the USB Bridge built into the Celestron Focuser.

 

I will see if I can get the Micro USB port replaced at a reasonable price but it's hard to find anyone to do it these days.

 

In the meantime, I could turn CPWI  detailed logging on and reproduce the problem. Naturally, the problem is difficult to reproduce, as others have mentioned. 

[mlord]

Remind me again, where in Australia are you located?

[mlord]

I am not using HGB3 at the moment because I somehow managed to break the Micro USB port.

That does not prevent doing most things with it, including tracing AUX bus messages.
 

[Rac19]

Remind me again, where in Australia are you located?

Sydney

[Rac19]

That does not prevent doing most things with it, including tracing AUX bus messages.
 

So I can plus it (HBG3) into an Aux port and access the via direct WiFi/Telnet, is that correct?

[mlord]

Yes, plug it into an AUX port, and connect it to the home WiFi.  If not already configured for such, use the SkyPortal app to configure the home WiFi SSID/passkey, or do it (easier) from a telnet session:

 

telnet 1.2.3.4 3000

set wlan.ssid HomeWiFiSSID

set wlan.passkey HomeWiFiPassword

save

exit

 

Then flip the HBG3 WiFi switch up away from the PCB to change to "Access Point" mode.  It will try to connect to the home WiFi with the parameters just set.

 

After that's all done, it becomes easier to use, as it will always be on the home network.   The OLED will show the IP address, eg 192.168.77.5 which you can then use for connecting again with telnet:

 

telnet 192.168.77.5 3000

ota_update

 

That will get the firmware on the device updated, which I very strongly recommend.

Afterwards, it will reboot, and you're now ready to trace bus activity:

 

telnet 192.168.77.5 3000

debug

v

 

It will now show all AUX bus activity.  So reproduce the problem and we'll see what's causing it.

 

Cheers

Edited by mlord, 25 June 2024 - 07:08 AM.