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

CEM60 or CEM60-EC

  • Please log in to reply
746 replies to this topic

#26 gotak

gotak

    Vanguard

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

Posted 25 April 2019 - 09:35 PM

For a (only? Depending on your POV) $3,498.00 mount the CEM60EC on my first run got me 0.39" RMS. I'd say that's good value swinging a Edgehd 8 with 0.7 reducer, qhy163 camera.

 

Suspect there's still some improvements to be had once I manage to eliminate the issue with my USB3 cable touching the floor by routing it through the mount. It likely would have been able to do better already if I can lock my edge's mirror but my AF solution moves the mirror so that's not an option. It's one reason why I just accept the need to guide. 


Edited by gotak, 25 April 2019 - 09:40 PM.


#27 Johnathan Edwards

Johnathan Edwards

    Sputnik

  • *****
  • Posts: 37
  • Joined: 03 Nov 2017

Posted 23 June 2019 - 02:08 PM

So in the end, is the EC version of the CEM60 worth the extra $1,300?  



#28 Wildetelescope

Wildetelescope

    Apollo

  • -----
  • Posts: 1456
  • Joined: 12 Feb 2015
  • Loc: Maryland

Posted 23 June 2019 - 06:42 PM

Hi All,

 

Let me firstly apologise because i know this topic has been much talked about and people's ears have soared up but i'm in the same dilemma as i was when i first started. Well to be fair, i'm even more scared now smile.gif

 

I had a perfectly well NEQ6-PRO mount which i sold just last week so am out in the market looking for a new mount. 

 

My budget is limited (£2500) and within this budget and in the UK market i'm limited to a very handful of mounts. 

 

1) NEQ6-Pro

2) EQ6-R 

3) CEM60

4) CEM60-EC

 

So thinking logically, i wanted to move up the scale so CEM60 was the obvious choice, but then i got introduced to the CEM60-EC mount. Don't get me wrong, i heard good stuff about both. 

 

The two scopes that will go on this mount are the SW Esprit 100 and C8. I've been guiding using a 60mm guidescope and will continue to do so for a little while longer until i can get the OAG sorted out. (i do have it, just need to get the focus done).

 

Whilst i was researching and finding more, i started to read up on the encoders and the horror stories with guiding. 

 

Is this still an issue or has the latest firmware addressed this issue?

 

I know the NEQ6-Pro is a beast of a mount and has served me well and caused me less issues than most of the mounts out there so i expect nothing but the same with the slightly higher price point mount now.

 

Thanks in advance

If you have the money and are curious, get the encoder version.  Why not?   It is cool technology.  There might a be a little learning curve with getting the right PhD settings, but that is true for guiding with PEC on as well.   The Rule of thumb used to be, if you guide, turn off PEC, because they would potentially compete with each other.  Now everyone is doing it the other way.  Same is true for the encoders.  Do you NEED the encoders?  Probably not, but they do offer some interesting twists, and I have seen some impressive results posted from all the CEM classes.  Yes, there are the horror stories, but they existed for every mount model.  Buy your mount from a trusted vendor with a good reputation for handling returns.

 

If you don't have the money, or have some other piece of gear that the extra cash could go towards, then get the standard version and don't look back.  Remember this is Astronomy, not cliff diving.  NO FEAR. waytogo.gif

 

Cheers!

 

JMD

 

JMD


  • Rob Bazinet likes this

#29 gotak

gotak

    Vanguard

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

Posted 23 June 2019 - 08:12 PM

So in the end, is the EC version of the CEM60 worth the extra $1,300?  

Can't compare it to a non EC CEM60. It is a lot better than the ieq45 pro. For a apples to apples you'll need to ask Chris White who's still working out some kinks with guiding.

 

For me to have RA=DEC in guiding is pretty normal unless seeing is just dead steady. RA excursions are limited to about 1". The performance is stable and gotten to the point where I started finding other weakness in the entire setup. 

 

Guiding a CEM60EC takes very different settings I find from a regular mount. You find PHD over compensating often and your task is more finding settings that avoids that than trying to control PE. During the process I realized my 174mini downloads dreadfully slow to the tune of 1-2 seconds of delay between frames no matter the exposure settings. This causes over reactions and the only solution was to extend the guide exposures. After using subframe setting I am still seeing between 300-500ms of delay but with the reduction it has helped close the gap on over reactions. The delays was true with the ieq45 pro but since it didn't have encoders the over-reaction wasn't as obvious, although in hindsight it did seem it was there all along.

 

The most interesting finding was that with the excessive frame download delays Phdlog viewer sees the 5.4 second "SDE", but once I resolved (sort of) the delays the SDE disappeared. Odd eh? Is it there? Does it ever existed or were people chasing a ghost? I don't know but when I was looking at a video feed of my main camera which has 0.54" image scale I can't see the oscillations you'd expect if SDE at 5.4 seconds was there.



#30 Der_Pit

Der_Pit

    Viking 1

  • -----
  • Posts: 855
  • Joined: 07 Jul 2018
  • Loc: La Palma

Posted 24 June 2019 - 05:10 AM

Well, I did still see them, with a ~1s update rate.  However, the Fourier analysis gives amplitudes of around 0.2-0.25".  Would you really see that, half a pixel?  I doubt I would, and my site has regularly seeing well below an arcsec.

And 0.25 amplitude is 0.5 peak-to-peak, something like 0.16" rms....

 

It seems logical that with a frame delay in the order of half the SDE period you do have a HUGE chance of doing the correction so late that it goes the same direction as the SDE error at that moment, increasing the signal, instead of damping it.  Increasing the exposure, so that you average over one period will of course improve the guiding then.  But you don't correct it either, and only the long exposure images will tell if that is a problem or not.  Guiding out a 5.5s oscillation is tough - you do need fast update times and lowest possible latency.

 

So I fully agree with your statement that the big 'issue' with EC is to find the proper settings for the guide parameters.  As you might remember, I'm also still hunting for them (but so far I only had a few nights with my new mount...)

 

FTR: When I had decided to get a CEM60 I went for the EC version, as I had the money and 'am always curious about the intersting twists'.  I'm quite sure the issues I still have are not related to the encoders, but to other changes I made at the same time.  Time will tell, but so far I don't regret buying it wink.gif



#31 John Miele

John Miele

    Gemini

  • *****
  • Posts: 3448
  • Joined: 29 May 2005
  • Loc: North Alabama

Posted 24 June 2019 - 02:47 PM

Can't compare it to a non EC CEM60. It is a lot better than the ieq45 pro. For a apples to apples you'll need to ask Chris White who's still working out some kinks with guiding.

 

For me to have RA=DEC in guiding is pretty normal unless seeing is just dead steady. RA excursions are limited to about 1". The performance is stable and gotten to the point where I started finding other weakness in the entire setup. 

 

Guiding a CEM60EC takes very different settings I find from a regular mount. You find PHD over compensating often and your task is more finding settings that avoids that than trying to control PE. During the process I realized my 174mini downloads dreadfully slow to the tune of 1-2 seconds of delay between frames no matter the exposure settings. This causes over reactions and the only solution was to extend the guide exposures. After using subframe setting I am still seeing between 300-500ms of delay but with the reduction it has helped close the gap on over reactions. The delays was true with the ieq45 pro but since it didn't have encoders the over-reaction wasn't as obvious, although in hindsight it did seem it was there all along.

 

The most interesting finding was that with the excessive frame download delays Phdlog viewer sees the 5.4 second "SDE", but once I resolved (sort of) the delays the SDE disappeared. Odd eh? Is it there? Does it ever existed or were people chasing a ghost? I don't know but when I was looking at a video feed of my main camera which has 0.54" image scale I can't see the oscillations you'd expect if SDE at 5.4 seconds was there.

Hmmm...I'll have to try this subframe selection option. I'm also using the ASI174mini as the guide camera and getting large overcorrections. How do you measure the delay time between guide frames being downloaded?...John



#32 gotak

gotak

    Vanguard

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

Posted 24 June 2019 - 03:40 PM

Hmmm...I'll have to try this subframe selection option. I'm also using the ASI174mini as the guide camera and getting large overcorrections. How do you measure the delay time between guide frames being downloaded?...John

The frame timestamp's in the guide log, it's the 2nd number in the CSV format you can just copy and paste into excel to get nice separation. 



#33 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • Posts: 2881
  • Joined: 30 Nov 2010

Posted 24 June 2019 - 07:00 PM

Gday gotak

 

The most interesting finding was that with the excessive frame download delays Phdlog viewer sees the 5.4 second "SDE", but once I resolved (sort of) the delays the SDE disappeared. Odd eh? Is it there? Does it ever existed or were people chasing a ghost?

For once, part of me agrees with you grin.gif .

( we know it "was" there as 4 different users using 4 different rigs clearly measured it.

Only question now is what triggers it to become visible )

I just downloaded yr logs from PHD2 site and stripped the 2 longish unguided data runs out.

The first run that showed the 54x fundamental had a lot of lost frames, but lost frames cant create ripple ( at the given framerate ), they can only blur it.

The second run at 650ms doesnt show any SDE but appears way more ragged than the first run?

The thing that interested me is the first run was done directly after a cal, and at a DEC near the equator.

The run appears to have been done using the same star the cal was done on.

You then moved several hours in RA ( no flip ) and recalibrated ( again near the meridien ),

but the logging runs were then done at DEC = +60, ie a long distance away from the second cal and first runs.

IIRC, you mentioned earlier that balance had an effect on yr data???

What would be really interesting is now you know how to trick PHD2 into getting its cadence right / wrong

do an unguided run at the same position using both settings and see what drops out.

Andrew Johansen Melbourne Australia



#34 gotak

gotak

    Vanguard

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

Posted 24 June 2019 - 08:13 PM

Imperfect balance causes deviations in RA after meridian flips that resulted in spikes that goes to around 2". This is likely due to stuck and slip events at the worm/wheel interface with the balance going towards the direction of motion. 

 

You actually don't need to wait for me to do new logs. You can see here another user's logs with similar cadence issues and the SDE showing at DEC 72.1: https://www.cloudyni...-2#entry9439188

 

There is something weird I think going on with ZWO drivers. Download delays shouldn't cause the amplitude of the guide trace to increase but it does appear to do that. Only thing I can think of is if the delay also causes change in the star shape but I am not crystal as to how that would come about.



#35 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • Posts: 2881
  • Joined: 30 Nov 2010

Posted 25 June 2019 - 12:05 AM

Gday Gotak

Imperfect balance causes deviations in RA after meridian flips that resulted in spikes

Maybe, but your data didnt show a flip, just a second calibration and a large change in position.

ie lots of variables between the 2 sets of data, so hard to conclude anything other than they gave very different results.

Download delays shouldn't cause the amplitude of the guide trace to increase but it does appear to do that.

I cant think of any way that can happen,

As per my previous comment, a sub optimal frame rate can certainly hide a rapid oscillation, but it cant create one ( if unguided ).

Also, the trace that didnt show the ripple actually had larger swings in its data, but they werent at any set freq, they were more randomly spread through the set.

I have attached the raw data plot for the run that didnt show any clear freq showing both RA and DEC.

In plots like this, you can use the ripple on the DEC trace to get an idea of the seeing

In the plot that had the ripple, the RA trace was more stable and had smaller pk-pk swings, very similar in size tothe DEC data.

All very intriguing

 

Andrew Johansen Melbourne Australia

No SDE.jpg



#36 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • Posts: 2881
  • Joined: 30 Nov 2010

Posted 25 June 2019 - 01:16 AM

Gday Gotak

 

You can see here another user's logs with similar cadence issues and the SDE showing at DEC 72.1: https://www.cloudyni...-2#entry9439188

Thks, hadnt seen that.

I note it is done at DEC = 72 so may have slight scaling errors for RA, and there was a LOT of drift.

That said, using the PEMPro log viewer and simply looking at certain sections, they all show an approx 54.5x fundamental. Not sure how accurate that is as the entire log is guided, so that may adjust the data a bit.

What was more telling is the PEMPro FFT reports the ripple as about 1.5 arcsec pk-pk

and that looks like what the actual data plots as????

I then looked at the log data using both PHD viewer and PEMPro viewer.

The Y scale data in the PEMPro viewer is approx 3x the scale of the PHD???

( I note cos(72) = 0.3 so maybe the PHD data is sensor deltas not axle deltas, or PEMpro is converting already converted data. No idea there yet )

Either way, i dont think the dataset is very useful to do a controlled test for if SDE is there.

 

Andrew Johansen Melbourne Australia



#37 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • Posts: 2881
  • Joined: 30 Nov 2010

Posted 25 June 2019 - 02:28 AM

Gday Gotak

 

The data discrepancy between PHD and PEMPro really confused me, so i just went to the raw log data for DerPits first run, where there was a large excursion when he wasnt guiding ( at about 1000 seconds in )

and processed it from first principles

From the raw log i see

 

Pixel scale = 1.28 arc-sec/px
xAngle      = -6.4 deg
Dec         = 72.1 deg
                                          X         Y       RA     DEC
968, 1012.496, "Mount", 4.447, 0.137, 4.404, 0.698,  0.000,0.007,0,,1,S,,,715221,496.34,0

 

sqrt( 4.447^2 + 0.137^2) = 4.45     = X/Y vector (in pixels)  from lock
sqrt( 4.404^2 + 0.698^2) = 4.459   = RA/DEC vector (in ???) from lock

 

Note both are very similar, hence i assume the RA/DEC vector is also in sensor pixels????

If you compare this data to the log viewer ( I am using 0.6.2 ), 

in RA/DEC mode, the spike max offset is shown as being about 5.7arcsecs in RA

Using RAerr = 4.404 pixels and 1.28arcsec/pix we get  5.64 arcsec,  sooo close

I suspect what PHD is displaying is the error on the sensor converted to RA/DEC "axes", with no cos(DEC) correction, and as such, the RA error isnt the axle error

At DEC = 72deg we get cos(72) = 0.31

sooo my guess is the Y scale for DerPits RA data ( via PHD viewer ) is out by a factor of 3.33  ?????

and that would line up with what the PEMPro conversion showed.

No idea any more confused1.gif

Maybe someone who posts on the PHD site can get confirmation, as thats not something i had ever hit before.

 

Andrew Johansen Melbourne Australia


Edited by OzAndrewJ, 25 June 2019 - 02:30 AM.


#38 gotak

gotak

    Vanguard

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

Posted 25 June 2019 - 05:45 AM

Exactly. It's very strange.

At this point my doubts are entirely with PhD. As said before a visual inspection of the main camera feed video feed in real time only shows seeing effects. There is no oscillation at 5 or so second range. This jives with others also doing similar tests on EC mounts. My main camera ends up at 0.54" scale so if we were seeing such large movements, it would have been very clear. Instead all I see is seeing effects.

#39 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • Posts: 2881
  • Joined: 30 Nov 2010

Posted 25 June 2019 - 05:59 AM

Gday Gotak

 

There is no oscillation at 5 or so second range.

I disagree with you there, as the PHD query only affects magnitude, not freq.

Too many mounts have shown the 54x ripple for it to be "fake", and the mathematics of a 54x fundamental line up with the encoder line count too sweetly.

All DerPits "guided" traces show an underlying  54x fundamental,so again, until proved otherwise, i assume he has a ripple and his guiding cant cover it up.

Also, the earlier data was collected using PHD, PEMPro and Metaguide, and all gave the same freq results, so i trust that part to be real.

Its now just a matter of is it big enough to be a problem, and for most, it isnt, but if DerPits data is correct, he has a relatively large SDE, so a new test at DEC = 0, unguided and at a high frame rate would be very informative.

 

Andrew Johansen Melbourne Australia


Edited by OzAndrewJ, 25 June 2019 - 06:00 AM.


#40 Der_Pit

Der_Pit

    Viking 1

  • -----
  • Posts: 855
  • Joined: 07 Jul 2018
  • Loc: La Palma

Posted 25 June 2019 - 07:27 AM

Its now just a matter of is it big enough to be a problem, and for most, it isnt, but if DerPits data is correct, he has a relatively large SDE, so a new test at DEC = 0, unguided and at a high frame rate would be very informative.

 

I'll try to deliver ASAP (I mentioned myself that the data I posted is likely not too useful as I didn't care for guiding/alignment that day), but really first need to fix my pier and/or have a low wind day. Thu-Fri night the predictions look good....

 

The wrong amplitude is indeed worrying.  If that really were a 0.8" amplitude instead of the reported 0.25" that would be disappointing and call for trouble, should I go for longer FL one day...



#41 John Miele

John Miele

    Gemini

  • *****
  • Posts: 3448
  • Joined: 29 May 2005
  • Loc: North Alabama

Posted 25 June 2019 - 09:42 AM

My guide logs showed only a 700ms download time for my asi174mini but I tried subframe guiding anyway last night. The large sawtooth motion was gone but there were huge periodic swings in ra sometimes 5 arcsec in magnitude over one guide pulse. The overall RA RMS was very poor. Well over 1.5 arcsec. The Dec RMS as usual was great. Around .25 to .3 RMS. Turned off guiding and all the large RA swings and oscillations went away. Seeing was not too bad and why would RA be 7 or 8 times worse than DEC?...john

#42 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • Posts: 2881
  • Joined: 30 Nov 2010

Posted 25 June 2019 - 04:14 PM

Gday DerPit

 

I mentioned myself that the data I posted is likely not too useful

All info is useful, as long as you know how it was collected.

Inormally ask people to log data at a DEC between the zenith and equator to maximise recorded RA error and remove refraction. I constantly compare datasets using PHD, Pempro and my own app, but till yesterday had never realised that the PHD log data might not include a cos(DEC) correction.

So i learnt something new from it grin.gif

 

The wrong amplitude is indeed worrying.  If that really were a 0.8" amplitude instead of the reported 0.25" that would be disappointing

Well just for info, use the PEMPro viewer as a cross check. It has a really neat dynamic range selector so you can select the clean sections of your traces to analyse very easily.

Also, as its all guided data, it may actually turn out that the guiding is affecting the drive speed software and hence allowing the uncontrolled SDE to be seen.

The later tests will highlight that.

Just thinking on that, if you do a run nearer DEC = 0, can you run unguided at the same framerate for a few mins, then just turn guiding on at the high framerate and see what happens?????

It may be that a high "guide rate" doesnt work well with the speed feedback loop firmware.

( And that would also explain what John is reporting, ie guiding affects the SDE control code?????  )

 

Andrew Johansen Melbourne Australia



#43 Der_Pit

Der_Pit

    Viking 1

  • -----
  • Posts: 855
  • Joined: 07 Jul 2018
  • Loc: La Palma

Posted 26 June 2019 - 08:00 AM

Hi Andrew,
 

Well just for info, use the PEMPro viewer as a cross check. It has a really neat dynamic range selector so you can select the clean sections of your traces to analyse very easily.

I don't have any Windows, so that might be difficult wink.gif

But I should see it as a clear difference in guiding performance for high/low DEC targets, is it?
 

Just thinking on that, if you do a run nearer DEC = 0, can you run unguided at the same framerate for a few mins, then just turn guiding on at the high framerate and see what happens?????

 

Sure. Didn't want to do that w/o proper polar alignment....

 

It may be that a high "guide rate" doesnt work well with the speed feedback loop firmware.
( And that would also explain what John is reporting, ie guiding affects the SDE control code?????  )

Guess a 'good' test would be running on the same guide star with different settings then.  I've done that so far only for different targets and seeing conditions, so it's not (yet) clear to me what differences in guiding come from the hardware, and which from external influence.

 

I'll ping you once I have some new stuff (I do have a few more old ones, some with short GA runs and really doing imaging, but also only rather high-declination targets.)



#44 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • Posts: 2881
  • Joined: 30 Nov 2010

Posted 26 June 2019 - 05:42 PM

Gday DerPit

 

But I should see it as a clear difference in guiding performance for high/low DEC targets, is it?

Actually, "guiding" at higher declinations is in theory easier as the actual sensor errors are smaller.

This effect works in reverse if trying to see whats going on as it hides the errors.

To do a "test" of tracking etc, its best to use a low declination so that the error "on the sensor" is physically as large as you can make it.

 

 

Guess a 'good' test would be running on the same guide star with different settings then.

Thats a gold standard test, as you can immediately "see" the effects in the one trace, vs try and compare different runs individually, as they all scale differently.

( This is part of why i wrote my app to overlay different datasets, as it means all the plots are seen at the same scale and timebase.)

Andrew Johansen Melbourne Australia



#45 souls33k3r

souls33k3r

    Vostok 1

  • -----
  • topic starter
  • Posts: 131
  • Joined: 20 Apr 2016

Posted 27 June 2019 - 10:48 AM

I know i haven't updated you all with my decision but about 3 weeks ago when my mind started to hurt more than it should, i caved in and spent my money on CEM60-EC. I'm hoping in the next 2 weeks i will have it with me. 

 

As much as i wanted to, but i just couldn't justify the cost of the Tri-pier but i am planning on putting a pier in my garden in the next few weeks. Still, would've loved to have a tripod/pier that i could use.



#46 Vagus

Vagus

    Sputnik

  • -----
  • Posts: 29
  • Joined: 02 Apr 2011
  • Loc: Ontario, Canada

Posted 27 June 2019 - 03:55 PM

What the heck is SDE?



#47 Chuckwagon

Chuckwagon

    Viking 1

  • *****
  • Posts: 756
  • Joined: 23 Jan 2008
  • Loc: Orem, Utah, USA

Posted 27 June 2019 - 10:19 PM

What the heck is SDE?

Sub-Divisional Error.



#48 Der_Pit

Der_Pit

    Viking 1

  • -----
  • Posts: 855
  • Joined: 07 Jul 2018
  • Loc: La Palma

Posted 28 June 2019 - 03:58 AM

So last night was quite a desaster :(

I'll still have to go through the logs, which is somewhat a mess as PHD2 kept crashing a lot.

 

But the essence is that if I run unguided there is a drift of ~1.2 arcsec per minute in RA.  I have no idea where that is coming from.  ISTR someone had mentioned a similar issue in the firmware update thread - will have to look for that.

The drift-corrected errors in that unguided phase seem reasonable - something like an arcsec PtP, so around 0.3 RMS.  But as soon as I start guiding it begins to oscillate, amplitude increases to 2.5-3 arcsec PtP, RMS 1 arcsec.  While this might sound not too bad, it is (persistently over many hours) a factor 4 larger than the DEC RMS.  The spot diagram doesn't even look like a football - it's a cigar.

 

I had experimented throughout the night with various guide algorithms, aggressiveness settings, exposure times.  Some settings seem somewhat better than others, but never did I get substantially below 1" RMS.

 

One of the unguided periods suggested that there was no 5.5s peak at all - only a 2.8s one.  That one is also visible in several other power spectra, together with the 5.5 one.  I wonder if that is the base and 5.5 is a harmonic?  I had tried 2s exposure and adjusted the 'Time Lapse' to get a 2.8s update frequency.  My impression was that was one of the better settings.

 

Maybe someone has additional input/suggestions - would be highly welcome.  I'll post more details with logs later.  Right now I start wondering whether I should better have gone for the non-EC one :(



#49 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • Posts: 2881
  • Joined: 30 Nov 2010

Posted 28 June 2019 - 05:35 AM

Gday DerPit

 

if I run unguided there is a drift of ~1.2 arcsec per minute in RA.  I have no idea where that is coming from.

That was the biggest error detected in the early version 60EC data, ie it had a very visible SDE ripple but the RA drift completely swamped it. Some data had shown the new calibration routine fixed the drift but not the SDE.

 

One of the unguided periods suggested that there was no 5.5s peak at all - only a 2.8s one.

Need to see the raw data and framerates when that happened, as framerates here can affect the results quite badly.

As mentioned earlier, the framerate used can give very odd data if it is close to the error frequency, hence why a very fast framerate is required when analysing tracking for this type of error.

 

I wonder if that is the base and 5.5 is a harmonic?

I strongly doubt that, based on five mounts all now showing the 5.5sec ripple, and the known encoder linecount also agrees with the 5.54sec frequency

I suspect your data is being distorted by a framerate that is too long to accurately log the data.

The raw logs will show that.

 

I had tried 2s exposure and adjusted the 'Time Lapse' to get a 2.8s update frequency.

That is not a good data collection frequency to use to analyse a 5.54 ripple, as it effectively hides the error

 

Right now I start wondering whether I should better have gone for the non-EC one

Dunno yet.

Many reports indicate that when not guided, the EC models track reasonably well.

Might be that the EC is a bit like my AZEQ5 when using PPEC, ie the mount disables tracking when guides come in.

Based on that assumption, one totally unsubstantiated guess is that when a guide comes in,

the encoder feedback loop is cancelled if the guide rate is too fast,

and as such the motor feedback loop constantly stops controlling the SDE

and hence the error "appears" to increase.

Using a much slower guide rate may not annoy it ???

Dunno.

Andrew Johansen Melbourne Australia


Edited by OzAndrewJ, 28 June 2019 - 05:41 AM.


#50 Der_Pit

Der_Pit

    Viking 1

  • -----
  • Posts: 855
  • Joined: 07 Jul 2018
  • Loc: La Palma

Posted 28 June 2019 - 11:23 AM

Hi Andrew,
 

That was the biggest error detected in the early version 60EC data, ie it had a very visible SDE ripple but the RA drift completely swamped it. Some data had shown the new calibration routine fixed the drift but not the SDE.


Ah, so you say the drift is a known old thing? But this is latest FW (20190424) and still seems to show  it frown.gif
I've fixed some limits in my capture program, and want to try custom tracking rates tonight.  I assume/hope that if the drift is gone Guiding will immediately improve (needing less guide pulses).  So do you have a clue were the drift comes from?  You mention the calibration - I assume that is the encoder calibration after FW update?  I have re-done that today, this time with fully loaded mount on the pier.  No idea if that changes something...
 

[using 2.8s guide cadence]
That is not a good data collection frequency to use to analyse a 5.54 ripple, as it effectively hides the error

If it's 5.54, indeed not. The idea was if it were 2.8 base I'd average over it.  I didn't want to analyze it, I wanted to observe DSOs tongue2.gif 
For analysis I had been running my main cam (USB3, sub-frame) as guide camera, also to get a better focus for the tests, with 0.5s exposures.
 

Many reports indicate that when not guided, the EC models track reasonably well.
Might be that the EC is a bit like my AZEQ5 when using PPEC, ie the mount disables tracking when guides come in.

For the CEM60EC, you can indeed disable guide signals, but they are on by default.
I started wondering if it might improve things to use the ST4 port instead.  
 

Based on that assumption, one totally unsubstantiated guess is that when a guide comes in,
the encoder feedback loop is cancelled if the guide rate is too fast,
and as such the motor feedback loop constantly stops controlling the SDE
and hence the error "appears" to increase.


It's enough if the correction arrives at the mount half a phase too late - that way it will double/amplify any inherent periodic error.  That is why additional delays between error measurement and correction application drastically lower the bandwidth of such a control loop, and past the 0db point it starts enhancing the errors instead of damping it.
 

Using a much slower guide rate may not annoy it ???

Yes.  But I cannot really use that, because of the drift.....

But I'll have a try with an 11s loop.




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






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics