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

RA spikes during guiding with a new iOptron CEM40EC

  • Please log in to reply
61 replies to this topic

#26 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

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

Posted 21 July 2019 - 05:09 PM

Gday Sasho

i agree that calibration by itself shouldn't cause "isolated" excursions as large as the one you show.

That said i note 4 things

1) there is no reasonable length unguided data set to get a datum from

2) In the last trace, virtually ALL guides in RA are now small but in one direction only ( ie you have lots of RA drift )

    The lower "PEMPro generated" plot appears to agree here??

3) The single major excursion in the last PHD log occurred immediately after the RA guider issued an East pulse

     ALL pulses up til that point were small and west

     After the single East Pulse it went troppo, and this lines up with several plots that DerPit has posted recently

    If you look at the first short trace in your PHD log, you will also see that you got a mix of E and W pulses

    and it stayed unstable whilst that was happening.  All good clues.

4) Once more, i used the PEMPro viewer to recreate an approximated raw/unguided curve based on the commands sent.

    This showed relatively massive drift ( 20 arcsec/min )

I then removed the drift to get the second plot ( which is similar to what PHD viewer also shows )

What we see there is what appears to be a normal worm mount with 15arcsec pk-pk PE

( You can also "visually" see the period of the sinusoid matches the worm cycle axis at the top )

ie to all intents and purposes, it looks like the encoder wasnt working

 

Andrew Johansen Melbourne Australia

RAW tracking ( reverse engineered )

Log3 RawRA.jpg

RAW tracking with drift removed

Log3 NormalisedRA.jpg

 

 



#27 Sasho_Panov

Sasho_Panov

    Explorer 1

  • -----
  • topic starter
  • Posts: 68
  • Joined: 19 Aug 2017

Posted 23 July 2019 - 08:44 AM

The night before last night I have carefully setup my new CEM40EC with AsiAir control WiFi device since it is also PHD2 guiding in basic, but much more easier to adjust and to control.

The scope-imaging includes 115mm apo triplet with reducer/flattener (effective focal length = 644 mm), ASI1600MM Pro cooled to -15 Celsius Degrees, OAG with ASI174MM Mini and ZWO EFW with LRGB and SHO filters.

 

The seeing was not very good for imaging with intermittent clouds, moderate wind gusts and Moon illumination 82%.

 

After one-star alignment, I oriented the scope due to East at Dec less than 20 Degrees for guiding calibration (PHD2 calculated step duration 550 ms).

 

This calibration was used for different targets in opposite celestial location and different latitudes, which is important for this topics.

 

Due to the file size restriction, I will submit the PHD2 (AsiAir) guiding log as attachment in a separate post immediately after I post this one.

 

AsiAir sometimes don't record calibration log, but it does the guiding sessions (a total of 4):

1. first was only a minute after the guiding and it shown calm and stable curves, so I stopped it in order to chose the first imaging target;

2. the second last for a continuous 2h 4m 45s during which IC1396 was imaged (located app. RA 21h, Dec app 57 Degrees). The guiding log was depicted in the attached screenshot , as well as the PHD2 Log Viewer screenshot of the entire session. Not only the guiding was very calm with global RMS 0.86" (0.46 pix), but even the clouds (especially the second cloud passage around 1 h of guiding that leads to complete star SNR loss) does not disturbed the guiding :)

A total of 12 lights with exposure duration of 600 seconds each were imaged (4 of each SII, Ha and OIII filters).

3. third guiding session was only 21 s since I forgot to click the guiding flip button since the scope moved to the opposite meridian position.

4. the last session includes 1h 32m 27s uninterrupted guiding for imaging of M16 positioned app at RA 18h, Dec -13 Degrees. A total of 9 600-seconds exposures were captured (3 of each filter).

 

The analysis of images in PixInsight revealed that all 21 exposures of 600 seconds each were with better properties (lower FWHM and Eccentricity values) than I have ever recorded before using the previous GEM (Meade LX85). None of the images shown star trails or other guiding-related problems).

 

I will attach the Ha image (only 3 integrated lights) in a new post just to show the successfulness of the ultimate, real-world test of star size. Please keep in mind that no deconvolution, morphological transformation or any other star-reduction algorithm were included in extremely minimalistic PixInsight processing (only MLT, delinearization by Histogram transformation and Curve transformation were performed for post-processing).

 

In conclusion, apart from proper gudang calibration, I suspect the the choice of 0.5x sideral as a guiding speed was crucial for resolving of the issue with RA spikes that occured previous nights.

 

I would like to thank to all of you that had a patience and time to analyze my submitted logs and screenshot. Without your help, suggestions and sympathy, I was completely disappointed. 

 

Now I am very happy with my new CEM40EC.

 

Best to all,

 

Sasho

 

Attached Thumbnails

  • AsiAIr_log_small.jpg
  • Screenshot_20190721-215713_ASIAIR_small.jpg


#28 Sasho_Panov

Sasho_Panov

    Explorer 1

  • -----
  • topic starter
  • Posts: 68
  • Joined: 19 Aug 2017

Posted 23 July 2019 - 08:45 AM

This is the PHD2 Guiding Log file recorded by AsiAir.

Attached Files



#29 Sasho_Panov

Sasho_Panov

    Explorer 1

  • -----
  • topic starter
  • Posts: 68
  • Joined: 19 Aug 2017

Posted 23 July 2019 - 08:47 AM

And this is the Ha image of M16 (integrated 3 lights of 600 seconds exposure, each) to see the star roundness.

Attached Thumbnails

  • H_ABE.jpg

  • dmdouglass and amoncayo like this

#30 amoncayo

amoncayo

    Explorer 1

  • -----
  • Posts: 87
  • Joined: 22 Aug 2018

Posted 23 July 2019 - 03:35 PM

Good to see that you have sorted things out. I too use 0.5x guiding speed. I've not bothered changing it at all...

 

Al

 

And this is the Ha image of M16 (integrated 3 lights of 600 seconds exposure, each) to see the star roundness.



#31 Sasho_Panov

Sasho_Panov

    Explorer 1

  • -----
  • topic starter
  • Posts: 68
  • Joined: 19 Aug 2017

Posted 23 July 2019 - 04:01 PM

Good to see that you have sorted things out. I too use 0.5x guiding speed. I've not bothered changing it at all...

 

Al

Thanks, Al. The 0.9x guiding speed was probably already set in PHD2 on the laptop. That is why I prefer AsiAir. Much more visible interface and easiness to adjust the setting.

 

Best regards,

Sasho



#32 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

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

Posted 23 July 2019 - 04:52 PM

Gday Sasho

AsiAir sometimes don't record calibration log,

The cal log data is in there but has no header so doesnt always show.

I faked a header for it and it looks OK

Not only the guiding was very calm with global RMS 0.86" (0.46 pix), but even the clouds (especially the second cloud passage around 1 h of guiding that leads to complete star SNR loss) does not disturbed the guiding

Not so sure on that.

Assuming that was one continuous run on a single target, something very weird happened with the drift. It also looks like some underlying SDE ( very small ) is now showing up at a 42x fundamental

but i need to break the log up a bit to investigate that some more.

( This 42x also showed up in yr prev ASIAir log and shows well in the last run )

Have attached a plot of the RA moves only from the second run. Note how the guiding was fighting drift in one direction, then swapped, then swapped then swapped back????????

The PEMPro log that approximately reconstructs raw tracking based on guides sent,  also agrees

No idea re that, but it is what can drop out of long duration logs

ie even tho your guiding is better than it has been on your other mount, i suspect it could be a lot better.

 

As to the last log run after flip, the RA guiding appears to be marginally better on that side

but something horrible has happened to DEC. Need to dig more there

On reconstructing the unguided data using pulses sent, we also see massive drift and large sinusoidal PE,

with a small ( possibly ) SDE component now showing due to the shorter frame rate

 

Andrew Johansen Melbourne Australia

 

Second run showing RA Guide size and directions

Log4 Guides.jpg

 

Second run reconstructed to show "approx" unguided path

Log4 Drift.jpg

 

Last run showing very large DEC excursions and possible SDE freq

Log5 SDE.jpg

 



#33 Sasho_Panov

Sasho_Panov

    Explorer 1

  • -----
  • topic starter
  • Posts: 68
  • Joined: 19 Aug 2017

Posted 23 July 2019 - 05:31 PM

Gday Sasho

The cal log data is in there but has no header so doesnt always show.

I faked a header for it and it looks OK

Not so sure on that.

Assuming that was one continuous run on a single target, something very weird happened with the drift. It also looks like some underlying SDE ( very small ) is now showing up at a 42x fundamental

but i need to break the log up a bit to investigate that some more.

( This 42x also showed up in yr prev ASIAir log and shows well in the last run )

Have attached a plot of the RA moves only from the second run. Note how the guiding was fighting drift in one direction, then swapped, then swapped then swapped back????????

The PEMPro log that approximately reconstructs raw tracking based on guides sent,  also agrees

No idea re that, but it is what can drop out of long duration logs

ie even tho your guiding is better than it has been on your other mount, i suspect it could be a lot better.

 

As to the last log run after flip, the RA guiding appears to be marginally better on that side

but something horrible has happened to DEC. Need to dig more there

On reconstructing the unguided data using pulses sent, we also see massive drift and large sinusoidal PE,

with a small ( possibly ) SDE component now showing due to the shorter frame rate

 

Andrew Johansen Melbourne Australia

 

Second run showing RA Guide size and directions

attachicon.gif Log4 Guides.jpg

 

Second run reconstructed to show "approx" unguided path

attachicon.gif Log4 Drift.jpg

 

Last run showing very large DEC excursions and possible SDE freq

attachicon.gif Log5 SDE.jpg

Hi Andrew,

 

Thank you very much for your time and effort. Could you please explain to me what this analysis means?

 

Should I change the mount firmware with different version which is beta also, but one of the posters here on CN (Ben) concluded that leads to even better guiding curves than the present one?

 

Best regards,

 

Sasho



#34 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

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

Posted 23 July 2019 - 05:50 PM

Gday Sasho

Could you please explain to me what this analysis means?

I have absolutely no idea how drift could change like that, or if it is really drift, or just the mount not handling guiding.

An encoder mount should only require a few small nudges in RA every now and then to keep on track.

You were guiding aggressively at 3 seconds here and i would not have expected the constant unidirectional nudges

Once more, i would alsk you try and get an unguided baseline

ie get say 30mins ( or longer ) where no guides are sent, and then start guiding.

If the plot shows "reasonably" steady tracking until you start guiding,

it would line up with what others are seeing with the 60EC

 

Andrew Johansen Melbourne Australia



#35 Sasho_Panov

Sasho_Panov

    Explorer 1

  • -----
  • topic starter
  • Posts: 68
  • Joined: 19 Aug 2017

Posted 23 July 2019 - 06:00 PM

Gday Sasho

I have absolutely no idea how drift could change like that, or if it is really drift, or just the mount not handling guiding.

An encoder mount should only require a few small nudges in RA every now and then to keep on track.

You were guiding aggressively at 3 seconds here and i would not have expected the constant unidirectional nudges

Once more, i would alsk you try and get an unguided baseline

ie get say 30mins ( or longer ) where no guides are sent, and then start guiding.

If the plot shows "reasonably" steady tracking until you start guiding,

it would line up with what others are seeing with the 60EC

 

Andrew Johansen Melbourne Australia

Thank you very much once again, Andrew. I will try to record longer unguided runs, but I am not sure how. (Using Guiding Assistant in PHD2, perhaps).

 

The weather is really cloudy tonight, though.

 

Please, if possible, tell me that it is not so bad as it looks. I am very emotional about this issue. It took me months to get this mount and it is very complicated to return it back, if necessary. After all, I am not sure that this will not happened with other CEM40, considering such or similar guiding-related problems are already described by other new owners of this, as well as of CEM60EC mounts. I really need some hope that those issues could get better with future firmware updates or that are acceptable with this price class, if not too much to ask. Please forgive me if I am boring to you.

 

Thanks in advance,

 

Sasho


Edited by Sasho_Panov, 23 July 2019 - 06:01 PM.


#36 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

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

Posted 23 July 2019 - 06:24 PM

Gday Sasho

 

I will try to record longer unguided runs, but I am not sure how.

You can turn off sending guides to the mount via a setting in the brain

( The "Enable Mount Guiding" checkbox in the "Guiding" tab  )

Simply set that to unchecked and the system will still measure and log the errors but wont send corrections

So maybe start guiding as per normal for say 30 mins to get a guided baseline.

Then ( without using Stop etc ), go to the brain and uncheck the "Enable Guiding" box and leave it for another 30mins

That way you will get guided and unguided in one plot.

I suspect that within about 10 secs of the last guide, the RA will settle into a nice smooth trace with a little drift.

 

 

Please, if possible, tell me that it is not so bad as it looks.

As you noted, your results are already way better than your prev mount ;-),

but i suspect ( as per before ), they could be even better with a lot less guiding required.

This appears to be a problem that is also being discussed in detail on the parallel 60EC thread.

ie when unguided, the mounts appear to track very well, but do have a bit of RA drift so need occasional guides

but finding a suitable way to guide is creating problems.

The manufacturer is supposedly aware of the problem so should be able to fix it.

 

Please forgive me if I am boring to you.

Not at all. These encoders ( and their implementation ) are a new beast to most people, so its a learning exercise for many.

The fact most mounts run very well unguided means it can be done. As such, i suspect it will be down to

a firmware tweak to allow guiding to work seamlessly.

 

Andrew Johansen Melbourne Australia



#37 Sasho_Panov

Sasho_Panov

    Explorer 1

  • -----
  • topic starter
  • Posts: 68
  • Joined: 19 Aug 2017

Posted 23 July 2019 - 06:37 PM

Gday Sasho

You can turn off sending guides to the mount via a setting in the brain

( The "Enable Mount Guiding" checkbox in the "Guiding" tab  )

Simply set that to unchecked and the system will still measure and log the errors but wont send corrections

So maybe start guiding as per normal for say 30 mins to get a guided baseline.

Then ( without using Stop etc ), go to the brain and uncheck the "Enable Guiding" box and leave it for another 30mins

That way you will get guided and unguided in one plot.

I suspect that within about 10 secs of the last guide, the RA will settle into a nice smooth trace with a little drift.

 

As you noted, your results are already way better than your prev mount ;-),

but i suspect ( as per before ), they could be even better with a lot less guiding required.

This appears to be a problem that is also being discussed in detail on the parallel 60EC thread.

ie when unguided, the mounts appear to track very well, but do have a bit of RA drift so need occasional guides

but finding a suitable way to guide is creating problems.

The manufacturer is supposedly aware of the problem so should be able to fix it.

Not at all. These encoders ( and their implementation ) are a new beast to most people, so its a learning exercise for many.

The fact most mounts run very well unguided means it can be done. As such, i suspect it will be down to

a firmware tweak to allow guiding to work seamlessly.

 

Andrew Johansen Melbourne Australia

Thank you, Andrew. Now it is much more clear to me and I am not so anxious about that. I hope tomorrow evening, the weather will permit me to do unguided (30 min) and then guided recording of PHD2 curve as you described to me.

 

Have a good day. 

 

All the best,

 

Sasho



#38 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

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

Posted 23 July 2019 - 07:10 PM

Gday Sasho

 

I hope tomorrow evening, the weather will permit me to do unguided (30 min) and then guided recording

No, do guided first then disable guiding

That way, we can see how long it takes from the last guide for it to settle

 

Andrew Johansen Melbourne Australia



#39 Sasho_Panov

Sasho_Panov

    Explorer 1

  • -----
  • topic starter
  • Posts: 68
  • Joined: 19 Aug 2017

Posted 23 July 2019 - 07:23 PM

Gday Sasho

No, do guided first then disable guiding

That way, we can see how long it takes from the last guide for it to settle

 

Andrew Johansen Melbourne Australia

OK, I will do that hopefully tomorrow evening. Best regards, Sasho



#40 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

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

Posted 23 July 2019 - 07:41 PM

Gday Sasho

No urgency

Have attached a plot for a ZEQ25 that was done using this technique, to show how you can get guided and unguided data in one plot.

That gives you a pretty good idea of how it behaves in both modes at a common location

 

Andrew Johansen Melbourne Australia

ZEQ25 Guided_Unguided.jpg



#41 spokeshave

spokeshave

    Vanguard

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

Posted 25 July 2019 - 07:00 AM

I have absolutely no idea how drift could change like that, or if it is really drift, or just the mount not handling guiding.

I think that iOptron employs some filtering logic for RA pulses for their EC mounts. Not long ago, I was a bit alarmed at similar behavior in my CEM120EC mount. While guiding was very good - typically less than 0.30" RMS in RA, it seemed like PHD2 was continually correcting in one direction in RA and the mount did not appear to be responding. PHD2 was telling me that it was calculating RA drift of about 0.2"/s. So, I did what you are suggesting - I disabled guiding in RA and looked for 0.2"/s of drift in RA - which should become readily apparent in just a few seconds. The drift never materialized. In fact, the RA trace continued just as it had when guiding was enabled. That could only mean one thing - the mount is filtering RA guide pulses and opting not to execute some of the commanded moves. This would give PHD2 the illusion that there was drift in RA because it would appear that the commanded pulses were not adequately correcting RA. The odd thing was that any larger excursions in RA - such as from dithering or wind - are met with instant response by the mount to the guide pulses. This seems to clearly indicate to me that the mount is intentionally ignoring some pulses and permitting others. So your suggested test is a good one. It will easily show whether the calculated RA drift is real or not.

 

As already mentioned, I suspect that iOptron applies some kind of logic to commanded guide pulses to determine whether to actually permit them being executed. My guess is that this is probably to try to avoid conflict between an encoder-driven correction and a guider-driven one. For my mount at least, I have concluded that iOptron know what they are doing because the mount's performance is excellent. I have since concluded that I can safely ignore those repeated guide pulses and just focus on actual guiding performance. In fact, I tend to keep the "corrections" box unchecked in PHD2. 

 

Tim



#42 Swordfishy

Swordfishy

    Explorer 1

  • *****
  • Posts: 61
  • Joined: 08 Feb 2019
  • Loc: Miami, FL

Posted 25 July 2019 - 08:10 AM

CGem user here... Experiencing the same exact issue. Everything runs smooth and then BAM, an RA excursion way out of the graph.

#43 gotak

gotak

    Vanguard

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

Posted 25 July 2019 - 08:13 AM

I think that iOptron employs some filtering logic for RA pulses for their EC mounts. Not long ago, I was a bit alarmed at similar behavior in my CEM120EC mount. While guiding was very good - typically less than 0.30" RMS in RA, it seemed like PHD2 was continually correcting in one direction in RA and the mount did not appear to be responding. PHD2 was telling me that it was calculating RA drift of about 0.2"/s. So, I did what you are suggesting - I disabled guiding in RA and looked for 0.2"/s of drift in RA - which should become readily apparent in just a few seconds. The drift never materialized. In fact, the RA trace continued just as it had when guiding was enabled. That could only mean one thing - the mount is filtering RA guide pulses and opting not to execute some of the commanded moves. This would give PHD2 the illusion that there was drift in RA because it would appear that the commanded pulses were not adequately correcting RA. The odd thing was that any larger excursions in RA - such as from dithering or wind - are met with instant response by the mount to the guide pulses. This seems to clearly indicate to me that the mount is intentionally ignoring some pulses and permitting others. So your suggested test is a good one. It will easily show whether the calculated RA drift is real or not.

As already mentioned, I suspect that iOptron applies some kind of logic to commanded guide pulses to determine whether to actually permit them being executed. My guess is that this is probably to try to avoid conflict between an encoder-driven correction and a guider-driven one. For my mount at least, I have concluded that iOptron know what they are doing because the mount's performance is excellent. I have since concluded that I can safely ignore those repeated guide pulses and just focus on actual guiding performance. In fact, I tend to keep the "corrections" box unchecked in PHD2.

Tim


Which FW was that which shows this?

It felt similar to what i saw with the new beta on cem60ec.

#44 gotak

gotak

    Vanguard

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

Posted 25 July 2019 - 08:13 AM

I think that iOptron employs some filtering logic for RA pulses for their EC mounts. Not long ago, I was a bit alarmed at similar behavior in my CEM120EC mount. While guiding was very good - typically less than 0.30" RMS in RA, it seemed like PHD2 was continually correcting in one direction in RA and the mount did not appear to be responding. PHD2 was telling me that it was calculating RA drift of about 0.2"/s. So, I did what you are suggesting - I disabled guiding in RA and looked for 0.2"/s of drift in RA - which should become readily apparent in just a few seconds. The drift never materialized. In fact, the RA trace continued just as it had when guiding was enabled. That could only mean one thing - the mount is filtering RA guide pulses and opting not to execute some of the commanded moves. This would give PHD2 the illusion that there was drift in RA because it would appear that the commanded pulses were not adequately correcting RA. The odd thing was that any larger excursions in RA - such as from dithering or wind - are met with instant response by the mount to the guide pulses. This seems to clearly indicate to me that the mount is intentionally ignoring some pulses and permitting others. So your suggested test is a good one. It will easily show whether the calculated RA drift is real or not.

As already mentioned, I suspect that iOptron applies some kind of logic to commanded guide pulses to determine whether to actually permit them being executed. My guess is that this is probably to try to avoid conflict between an encoder-driven correction and a guider-driven one. For my mount at least, I have concluded that iOptron know what they are doing because the mount's performance is excellent. I have since concluded that I can safely ignore those repeated guide pulses and just focus on actual guiding performance. In fact, I tend to keep the "corrections" box unchecked in PHD2.

Tim


Which FW was that which shows this?

It felt similar to what i saw with the new beta on cem60ec.

#45 spokeshave

spokeshave

    Vanguard

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

Posted 25 July 2019 - 08:18 AM

I'll have to get back to you when I can see what firmware I have loaded.

 

Tim



#46 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

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

Posted 25 July 2019 - 05:32 PM

Gday Tim

In fact, the RA trace continued just as it had when guiding was enabled. That could only mean one thing - the mount is filtering RA guide pulses and opting not to execute some of the commanded moves.

I agree it is filtering/averaging/smoothing in some way, but what intrigued me was when i use the PEMPro or PHD viewers to reverse engineer the "theoretical" unguided performance, i see a massive drift.

When you break the traces apart and normalise the drift out of the data, it turned into a near perfect sinewave with a period equal to the worm. ie maybe, instead of the mount ignoring some pulses, maybe the guide freq is effectively disabling the encoder. You now have a mount with a lot of drift and the normal worm PE superimposed.

The guiding then fights this, and the drift makes it a unidirectional fight.

Where this theory comes a cropper is the data above where the drift changed direction several times for no apparent reason. Very intriguing.

just for info re

 

While guiding was very good - typically less than 0.30" RMS in RA, it seemed like PHD2 was continually correcting in one direction in RA and the mount did not appear to be responding.

Do you have those log files???

If so, can you use the PEMPro or PHD viewers to reconstruct what an unguided plot "would have" looked like.

If ( after drift removal ) you get a sinusoidal error that is at the worm freq of the 120EC ( ie it will be different to the 40EC ), then it might indicate the encoder is essentially not being used ( or resynching quick enough after a guide ) and as such,you are essentially guiding a std worm mount with a lot of RA drift???

Dunno

My current theory is there is some averaging/smoothing code in there to suppress SDE and guiding upsets it, which is why in a lot of the plots of DerPits 60EC, when it chucked a wobbly, the error ripple matched the SDE freq. Only thing is it didnt happen all the time.

Very intriguing

 

Andrew Johansen Melbourne Australia



#47 spokeshave

spokeshave

    Vanguard

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

Posted 25 July 2019 - 06:39 PM

Gday Tim
I agree it is filtering/averaging/smoothing in some way, but what intrigued me was when i use the PEMPro or PHD viewers to reverse engineer the "theoretical" unguided performance, i see a massive drift.

What I'm saying is that the drift doesn't actually exist - at least on my mount. There is essentially no difference in RA tracking performance with guiding disabled versus enabled - which is as it should be with an encoder mount with very good polar alignment. In fact, I only guide in RA to correct for refraction and to facilitate dithering.
 
When PHD2 and PEMPro reverse engineer the "theoretical" unguided performance, they assume that a guide pulse is actually performed by the mount. When PHD2 sends a guide pulse east and the star doesn't move, it assumes that the mount moved west at the same time. So it infers an westward drift that counters the east pulse. On my mount, that inference can easily be proven incorrect by disabling guiding and seeing that the inferred drift isn't real. 
 

If ( after drift removal ) you get a sinusoidal error that is at the worm freq of the 120EC ( ie it will be different to the 40EC ), then it might indicate the encoder is essentially not being used ( or resynching quick enough after a guide ) and as such,you are essentially guiding a std worm mount with a lot of RA drift???



That's not happening, at least on my mount. The encoder is working perfectly and there is no real RA drift. That's my point. The inferred drift appears to be based on the false assumption that every guide pulse is accepted and the mount is drifting in RA to oppose the pulses. The only explanation that fits my observations is that those RA pulses that don't seem to be moving the trace really aren't doing anything, at least some of the time. That implies that the mount firmware is making decisions about which guide pulses to permit and which ones not.

I'll try to get some logs, but I will also add that the most recent firmware I installed a couple of weeks ago doesn't seem to be displaying the behavior nearly as much. That implies to me that the firmware routine that I postulate is reconciling guide pulses and encoder corrections has been somewhat refined.

Tim

#48 OzAndrewJ

OzAndrewJ

    Mercury-Atlas

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

Posted 25 July 2019 - 07:07 PM

Gday Tim

What I'm saying is that the drift doesn't actually exist

I agree that unguided, there appears to be very little drift on most plots, as the encoder can account for any underlying drift and PE at the same time. Currently, you cannot disable the encoders and use dead reckoning driving of the stepper, as that would be the acid test as to how the mount worked with no encoder feedback.

When PHD2 and PEMPro reverse engineer the "theoretical" unguided performance, they assume that a guide pulse is actually performed by the mount.

Agreed, and as such it is taken with a grain of salt at the detailed level.

What i am thinking is that if guided too frequently, the system essentially reverts to dead reckoning driving of the steppers. In this scenario, there may actually be very bad drift as well as PE. PHD sees this and tries to account for it, but as soon as you stop guiding, the effect goes away and the system stabbilises, so you will never "see" it in the measured data.

The main reason i am thinking this way at present is that if the mount simply ignored pulses from PHD2

why, when reverse engineered, do we get a very repeatable sine wave that perfectly matches the worm period.????? ( ref post 26 for one example )

Thats also why i was interested if reverse engineering one of yr old logs (which had unidirectional guiding) also showed it, but at your worm freq.

 

Andrew Johansen Melbourne Australia



#49 dapalmer

dapalmer

    Mariner 2

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

Posted 25 July 2019 - 07:26 PM

What I'm saying is that the drift doesn't actually exist - at least on my mount. There is essentially no difference in RA tracking performance with guiding disabled versus enabled - which is as it should be with an encoder mount with very good polar alignment. In fact, I only guide in RA to correct for refraction and to facilitate dithering.
 
When PHD2 and PEMPro reverse engineer the "theoretical" unguided performance, they assume that a guide pulse is actually performed by the mount. When PHD2 sends a guide pulse east and the star doesn't move, it assumes that the mount moved west at the same time. So it infers an westward drift that counters the east pulse. On my mount, that inference can easily be proven incorrect by disabling guiding and seeing that the inferred drift isn't real. 
 


That's not happening, at least on my mount. The encoder is working perfectly and there is no real RA drift. That's my point. The inferred drift appears to be based on the false assumption that every guide pulse is accepted and the mount is drifting in RA to oppose the pulses. The only explanation that fits my observations is that those RA pulses that don't seem to be moving the trace really aren't doing anything, at least some of the time. That implies that the mount firmware is making decisions about which guide pulses to permit and which ones not.

I'll try to get some logs, but I will also add that the most recent firmware I installed a couple of weeks ago doesn't seem to be displaying the behavior nearly as much. That implies to me that the firmware routine that I postulate is reconciling guide pulses and encoder corrections has been somewhat refined.

Tim

It almost sounds like maybe the mount was planning to move the mount anyway when PHD gave the command to move, so when it recognized a similar move - instead of moving twice as much it just let the encoder do its job and cancelled the PHD request. This could be a good thing to prevent the guiding from fighting the encoders if implemented properly.  Maybe I am misinterpreting your comments. Certainly I have no experience, only interest at this point.



#50 spokeshave

spokeshave

    Vanguard

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

Posted 25 July 2019 - 07:49 PM

It almost sounds like maybe the mount was planning to move the mount anyway when PHD gave the command to move, so when it recognized a similar move - instead of moving twice as much it just let the encoder do its job and cancelled the PHD request. This could be a good thing to prevent the guiding from fighting the encoders if implemented properly.  Maybe I am misinterpreting your comments. Certainly I have no experience, only interest at this point.


That is exactly what I'm saying. I think that there is logic in the mount firmware that makes decisions about when a guider correction is permitted or rejected so as not to have conflict - as you describe - with the encoder action.

I just looked at the PHD2 logs that I have and I don't see the behavior that I was describing earlier, so it looks like the newer firmware doesn't display that behavior.

Tim


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