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

Calibrating IOptron "EC" mounts

  • Please log in to reply
39 replies to this topic

#1 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 23 October 2019 - 03:37 PM

As suggested, have started a new thread to deal with the specific behaviours of IOptron EC mounts when pulseguided

Once more, i used the 8 oct dataset from StarFlyer, as it has everything in one bit.

I modified my app so i can read out a full session ( with timestamps ) from the PHD debug log ( vs the guidelog ), as this allows a continuous plot to be compared to the commander data.

There are 4 attached diags below

1) Shows the RA data for the session from calibration through to oscillation

    i also manually superimposed what the commander log showed for the calibrate section

    You can clearly see that the "theoretical" distance travelled via pulses is not achieved by the mount. Why??

2) Shows a closeup of the initial ( West )calibrate section

    Again, we see the mount is moving but nowhere near the speed requested

    He used 900ms pulses and 1000ms exposures so there was roughly 2100-2200ms between pulses, ie heaps of time

3) Shows the rapid ( East ) return to home after the cal had moved enough

    In this case, one pulse "appears" to move at almost the correct speed, but then the next 2 pulses get ignored???

4) Shows the post calibration oscillation starting up when guiding ( it only stopped when the aggression was dropped )

    The interesting bit here is how once again, the mount is not applying the move at the expected rate

     and this is creating a hysteresis effect where the guides are out of synch with the real error

     and the system starts chasing its tail

 

Thus, analysing something "similar" to a calibrate may assist in finding what settings can be used to get the mount to match the guide requests.

This really needs a scripted process, where PHD is run at a high framerate to merely collect data

and a third party app can supply scripted pulses at whatever cadence is chosen, to see the effects.

No idea how to do that with the IOptron driver tho.

 

Andrew Johansen Melbourne Australia

Cal 08 Oct Full.jpg

Cal 08 Oct RA Start.jpg

Cal 08 Oct RA Return.jpg

Cal 08 Oct Guide oscillate.jpg

 

 


  • Destrehan Dave and alphatripleplus like this

#2 HxPI

HxPI

    Surveyor 1

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

Posted 23 October 2019 - 06:22 PM

Is this with latest official or beta firmware? What’s the difference?


Edited by HxPI, 23 October 2019 - 06:23 PM.


#3 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 23 October 2019 - 07:09 PM

Gday HxPI

 

No idea grin.gif

His log data for the 8th showed

2019-10-08 18:58:40.364 :FW1#
2019-10-08 18:58:40.416 190716xxxxxx#
2019-10-08 18:58:40.426 :FW2#
2019-10-08 18:58:40.465 190716190716#

but i have no idea what that really means

 

That said, it is the dataset i was analysing to try and see what was going on, as it had a bit of everything.

The methodology used to detect bad calibrates wont change for the later firmwares so if someone can grab some Calibrate data using the latest firmwares, and using different pulse lengths / guide speeds etc, we can see if it is still there.

ie the mount may behave differently based on pulse length + guide speed + guide cadence, hence why some work and some dont. A bit of testing may highlight that and allow users to find the lower limits they can use.

 

Andrew Johansen Melbourne Australia



#4 555aaa

555aaa

    Vendor (Xerxes Scientific)

  • *****
  • Vendors
  • Posts: 1464
  • Joined: 09 Aug 2016
  • Loc: Lynnwood, WA, USA

Posted 23 October 2019 - 08:00 PM

Can't you just look at a bright star with a video camera or DSLR in video mode when you send the pulses? 900ms at 0.5 sidereal is a very large move.

#5 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 23 October 2019 - 09:38 PM

Gday 555aaa

 

900ms at 0.5 sidereal is a very large move.

Yep, but what we are looking at here is the way PHD calibrates the drives and for that it needs to move a set distance.

The guide rate and pulse length used to achieve the move "appears" to vary quite a bit due to the fact the mount doesnt move at the expected rate.

I have just analysed starflyers second calibrate from the 10th

He changed guide rate, pulse duration and focal length so that introduces a lot of changes

but the theoretical vs actual moves give a much better correlation.

ie the settings used can greatly vary the PHD calibration results, and that shouldnt be the case.

 

Andrew Johansen Melbourne Australia



#6 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 23 October 2019 - 11:37 PM

And here is the RA data for the same mount a week later

Same firmware but different OTA and settings, and Very different results

 

The 08 Oct run ( 5.16 "/pix ) got calibrate results of

RA    = 0.654 px/sec  ( 3.38 "/sec )

DEC = 2.242 px/sec  ( 11.57 "/sec )

( expected was 12.0 for both )

 

The 16 Oct run ( 1.43 "/pix ) got calibrate results of

RA    = 3.755 px/sec  ( 5.37 "/sec )

DEC = 5.105 px/sec  ( 7.30 "/sec )

( expected was 7.5 for both )

 

Soooo, it appears the RA calibration process can be highly affected by settings

and pulse guides sent in RA dont run at the expected speeds.

This would easily explain a lot of the variable results people see.

 

Might be a useful test for users having problems to see how far off reality

the calculated PHD calibration data is????

 

Andrew Johansen Melbourne Australia

 

Cal 16 Oct Full.jpg

 

 

 

 

 



#7 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 24 October 2019 - 12:17 AM

And just for fun, ( and to cross check my app ),

i just grabbed a PHD2 "debug" log i pilfered somewhere recently for a "premium" mount.

It is for a 10u2000 and shows the actual PHD recorded position lines up almost perfectly with the theoretical pulses, so it can happen :-)

 

Andrew Johansen Melbourne Australia

10u2000.jpg


  • RossW likes this

#8 Der_Pit

Der_Pit

    Viking 1

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

Posted 24 October 2019 - 04:32 AM

  Hi Andrew,

 

And here is the RA data for the same mount a week later

Same firmware but different OTA and settings, and Very different results

 

The 08 Oct run ( 5.16 "/pix ) got calibrate results of

RA    = 0.654 px/sec  ( 3.38 "/sec )

DEC = 2.242 px/sec  ( 11.57 "/sec )

( expected was 12.0 for both )

 

The 16 Oct run ( 1.43 "/pix ) got calibrate results of

RA    = 3.755 px/sec  ( 5.37 "/sec )

DEC = 5.105 px/sec  ( 7.30 "/sec )

( expected was 7.5 for both )

 

Just to be sure - where was this calibration done?  I had similar results yesterday,

RA = 3.335 px/sec (4.27"/s)

DE = 5.846 px/sec (7.48"/s)

 

This, however, had been done at target, declination=57.2 degrees, and  3.335/cos(57.2) = 6.15px or 7.88"/s.  Guide speed was 50/50, so the values are as expected.

 

Oh, and yes, the 190716 firmware is the latest ('good') Beta version.



#9 spokeshave

spokeshave

    Vanguard

  • *****
  • Posts: 2146
  • Joined: 08 Apr 2015

Posted 24 October 2019 - 07:28 AM

I think it is worth noting that this behavior is being seen in one CEM60EC. My CEM120EC does not display this behavior. So, this is not necessarily an analysis of the calibration of all iOptron EC mounts, or for that matter, all CEM60EC mounts.

 

Tim



#10 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 24 October 2019 - 02:24 PM

Gday DerPit

 

Just to be sure - where was this calibration done?

As he noted in the other thread, when he calibrates, he slews to DEC = 0.0 and very close to the meridien

and thats what his logs show

 

Gday Tim

 

I think it is worth noting that this behavior is being seen in one CEM60EC.

Agreed. I was initially analysing starflyers data because it was so odd and different between runs

ie it semi confirms the settings may be a big part of the systems behaving erratically.

His data has now highlighted something to look for, so I am now looking for some calibrates from other datasets i have squirreled away to see if any have similar results. Problem is to get the correct timestamps, offsets and settings, i need the "debug" not "guide" logs, and i dont have as many of them.

 

Also, as you have a 120EC, we have been working with IOptron ( on another site ) to deal with a bug where DEC guiding stops working randomly. ( It was tracked down to a glitch when the GPS fixes during a run )

During this, IOptron mentioned the 120EC uses different algorithms ( they didnt say how much lol.gif )  so i fully expect the 120EC to behave differently.

Thats why i suggested testing using multiple cals at multiple rates to see if it is "consistent"

 

Andrew Johansen Melbourne Australia



#11 Der_Pit

Der_Pit

    Viking 1

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

Posted 25 October 2019 - 08:46 AM

Thanks for confirmation Andrew!  ISTR that it was indeed at zero degrees, but couldn't find it, so I better asked.

 

For now I'll attach my complete dataset from Oct 26.¹  It's two parts, the first one has two (wrong) calibrations.  To me it looks like some strong drift in RA that skews the DEC leg, so probably something different from what starflyer experienced.  But maybe you can dig out more details - I still didn't find the time to write some parser for the logs blush.gif

The second (large) part has a (successful) calibration and a lot of guide data.

 

¹ actually it's too large (2.1M).  Get it here

 



#12 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 25 October 2019 - 04:50 PM

Gday DerPit

It's two parts, the first one has two (wrong) calibrations.

They actually ran without "error", hence proving why this is so tied to settings used, ie they are gold grin.gif

Have attached a true sensor snail trail for both calibrations side by side, and also an extract of the 2 runs plotted from the debug log

 

  To me it looks like some strong drift in RA that skews the DEC leg, so probably something different from what starflyer experienced.

Yes and no, ie it is not strangewaytogo.gif .

This closer approximates my suspicions that the mount doesnt apply the RA pulses at the required rate, but may also be "storing them up" and processing as it sees fit.

ie when PHD calibrates, it sends enough pulses to move the target west a set no of pixels

Once done, it returns to start using east pulses based on max pulse len ( ie using the same time as west got sent )

It then moves north till it detects movement, then repeats the out/back process for north/south.

If you look at the snail plots, you can see the fast RA returns moved different distances before North started

At that point, the North moves started, but the snail trail shows the east moves were still processing

and stopped when they got back to the same RA position????

The resulting "rates" were similar, but the North angles were way off. ( This affects later conversions )

Now we look at the "debug logs"

We can see the blue "RA" trace reported by PHD moved "steadily" west ( but at a wrong/lower than expected rate )

It then reversed and came correctly back to zero

Only problem is the DEC cal moves actually started when the "theoretical" East moves had stopped

but we can see the RA was still moving, even tho no RA pulses are being sent????

We also see that you did 2 identical cals in a row, with the same settings

I the first run, RA slewed out and back in 80sec yet the second run only took 65sec

and this is why the first snail trail has such a big RA drift whilst the DEC is calibrating.

 

I cant confirm with your commander logs yet as they are a totally different format to the others

but it does look like the east moves were still running in the background when the North moves started.

Again, the ASCOM.IsGuiding flag reported by Commander appears to be the culprit here.

 

Andrew Johansen Melbourne Australia

RA drift.jpg RA Overrun.jpg

 

 


  • RossW and Der_Pit like this

#13 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 25 October 2019 - 06:40 PM

Gday DerPit

 

Just looked at your later calibration and guiding

The calibration did look good, but i suspect it has a different mount guide rate

but there is no data to confirm it

ie the first commander logs show 90% but there is no commander data for the second run

and the calibrate for that would indicate a 50% rate??????

That said, the later guiding looked pretty good, but there are some very large mid sub spikes in there

and not sure what caused them

 

Andrew Johansen Melbourne Australia

Run2 Cal.jpg



#14 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 25 October 2019 - 09:19 PM

Gday DerPit

 

but there are some very large mid sub spikes in there

and not sure what caused them

Have attached an overview of a set of subs where RA spikes occurred. ( These are also seen at times in 120EC2 logs )

I also then made a detailed plot using the debug log data for one of the worse plots.

We clearly see the RA deviated 10arcsec in 2secs with no pulseguide sent.

How it recovers is interesting as when looked at in detail, PHD detected the 10 arcsec error and sent a 13arcsec pulse. After 4 seconds, PHD only detected 4 arcsec of movement so sent a new 8 arcsec pulse.

After 4 sec it was OK as far as PHD was concerned so no pulse, but it was still moving ?????

After another 4 sec, it was now 8 secs overshot so PHD issued a new reversal pulse of 9arcsec

after 4 seconds, this had been totally ignored as the RA kept going to 13arcsec overshot

.PHD then sent a bigger  16arcsec move and the RA finally reversed, but again, at nowhere near the expected speeds.

ie as per starflyers data, the mount is simply not responding to RA pulses at the expected rate, and PHD doesnt appear to know anything about it??????

All good fun

Andrew Johansen Melbourne Australia

DEC Ripple.jpg RA glitch.jpg

 



#15 dapalmer

dapalmer

    Mariner 2

  • *****
  • Posts: 261
  • Joined: 21 Nov 2016
  • Loc: Jackson, MO

Posted 26 October 2019 - 09:00 AM

So what do you propose to do with this information?



#16 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 26 October 2019 - 04:00 PM

Gday Doug

 

So what do you propose to do with this information?

Still just collecting data to try and nail down the real cause of the problem, what to look for and possible workarounds. Then the users can hit IOPtron with a properly researched bug report

It currently looks like there are a range of problems involved, so its not simple

 

As an aside, another user with a 120EC was having problems where the reported RA would spike ( by a random amount ) and then DEC guiding would just stop. It was also semi random as to when it happened, so very annoying.

We eventually got logs from 3 different mounts where it happened, and that was enough to trace the cause.

( In this case, a mount was started with manual time entry but the GPS was taking "about" half an hour to fix. When it fixed mid run, the changed time resulted in a random sized "tweak" to the reported RA, and a code bug disabled DEC guiding )

 

Andrew Johansen Melbourne Australia


  • psandelle likes this

#17 Der_Pit

Der_Pit

    Viking 1

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

Posted 27 October 2019 - 03:26 PM

Hi Andrew,

 

thanks so much for the detailed analysis.  Happy you mentioned 'All good fun', so I don't have to have a guilty conscience flowerred.gif

 

Yes, I had thought that something was bad with the guide speed setting.  I had cold started both the mount and the indi control program, and went for calibration.  Looking at the settings I noticed that the reported values in the overview were zero, and the suggested (pre-filled) values to change them were something like 0.1 for RA.

Therefore, for the third run, I had set them manually (again?) to 0.5/0.5.  I thought it would always do that on first start, but maybe I'm wrong there.

 

As for the really bad spikes between the dither ones:  Those most likely are from focusing.  I use an OAG, and changing focus (and especially changing focus direction) always slightly moves the pointing.  I sometimes forget to suspend guiding when focusing, that then creates such nasty excursions.  I don't think that part of the log provides useful information...

 

I still have that scripted test we talked about on the todo list, but currently we have really bad weather, so I'm not sure yet if/when I'll find time for it undecided.gif



#18 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 27 October 2019 - 04:01 PM

Gday DerPit

 

Yes, I had thought that something was bad with the guide speed setting.

Hmm, the initial commander logs showed you were at 90%, but it didnt show in the PHD data

The last calibrate had no commander data, but the cal would have indicated 50%

but once more, the PHD logs had no details of these settings

Maybe an Indi quirk??

 

 

As for the really bad spikes between the dither ones:  Those most likely are from focusing.

Dunno there. The big move was over 50 clock seconds or more???

Also, there is virtually no change in the DEC traces

On top of that, it also shows the mount simply did not respond to the pulses as expected

All very odd

 

Andrew Johansen Melbourne Australia


Edited by OzAndrewJ, 27 October 2019 - 04:03 PM.


#19 starflyer

starflyer

    Lift Off

  • -----
  • Posts: 12
  • Joined: 07 Dec 2011

Posted 29 October 2019 - 11:10 AM

Hi guys,

 

I'm back with more logs, thought I'd post in here rather than the old thread.

Logs are here in the folder dated 24th October, there's also a folder with some short unguided exposures in there too.

 

Andrew, as you suggested I ran three lots of calibration at 0.50 rate, 400 / 800 / 1200ms guide pulses, and also three lots at 0.8 rate.  I was seeing odd calibrations again, but at lower pulse length they weren't too bad.

 

 

Look forward to seeing what you make of these.

 

 

Thanks,

Ian



#20 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 29 October 2019 - 06:42 PM

Gday Ian

These are goldwaytogo.gif

Have attached a continuous plot of all the cals in a row ( and a summary below )

The blue is the RA trace, as measured by PHD

The pink is the expected path based on pulses sent at the given rate.

In all cases, we can see the PHD plot shows the mount moves at the speed it wants to ( about 1.3 arcsec/sec )

not what has been specified ( ie 7.5 vs 12.0 )

The shorter pulses tied with the long exposure means the mount appears to have more time

to complete the requested move before the next frame, hence getting a much more accurate calibrate.

Ref summary below of the results

The DEC data all seem to get pretty accurate results, but the RA gets progressively worse with longer pulses

and it appears the distance moved is the critical bit, not the rate or pulse size

This would line up with the theory that the mount just goes at one rate.

I also note a clear overrun/underrun in the RA data at the end of the East moves, and once more this lines up with the fact the mount may still be moving in RA when the DEC starts

Based on that

Another very interesting test would be to set the mount to 12.0 arcsec/sec and 1200ms pulses

That should give a big RA overrun

Now turn your camera so it is about 45degrees ( vs the nicely square setting you had )

It will be interesting to see how badly the RA drifting affects the DEC traces

 

Andrew Johansen Melbourne Australia

 

Results of the seven cals

 

Pixel scale = 1.43 arc-sec/px
Cal Dist    = 25 px      = 35.8arcsec
Guide rate  =  7.5"/sec  = 5.25 pix/sec
            = 12.0"/sec  = 8.39 pix/sec
Exposure    = 1500 ms
RA          = 20.65 hr,
Dec         = 0.0 deg,
Hour angle  = 0.01 hr,
Pier side   = East

Cal  Rate  Pulse     West         North
     7.5              5.25            5.25
1    7.5   400   2.9  5.002    91.2   5.331
2    7.5   800  -0.2  2.800    90.2   5.335
3    7.5  1200   0.9  2.351    90.6   5.257

    12.0              8.39            8.39
4   12.0   250  -0.7  7.715    90.7   8.466
5   12.0   800  -0.5  2.765    90.5   8.488
6   12.0  1200   1.7  2.251    90.9   8.474
7   12.0   400   2.5  5.084    91.1   8.649

MultiCal.jpg

 

 

 


  • Der_Pit likes this

#21 starflyer

starflyer

    Lift Off

  • -----
  • Posts: 12
  • Joined: 07 Dec 2011

Posted 30 October 2019 - 06:42 AM

Many thanks for taking the time to do this Andrew, I'll look to get the next test done when the weather improves here.

I'm not sure why the first run at 12.0"/sec ran at 250ms, I did set it at 400ms, and did notice that it had changed itself to 250 when I went to change it up to 800ms for the next run.

 

I want to guide the CT10 at 0.5x (experience has shown that it's a big lump to throw around at a higher guide rate), can you suggest a pulse length / exposure time from this data that would yield an accurate calibration?

 

 

Cheers,

Ian



#22 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted 30 October 2019 - 03:23 PM

Gday Ian

I'm not sure why the first run at 12.0"/sec ran at 250ms, I did set it at 400ms,

Doesnt matter, as the main aim was to get a spread of data when only one factor got changed at a time.

Having it all in one continuous section of one plot makes it so much more visible as to whats happening.

 

can you suggest a pulse length / exposure time from this data that would yield an accurate calibration?

Based on all the runs effectively going at about 1.3arcsec/sec ( according to PHD2 data )

your best calibration will be where the actual frame time of each cal step allows enough time for the exposure and the mount to move the defined distance at 1.3"/sec.  ie you cant at high guide rates :-(

 

your 250ms @ 12.0"/sec looked almost perfect

your 400ms @ 7.5 arcsec/sec also looked pretty good, but didnt return in time

That said PHD was probably already taking the next frame whilst the pulse was finishing so will build a bit of error into the centroiding.

Another test would be to limit the guide rate to say 10% ( or 1.5arcsec/sec )

We know the mount appears to want to go at this speed anyway, so its no loss

If you run the 3 calibrate pulses at that rate, i "suspect" all 3 will work well.

( and if so, you would use a low rate and high pulse size to do your cals

and later guiding would use the low rate to generate onger pulses, so you would need a longer frame time between guides to account )

 

Andrew Johansen Melbourne Australia


Edited by OzAndrewJ, 30 October 2019 - 03:27 PM.


#23 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted Yesterday, 05:51 PM

Gday All

Just as a bit more feedback, a 120EC user has done a set of calibrations using different settings

and has confirmed the 120EC can also be affected by the settings used.

Part of this does appear to be based on Commander not using the "IsGuiding" flag the way PHD expects

but the main problem appears to be how the IOPtron code handles pulse guides.

Have attached a marked up theoretical trace against what really happens

( ref plots above  for overviews )

Basically, a pulse should apply as per the thick red line

During this red section, the IOptron driver should set the "IsGuiding" flag, and clear it when done

if guiding with PHD, you can then insert a "timelapse" delay as per the thick yellow line

then the next exposure + download runs ( thick blue line )

The resulting thick green line is what the PHD log will show as the "averaged" rate,

as it only takes one frame per pulse.

Now the process repeats

What appears to be happening is the IOptron code doesnt always set the IsGuiding Flag

and doesnt apply the pulses at the expected rate.

As such, the averaged rate for the mount is actually the thick skyblue line

Whenever the thick green line runs at an angle greater than the thick skyblue line, the system appears to destabilise.

Long exposures and small pulses effectively reduce the green angle

Short exposures and large pulses effectively increase the green angle

Andrew Johansen Melbourne Australia

Analysis of PulseGuides.jpg

 

 

 

 


  • psandelle and alphatripleplus like this

#24 rgsalinger

rgsalinger

    Fly Me to the Moon

  • *****
  • Moderators
  • Posts: 5185
  • Joined: 19 Feb 2007
  • Loc: Carlsbad Ca

Posted Yesterday, 08:05 PM

Is there a problem with the images being produced that can be traced to a bad guiding algorithm? What seems to be in this thread is simply that theory doesn't match practice. The last thing that I would expect is that an encoder controlled mount would correct to the extent (time and distance) that PHD or any other guiding software instructs it to do. It must treat the encoder values as being of higher quality than any guide star centroid calculation. 

 

It's unfortunate that iOptron will not allow the encoders to be turned off. There's no log of what the firmware is telling the mount to actually do. All you can see are the commander and PHD logs. I know from experience that you need a log that shows how the end pulse values (if they even are pulses) are calculated. So, I look through this thread and I see nothing about bad images or links to them. The pulse is determined by an algorithm that takes into consideration a number of variables, it's not just a simply calculation as it is with a non encoder equipped mount. 

 

I have not been using PHD on my CEM120EC2. I no longer trust PHD as it has way too many switches and parameters that could upset things advertently or inadvertently. What I can say is that my dual encoder CEM120EC2 produces round stars time after time at 10 minutes of exposure using MaximDL. I have around 70 pounds on the mount now. I am using a PW 12.5 CDK and a (repaired) QHY16200A camera. I use very low aggression, 3 to 5 second exposures, am careful about calibration, and I do not correct until the error is around .3 arc seconds. Last time out (yesterday) I was, as usual, around .3 arc seconds in each axis. 

 

So, help me out here - are people actually getting bad results? If so what settings are they using and have they tried other guiding software? FWIW, I've also use the SKYX to guide the mount when the planewave was not on it and the results were the same - nice stars at lengths up to 10 minutes. I have the awful feeling that I'm missing something in this thread but I know from experience that encoder mounts do not simply behave as you expect them to do. 

 

Rgrds-Ross


  • psandelle and DuncanM like this

#25 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2941
  • Joined: 30 Nov 2010

Posted Yesterday, 08:44 PM

Gday Ross

 

So, help me out here - are people actually getting bad results?

Some were, but thats not what this thread was about.

Most problems that appeared indicated they got bad calibrations and this affected their guiding, ie showing up as DEC oscillations etc, until they retweaked the aggression to reduce pulse size.

ie the way PHD calibrates doesnt play well with the way IOptron applies pulses.

This can screw up all later calcs.

This thread was merely to investigate what did and what didnt work

and what are the best settings to allow a clean calibrate and good guiding.

 

The last thing that I would expect is that an encoder controlled mount would correct to the extent (time and distance) that PHD or any other guiding software instructs it to do.

You havent looked at the test data put out by AP on the Mach2 testing then

It applies what is asked for when it is asked, and very precisely.

Still only manufacturer supplied data, but it appears to have been done in a real world environment.

Also, the data from the 10micron ( in post 7 ) also showed textbook applications of guides.

The IOptrons appear to do what they want at times.

 

 

I know from experience that you need a log that shows how the end pulse values (if they even are pulses) are calculated.

Dont understand.

You dont need to know anything about the algorithms used by PHD etc to calculate pulse times

The end result is the guide software tells the mount to move for X millisecs at a defined guide rate.

This is easily converted to a set no of arcsecs in a given timeframe.

The guide app "assumes" this happens, but the mount doesnt do it and hence it all gets out of whack, and in some cases, starts to resonate.

 

 

I use very low aggression, 3 to 5 second exposures,

And that is what is needed to ensure requested guides happen before the following guide gets sent.

Again, this thread was to test the effects on calibrating and guiding, to find what works and what doesnt.

 

Andrew Johansen Melbourne Australia


  • psandelle likes this


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