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

iOptron CEM120 EC2 - DEC instability

SCT mount
  • Please log in to reply
126 replies to this topic

#1 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 19 March 2019 - 11:23 PM

My first post on CN, so please forgive any formatting issues. I recently became the proud owner of an iOptron CEM120 EC2. Given the many positive comments and supporting quantitative data posted here at CN, and my desire to image planetary nebula in the highest resolution my seeing will permit, I decided to bite the bullet and go with the dual-encoder version. I purchased it from a well-known store in Europe, and after a short delay due to back-ordering it arrived here within a few days of receiving the shipping notice. On opening the shipping box I was surprised to see that the DEC axis was unlocked and the DEC worm in the engaged position. Here's an image of the opened box minutes after arrival:

 

 

shipping-box-20190310_120313-1000.jpg

 

With the mount still in the box I carefully felt the RA gear switch and axil lock (on the underside of the mount) and noticed that they too were set to axis unlocked, worm engaged. This was confirmed when I carefully removed the mount from the box. Perhaps I am mistaken but if my understanding is correct, the axes need to be locked and the worms free when moving and transporting the mount; the worms are prone to damage in the "worms locked, axes unlocked" state. I can imagine there may have been quite a bit of torque applied directly to the worms while carrying the mount to the box and placing it into the box, given its considerable weight and lack of carrying handles like the EQ8 has. I immediately emailed the store the above findings to "cover my behind". I had asked the store to check the mount prior to shipping, so I assume the store simply forgot to return the switches/locks to their correct "safe for transport" positions.

 

Time passes while I wait for a clear night to test the mount. What follows below are my observations over two days of testing. I am fairly new to astronomy and astrophotography so my inexperience may be leading me to the wrong conclusions, but I am concerned as to what I am seeing; being quite different to those experiences and data that other members have posted. I may simply have a software setting incorrect, or old firmware (my mount has version 180810).

 

  • My equipment is the CEM120 EC2 with a Celestron Edge HD 1100 + ZWO OAG + ASI 1600MM pro.
  • Using iOptron Commander V6.1 and PhD2 via USB to control the mount.
  • Guide speed 0.6x (also tried 0.5x)
  • No wind
  • Using an OAG
  • Cabling is tight, as is the optical train. Cable management is a dream on this mount.
  • The RA has a periodic "tick tick tick" during fast slews.

 

What I am seeing that I am a little concerned about is:

 

  1. a repetitive, predictable sawtooth guide trace in RA when RA guiding is enabled (see below). Even low values of RA aggression like 10% cause this. These periodic oscillations can be as much as 4 arc-sec peak to peak, and certainly don't help in minimising my RMS guiding error. However I think I remember seeing others with this mount post similar concerns so perhaps my mount is "normal" in this respect? In any case I hope there is a method or software setting to reduce them.
  2. frequent sudden excursions in DEC, but only when guiding (see below). These ruin any chance of imaging at high resolution and result in the loss of many subs.

I tested the mount using a second completely independent scope and imaging train (TS Photoline 130 F7 refractor) to confirm that the source of the problem is probably either the mount hardware or mount/software/firmware bugs. The DEC instability does not occur as often using the refractor, perhaps because it is lighter and/or has a much shorter focal length (720mm vs 2800mm). Both scopes were 3D balanced on the mount.

 

Perhaps I don't understand how the DEC encoder is supposed to work, but it would appear to me it is not attempting to correct these excursions; it appears to be PhD doing all the heavy-lifting. I guess it is possible that the DEC encoder is causing the excursions?

 

Here are my settings in Commander:

 

Commander.gif

 

 

Example PhD2 guide logs can be download here if you wish to take a look:

 

https://www.ohmigall...3-17_232625.txt

 

https://www.ohmigall...3-17_232625.txt

 

So colleagues, what would be your best guess as to what is happening and why? Are there any further tests I should undertake to isolate the cause of these problems? Under EU law I believe I have 14 days from receipt to return the mount "no questions asked", but thanks to terrible weather 11 days have already passed, so I need to make a decision soon. If I do return it it will be for a replacement; I'm not giving up on this mount just yet. I have my fingers crossed that this is simply a software/firmware incompatibility/bug, not to mention operator error wink.gif

 

More to follow.

 

Ross

 



#2 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 19 March 2019 - 11:45 PM

Here are some comments regarding the above two logs:

 

PHD2_GuideLog_2019-03-17_232625.txt

 

Log section:

(2) Good calibration.

 

PHD2_GuideLog_2019-03-17_232625-2.gif

 

(6 to 13): DEC oscillations. They remind me of DEC backlash, but isn't the DEC encoder supposed to control that? I've tried adjusting the DEC gear mesh as per the iOptron manual, both tighter, and looser, with no obvious effect. Here is one of the more forgiving examples:

 

PHD2_GuideLog_2019-03-17_232625-9.gif

 

(14) Unguided in both RA and DEC. No instability in DEC. Sawtooth pattern in RA is obvious, despite no RA guiding. It is too deterministic to be due to seeing. Yes, poor PA.

 

PHD2_GuideLog_2019-03-17_232625-14.gif

 

 

 

PHD2_GuideLog_2019-03-19_160443.txt

 

Log sections:

 

(2) and (4): PhD calibration is a bit off tonight (DEC adjustment too tight/loose?)

 

PHD2_GuideLog_2019-03-19_160443-4.gif

 

 

(6) to (18): adjusting PA at meridian/CE
(7, 8, 9) noticeable RA sawtooth, Aggression = 0.500, Minimum move = 0.59

 

PHD2_GuideLog_2019-03-19_160443-7.gif

 

 

(15) unguided in RA and DEC. No more sawtooth pattern in RA, and no DEC instability:

 

PHD2_GuideLog_2019-03-19_160443-15.gif

 

(19 ->26): adjust PA toward East
(25) reduced RA aggression to 0.2 but still seeing sawtooth RA trace

 

PHD2_GuideLog_2019-03-19_160443-25.gif

 

 

(27 to 35): adjusting PA at meridian/CE

(36): finished PA. Still not good enough. Unguided for 27 mins with no sudden large DEC excursions/instability

 

(38): first attempt at guiding for the night (Whirlpool Galaxy).

 

X guide algorithm = Hysteresis, Hysteresis = 0.100, Aggression = 0.200, Minimum move = 0.880

Y guide algorithm = Resist Switch, Minimum move = 1.100 Aggression = 50% FastSwitch = enabled
Backlash comp = disabled, pulse = 20 ms
Calibration step = phdlab_placeholder, Max RA duration = 2500, Max DEC duration = 2500, DEC guide mode = Auto
RA Guide Speed = 9.0 a-s/s, Dec Guide Speed = 9.0 a-s/s, Cal Dec = 5.2, Last Cal Issue = None, Timestamp = 19/03/2019 6:52:25 PM
RA = 13.51 hr, Dec = 47.1 deg, Hour angle = -1.83 hr, Pier side = West, Rotator pos = N/A, Alt = 66.2 deg, Az = 51.2 deg

 

Extreme swings in DEC:

 

PHD2_GuideLog_2019-03-19_160443-38.gif

 

 

(39 to 43): further extreme and sudden swings in DEC.

(43): turned off DEC guiding.

 

Give up at 2am and go to bed.

 

Thanks in advance for any comments and sage advice you may have.

 



#3 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 20 March 2019 - 03:12 AM

Here's another interesting portion of log section 42 in PHD2_GuideLog_2019-03-19_160443.txt. I was experimenting with DEC aggression and set it to values of 1 to 10% (changed back to 50 when the image was captured) to see whether the DEC encoder would pull DEC back into line by itself. Lots of tiny DEC corrections by PhD, as to be expected. Each guide pulse is 3 seconds, and I count over 20 guide pulses during some of those wild excursions, so the DEC encoder had over a minute to decrease DEC error to zero. Yet it seems to be unresponsive. If I am not mistaken the encoder is supposed to work together *with* guiding, but one interpretation of this graph is that the encoder switches itself off when it sees guide pulses. Or it's trying to correct, but doesn't succeed for some reason (yet PhD succeeds eventually).

 

 

 

2019-03-19-%20CEM120EC2%20PhD2%20-2.png

 

 

I was also wondering whether the DEC encoder simply can't see these excursions for some reason. The excursions are obviously not due to seeing. I thought briefly that perhaps there was something moving inside the OTA that varied the optical path slightly (which would obviously not influence the DEC encoder count), but if that was the case we would see excursions in RA as well.

 

 



#4 BobT

BobT

    Vostok 1

  • -----
  • Posts: 116
  • Joined: 09 Feb 2012
  • Loc: Driftwood, TX

Posted 20 March 2019 - 05:40 AM

Ross,

 

What firmware versions are you using?  There has been a recent release that fixed the fixed the jumpiness in RA but I'm not sure if it did anything to DEC.  My CEM120 is the EC version so I can't comment on the DEC encoder operation.  I had the same intermittent spikes in RA but, with what little testing I've been able to do given the recent weather, they seem to have been eliminated.  If you haven't already done so, I'd update the firmware and retest.  You might contact iOptron support to see if the latest update did anything to change DEC behavior, they are very responsive here in the US.

 

I don't have a PHD graph since change the firmware but this is what it looks like in SkyGuide3.  The vertical scale is arcseconds of correction sent to the mount, horizontal is guider frame (which was set to 10 seconds) so it is about 20 minutes of data.  Seeing was terrible with lots of clouds.  We haven't had a decent night since late November :>(.

 

Guiding3_13_2019.PNG

 

Edited to remove wrong PHD chart 10:43 UTC.

 

Needed to add:  This was with a 10" RC, 2000 mm, OAG with Lodestar II.

 

The vendor did have the switches in the wrong position.  The iOptron packing is good but who knows what treatment it got in shipping.


Edited by BobT, 20 March 2019 - 06:02 AM.


#5 BobT

BobT

    Vostok 1

  • -----
  • Posts: 116
  • Joined: 09 Feb 2012
  • Loc: Driftwood, TX

Posted 20 March 2019 - 06:18 AM

Ross,

 

Here's the link to the firmware upgrade in case you don't have it:  https://www.ioptron....cles.asp?ID=316.



#6 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 22 March 2019 - 03:10 AM

Bob,

 

Thanks for your reply. It's always good to receive advice from more experienced members.

 

What firmware versions are you using?  There has been a recent release that fixed the fixed the jumpiness in RA but I'm not sure if it did anything to DEC.

 

 

My mount and HC had 180810 and 180206 firmware, respectively.

 

I'd update the firmware and retest.

 

 

Thanks for the link to the latest firmware beta. I was able to successfully update the mount and HC to the March 15th beta, and updated to Commander V6.2 as required for this beta, so now it is only a matter of waiting until the skies clear to see if any of the problems are resolved.

 

You might contact iOptron support to see if the latest update did anything to change DEC behavior, they are very responsive here in the US.

 

 

Yes I did email iOptron, and included a link to this thread (to save repeating everything I wrote here). I received a reply within about an hour, so I'm certainly impressed with iOptron's responsiveness. They did not comment on what might be the problem, but they did suggest I upgrade the HC and mount, and provided the same link to the beta firmware that you gave.

 

I think my next course of action will be:

  • Increase RA and DEC min-mo in PhD2 to more appropriate values; they're currently set far too low.
  • Take Ross's advice in another recent thread:
    • remove the OAG from the equation and guide via the imaging camera, making a new profile in PhD with settings for the imaging camera. I don't think the imaging and guiding equipment are a problem because I saw similar DEC instability using a completely different scope/OAG/guide camera/imaging camera, albeit less severe. But there is certainly no harm in double-checking previous observations.
    • run a USB2 cable from computer direct to mount, and separate USB3 cable from computer to imaging camera (no hubs).

I currently run a single USB3 cable from my computer to a powered hub at the mount.

From the hub I have USB2 to mount; USB2 to RA panel; USB3 to RA panel.

From the DEC panel I have USB3 to imaging camera; USB 2 to guide camera; USB2 to focuser.

From imaging camera, USB2 to filter wheel.

 

Running two cables direct to the mount and camera will minimise the number of cables, connectors, and USB hubs (internal and external) that are in the communications chain.

 

  • Try a different power supply. The 12V 10 amp PS I currently use should be more than sufficient but trying another PS will eliminate one more potential source of problems..

 

I shall report back later. 

 

Cheers.

 



#7 BobT

BobT

    Vostok 1

  • -----
  • Posts: 116
  • Joined: 09 Feb 2012
  • Loc: Driftwood, TX

Posted 22 March 2019 - 01:02 PM

smile.gif I wish I were a "more experienced user".  I received my mount back in early December and have had precious few nights for testing because of the atrocious weather patterns.

 

I think you have a good plan.  I like Ross's comments on potential OAG problems and plan to reinspect my installation along those lines.  I have a small industrial-grade CPU mounted at the base of my pier and only have two short USB2 cables going to the mount, one for the imaging camera and the other for the guide camera and focuser.  Mount control is via Ethernet.

 

Hope all works out well,

 

BobT



#8 DuncanM

DuncanM

    Mercury-Atlas

  • -----
  • Posts: 2552
  • Joined: 03 Nov 2009
  • Loc: Arizona Sky Village or the rain forest

Posted 22 March 2019 - 03:49 PM

I have a CEM120 nonEC mount so I can't help much. There is a Google CEM120 users group that might be able to provide more comment.


  • RossW likes this

#9 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 24 March 2019 - 11:25 PM

Duncan, thanks for the link to the CEM120 user group. I have joined and even found Rainer there smile.gif  I guess I will post my reports over there too.

 

Well the gods were favourable to me and provided me with just enough time to carry out my proposed testing. For those that do not want to read through a wall of text and images I can summarise my testing by saying that the new beta 190315 firmware upgrade did not appear to solve any of the problems I was observing via the prior firmware 180810. I must say the firmware upgrade for the HC, RA, and DEC, went smoothly and I did recalibrate the RA/DEC encoders and searched/set the zero position.

 

I first wanted to determine if the firmware upgrade had made any improvements to the RA and DEC problems with the equipment unchanged from my prior trials,  so I left all the USB connections as-is, same power supply, and guided via the OAG. No noticeable changes in poor guiding performance, still had a sawtooth RA trace (unguided and guided), and large random DEC excursions. Changing the power supply made no difference but I expected that anyway. I then stripped the cabling down to the bare essentials, USB2 to mount and USB3 to imaging camera, and ran tests using the main scope and imaging camera as my guide camera (new profile in PhD as appropriate). Still no improvement in RA or DEC performance. 

 

As a comparison, I set up my EQ8 and TS Photoline 130 F7 refractor close to the CEM120 so that they both imaged and guided under the same conditions. I think the comparison is best summarised by the two images below, the upper being the CEM120 and the lower the EQ8. Y-axis scales are the same at +/- 2 arc/sec, and the x-axis time frame and scale are also the same, from just before to just after midnight, so both scopes see the same seeing conditions. My EQ8, even with its DEC backlash and encoders turned off, produced some of the best guiding I've seen, averaging 0.65 arc-sec RMS for the 2.5 hour imaging session (with periods below 0.5 arc-sec RMS) and producing a nice tightish scatter plot (upper right). All of the sudden excursions in RA and DEC visible in the EQ8 traces are dithering. The CEM120 on the other hand only managed 1.14 arc/sec for the session, with numerous large excursions in DEC unrelated to seeing. The scatter plot looks a mess, as do my subs. Longer exposure settings did not tame the sudden excursions (I trialled 1,2,3,4,5,and 10 second exposures during the night):

 

2019-03-23-%20CEM120EC2%20compare%20to%2

 

 

I then investigated the problem associated with the RA axis, which has me even more concerned than DEC performance. I'm still seeing quite a strong sawtooth RA trace even when unguided:

 

2019-03-23-%20CEM120EC2%20unguided%202s.

 

 If you are familiar with signal processing and sampling theory you may recognise the RA trace as one that is undersampled; it's effectively a filtered (smoothed) version of the actual movement of the RA axis over time. I wanted to see how the RA axis was actually physically moving the OTA, but to do that I needed to sample at a much faster rate (i.e., decreased exposure time). So I slewed to a very bright star near the meridian/CE, set PhD to download subframes from the guide camera (rather than full frames) and gradually decreased the exposure rate of the guide camera. I continued to decrease the sampling rate until I began to see the fundamental movement of the RA axis:

 

RA-oscillation-compare.png

 

At 100ms sampling (exposures) I can see that my mount's RA has a quite nasty and fast periodic error of at least 3.5 arc-seconds peak-to-peak. Also note that, as I increased exposure time the oscillations began to smooth out, reducing to around 1 arc-sec peak-to-peak at 3 s sampling. But that smoothing is simply PhD filtering the actual RA movement; the point-spread functions of any stars in my images were still be slewed across the imaging camera's sensor at up to 3.5 arc-sec (around 12 pixels) each second. In other words, using long exposure times may provide a deceivingly smoothed RA trace and lower reported RMS error, but it is simply masking the underlying problem of RA periodic error, rather than solving it.

 

To test this theory I guided using 5s exposures (low aggression/ large min-mo) and imaged a bright star using SharpCap. As expected, despite a reasonably smooth RA trace and low RMS error reported by PhD, the star was still moving considerably; take a look at this:

 

https://www.youtube....h?v=eYfhhEfOaxI

 

If you look closely you can see, besides some random seeing-induced movement, the star oscillating in a vertical direction (the direction of RA movement) with a period of about 1 second. This confirms the period of about 1 second I estimated in the 100ms exposure trace above.

 

I'm not sure how to explain this 1 second oscillation, but my "educated guess" would be that the RA's worm gear has perhaps been damaged and now has some eccentricity? Can anyone think of an alternative explanation? RA encoder feedback to the RA drive is causing an oscillation? Whatever it is it is meaningless imaging with this mount at a focal length of 2.8m, when the RA axis has a 3.5 arc-sec periodic error. I'll contact iOptron again and see what they have to say.

 

Thanks for reading.

 

 

 

Edit: corrected the image links.

 

 

 

 


Edited by RossW, 25 March 2019 - 06:55 PM.


#10 DuncanM

DuncanM

    Mercury-Atlas

  • -----
  • Posts: 2552
  • Joined: 03 Nov 2009
  • Loc: Arizona Sky Village or the rain forest

Posted 25 March 2019 - 12:15 AM

Your mount should have come with a PE printout. How does that printout compare to your tests?



#11 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 25 March 2019 - 02:54 AM

Both RA and DEC encoders look fine when measured at the factory:

 

CEM-120-EC2--RA.jpg

 

CEM-120-EC2--DEC.jpg



#12 DuncanM

DuncanM

    Mercury-Atlas

  • -----
  • Posts: 2552
  • Joined: 03 Nov 2009
  • Loc: Arizona Sky Village or the rain forest

Posted 25 March 2019 - 03:03 AM

Your actual performance, unguided, should be similar to the printout. If it isn't then it seems likely that the mount was damaged by not having the shaft locks engaged and having the gears switches engaged. Its possible that the nice people at customs/security may have done that for you.

 

Both my CEM60 and CEM120 PE were very close to the enclosed printout.


Edited by DuncanM, 25 March 2019 - 03:04 AM.


#13 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 25 March 2019 - 05:29 AM

Its possible that the nice people at customs/security may have done that for you.

 

Fortunately customs did not open the shipping box; when they open a package they always reseal it with tape that is clearly marked "Opened by Customs". And I doubt that damage occurred during shipping, because the mount is very well supported/cocooned in the shipping box. But if damage to the RA worm has occurred (speculation at this stage) during shipping, then that damage surely would not have occurred if the mount had been placed in the box with the axes locks and worm gear switches in the correct positions. The vendor is quite reputable so I am sure they or iOptron would "come to the party" if necessary.

 

I still have my fingers crossed that the oscillation visible in the RA error trace can be corrected via firmware or mechanical adjustment. On my next clear night I will try adjusting the RA gear mesh slightly and see if that reduces the amplitude of the oscillation. Perhaps there is simply too much slop in the gear mesh at the moment. I've already adjusted the RA mesh once with no discernable difference in the sawtooth waveform amplitude, but next time I will make a sequence of adjustments and record the results for later analysis.

 

Both my CEM60 and CEM120 PE were very close to the enclosed printout.

 

 

Why do I have that feeling of envy Duncan wink.gif



#14 Skymind

Skymind

    Explorer 1

  • -----
  • Posts: 88
  • Joined: 25 Nov 2010

Posted 25 March 2019 - 05:58 AM

Have you contacted the vendor about the locks and switches? Some vendors go extra mile to test every unit before shipping. In this case reporting to the vendor should do their favor preventing the same happen again.



#15 gotak

gotak

    Surveyor 1

  • *****
  • Posts: 1878
  • Joined: 18 Sep 2016
  • Loc: Toronto, CA

Posted 25 March 2019 - 06:17 AM

If you are within your 14 days I'd get a replacement copy.

Might be the easiest way to go. Encoders could be the cause of some issues too.

Edited by gotak, 25 March 2019 - 06:17 AM.


#16 HxPI

HxPI

    Apollo

  • -----
  • Posts: 1410
  • Joined: 05 Sep 2013
  • Loc: Virginia Beach, VA

Posted 25 March 2019 - 09:07 AM

My first post on CN, so please forgive any formatting issues. I recently became the proud owner of an iOptron CEM120 EC2. Given the many positive comments and supporting quantitative data posted here at CN, and my desire to image planetary nebula in the highest resolution my seeing will permit, I decided to bite the bullet and go with the dual-encoder version. I purchased it from a well-known store in Europe, and after a short delay due to back-ordering it arrived here within a few days of receiving the shipping notice. On opening the shipping box I was surprised to see that the DEC axis was unlocked and the DEC worm in the engaged position. Here's an image of the opened box minutes after arrival:

 

 

shipping-box-20190310_120313-1000.jpg

 

With the mount still in the box I carefully felt the RA gear switch and axil lock (on the underside of the mount) and noticed that they too were set to axis unlocked, worm engaged. This was confirmed when I carefully removed the mount from the box. Perhaps I am mistaken but if my understanding is correct, the axes need to be locked and the worms free when moving and transporting the mount; the worms are prone to damage in the "worms locked, axes unlocked" state. I can imagine there may have been quite a bit of torque applied directly to the worms while carrying the mount to the box and placing it into the box, given its considerable weight and lack of carrying handles like the EQ8 has. I immediately emailed the store the above findings to "cover my behind". I had asked the store to check the mount prior to shipping, so I assume the store simply forgot to return the switches/locks to their correct "safe for transport" positions.

 

Time passes while I wait for a clear night to test the mount. What follows below are my observations over two days of testing. I am fairly new to astronomy and astrophotography so my inexperience may be leading me to the wrong conclusions, but I am concerned as to what I am seeing; being quite different to those experiences and data that other members have posted. I may simply have a software setting incorrect, or old firmware (my mount has version 180810).

 

  • My equipment is the CEM120 EC2 with a Celestron Edge HD 1100 + ZWO OAG + ASI 1600MM pro.
  • Using iOptron Commander V6.1 and PhD2 via USB to control the mount.
  • Guide speed 0.6x (also tried 0.5x)
  • No wind
  • Using an OAG
  • Cabling is tight, as is the optical train. Cable management is a dream on this mount.
  • The RA has a periodic "tick tick tick" during fast slews.

 

What I am seeing that I am a little concerned about is:

 

  1. a repetitive, predictable sawtooth guide trace in RA when RA guiding is enabled (see below). Even low values of RA aggression like 10% cause this. These periodic oscillations can be as much as 4 arc-sec peak to peak, and certainly don't help in minimising my RMS guiding error. However I think I remember seeing others with this mount post similar concerns so perhaps my mount is "normal" in this respect? In any case I hope there is a method or software setting to reduce them.
  2. frequent sudden excursions in DEC, but only when guiding (see below). These ruin any chance of imaging at high resolution and result in the loss of many subs.

I tested the mount using a second completely independent scope and imaging train (TS Photoline 130 F7 refractor) to confirm that the source of the problem is probably either the mount hardware or mount/software/firmware bugs. The DEC instability does not occur as often using the refractor, perhaps because it is lighter and/or has a much shorter focal length (720mm vs 2800mm). Both scopes were 3D balanced on the mount.

 

Perhaps I don't understand how the DEC encoder is supposed to work, but it would appear to me it is not attempting to correct these excursions; it appears to be PhD doing all the heavy-lifting. I guess it is possible that the DEC encoder is causing the excursions?

 

Here are my settings in Commander:

 

Commander.gif

 

 

Example PhD2 guide logs can be download here if you wish to take a look:

 

https://www.ohmigall...3-17_232625.txt

 

https://www.ohmigall...3-17_232625.txt

 

So colleagues, what would be your best guess as to what is happening and why? Are there any further tests I should undertake to isolate the cause of these problems? Under EU law I believe I have 14 days from receipt to return the mount "no questions asked", but thanks to terrible weather 11 days have already passed, so I need to make a decision soon. If I do return it it will be for a replacement; I'm not giving up on this mount just yet. I have my fingers crossed that this is simply a software/firmware incompatibility/bug, not to mention operator error wink.gif

 

More to follow.

 

Ross

I have a CEM60-EC. What does the Camera and Optics parameters in the iOptron Commander ASCOM software do?

 

Ciao,

Mel


Edited by HxPI, 25 March 2019 - 09:07 AM.


#17 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 25 March 2019 - 06:56 PM

Sorry for the broken image links in post #9. I hope they are now working.



#18 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 26 March 2019 - 01:42 AM

What does the Camera and Optics parameters in the iOptron Commander ASCOM software do?

 

Mel, I'm not sure yet, I've only just started to use this software and mount, but please see:

 

https://www.cloudyni...cem60-settings/

 

Cheers,

 

Ross



#19 Tristarcapt

Tristarcapt

    Explorer 1

  • -----
  • Posts: 92
  • Joined: 20 Aug 2018

Posted 26 March 2019 - 05:33 AM

I have a CEM60-EC. What does the Camera and Optics parameters in the iOptron Commander ASCOM software do?

 

Ciao,

Mel

I have a cem25p with the same tab in Commander.  I'm not sure but I don't think the mount really does anything with that info.  It could be that ascom just shares that info with other connected devices.  Then those devices can automatically grab that info from ascom instead of asking you for it.  Like maybe the pixel scale, your image capture software can now grab it from ascom and write it to the header of your fits frames or maybe even the exif data in dslr frames.  Then other programs can automatically read it from the header, like plate solving programs.

 

Just a guess though,

Scott



#20 gotak

gotak

    Surveyor 1

  • *****
  • Posts: 1878
  • Joined: 18 Sep 2016
  • Loc: Toronto, CA

Posted 26 March 2019 - 05:35 AM

Could also be at one point they had thoughts of doing build in guiding. You can ask the maybe they'll answer.

The extra port was said years ago to be for things like running a focuser. That reality came about only recently. They are not a fly by night company and appears to have a long term plan as to what new stuff they will offer. Sometimes it takes them a looooong time to get around to it.

Edited by gotak, 26 March 2019 - 05:35 AM.


#21 HxPI

HxPI

    Apollo

  • -----
  • Posts: 1410
  • Joined: 05 Sep 2013
  • Loc: Virginia Beach, VA

Posted 26 March 2019 - 06:11 AM

Ok so it’s not something that would affect mount tracking. Another check in the box! Thanks.

 

Ciao,

Mel


  • f29pc likes this

#22 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 28 March 2019 - 03:40 AM

Ok, time for an update regarding my RA oscillation problem (I won't bother investigating the DEC problem too much until I get RA solved).

 

Tried a third power supply, feeding the original iOptron PS to only the mount and another PS to all other equipment. No go as expected; it was a long shot of course.

 

Uploaded a video showing the oscillation for iOptron tech support to inspect:

 

https://www.youtube....eature=youtu.be

 

Note: if I was using 1 or 2 second exposures in PhD, that waveform would look exactly like the sawtooth waveform that many iOptron mount owners have talked about (see my images above).It only looks similar to a sine wave because I'm using very fast sampling via 0.1 sec exposures.

 

I previously thought the oscillation was around 1 second, but upon careful measurement is came out to just over 3 seconds (I forgot to consider the guide camera image download time and PhD processing time between exposures). PhD also measures it as 3.3 sec via the FFT function.

 

2019-03-26-%20CEM120EC2-200ms-unguided-R

 

Kevin at iOptron support suggested I check the RA encoder cable under the RA control board cover. Continuity-tested every pin, plus tested for shorts between pins. All check out ok. Quality of workmanship (PCB and cables/connectors) looks good, though the cables could have been perhaps a little longer.

 

Checked whether, after a slew to target, the target RA and Dec (TRA and TDec on the hand controller) are the same values as RA and DEC. Passed that test with flying colours.

 

Then we hit the jackpot. Was asked to release the RA/DEC gear switches, move the OTA in RA/DEC, and ensure that the RA/DEC values displayed on the HC changed in sync with the movement. DEC values changed nicely, BUT ...... the firmware was dead to movements in RA. Gotcha finally. Probable dead RA encoder board. So all this time, my mount has been acting like a non-encoded RA mount. With the benefit of hindsight this should have been one of the first tests I performed. But to tell you the truth I would have expected the mount not to work at all, or at least give me an error message, if the encoder was faulty, so I did not suspect the encoder was completely inoperable.

 

But this finding leaves me with a few more questions:

  • If the RA encoder wasn't working, why was I not seeing the usual +/- 3 arc-sec periodic error these mounts usually have? I either missed it in my unguided graphs, or I have a mount with very low native PE.
  • Why didn't the software tell me it wasn't getting any encoder feedback when the RA axis moved? The firmware knows that the mount is an EC2, so it should be straightforward for the firmware to check for dead RA encoders and display an error message on the HC or within Commander. Perhaps they can add this check to a future version of the firmware. Or perhaps these things aren't as straightforward as I think.
  • Do non-encoder versions of the CEM120 also have this 3-second oscillation when unguided? It appears as a sawtooth waveform when guiding using 1 to 2 second exposures, similar to what many users have described in numerous forum posts. I guess it is possible that some may unknowingly have it, assume the sawtooth guiding waveform is "overguiding", and "hide" the problem by using long (4+ second) guide exposures to smooth out the sawtooth.

This oscillation is easy to check for actually. Simply slew to a very bright star (say, mag 1 or brighter, preferably near zenith for the least atmospheric seeing), reduce guiding exposure rate to less than 1 second (I've tried 0.1 to 0.5 seconds successfully), set your guider to download image subframes rather than full frames (this is important to achieve a high enough framerate; look in the camera tab in the "brain" of PhD), and then go unguided in RA (PhD's Guiding Assistant is great for that). If the oscillation is present it will quickly reveal itself, as seen in the video linked above.

 

iOptron said they will ship me a new RA encoder board tomorrow, so hopefully within a few days I'll report back with news that my RA is now stable. They've been very pro-active so I'm quite satisfied with their response.

 

Cheers,

 

Ross



#23 gotak

gotak

    Surveyor 1

  • *****
  • Posts: 1878
  • Joined: 18 Sep 2016
  • Loc: Toronto, CA

Posted 28 March 2019 - 05:35 AM

Awesome. And they should incorporate that check into the firmware.

Maybe the cem60-ec owner needs to do this check as well.

The non encoder mounts themselves also have low specced PE so this isn't surprising.

#24 HxPI

HxPI

    Apollo

  • -----
  • Posts: 1410
  • Joined: 05 Sep 2013
  • Loc: Virginia Beach, VA

Posted 28 March 2019 - 07:08 AM

Hmm yeah I need to check on this ASAP!!



#25 RossW

RossW

    Explorer 1

  • -----
  • topic starter
  • Posts: 75
  • Joined: 15 Jun 2018
  • Loc: Lake Biwa, Japan

Posted 28 March 2019 - 07:43 AM

Just correcting that one remaining image that is not showing in post #9

 

I then investigated the problem associated with the RA axis, which has me even more concerned than DEC performance. I'm still seeing quite a strong sawtooth RA trace even when unguided:

 

2019-03-23-%20CEM120EC2%20unguided%202s.




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: SCT, mount



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics