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

AVX Runaway Dec during guiding... Where to look?

  • Please log in to reply
5 replies to this topic

#1 TelescopeGreg

TelescopeGreg

    Gemini

  • -----
  • topic starter
  • Posts: 3,447
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 13 June 2021 - 03:09 PM

Hi folks,

 

My AVX mount has developed a very annoying habit.  While guiding, the Dec axis starts running upwards (north), with PHD2's corrections largely ignored.  The time between these runaway events ranged from 10's of seconds to 7+ minutes.  Before I start digging into the mechanics or the software, where should I look?

 

Here's an example guide graph for the Dec axis from the PHD2's log viewer:

guide graph2-dec.jpeg

 

My polar alignment was very close (way under an arc-minute), so the Dec motor hardly needed to run at all, as seen in the guide graph.  The AVX does not run the Dec motor on its own while tracking, however note the lack of an upward guide pulse at the start of the upward run.  So it appears that the mount electronics decided to run off by itself, suggesting an electrical issue, not one where the software commanded an upward pulse and forgot to stop it.

 

But if this were something electrical having come loose or shorting, that doesn't explain everything.  I'd stop PHD2's guiding, pause a moment, restart looping, select a star, and resume.  That seemed to work for a while, then it'd go AWOL again.  Why would stopping the guiding software have any effect if the issue were purely an electrical one?  Also note that the upward slew is not linear; the downward guiding pulses from PHD2 initially had some effect, so the hand controller is not locked up.

 

The configuration is the AVX mount, connected via USB from the hand controller directly to a Raspberry Pi 4B running Astroberry, with PHD2 doing the guiding.  A few days ago I started having an issue with PHD2 complaining that the guide rate had changed, and that I needed to re-do the calibration, which I did at the start of this session, but the runaway was happening before doing so.  Software was updated before all this started (I was trying - and failed - to get a GPS dongle to help set the time and location), which has me suspicious, but as noted, I don't see how the software could be the cause.  The only little flag waving in the back of my mind is that the target (M5) crossed the Meridian during the session.  But the issue occurred both before and after that crossing, which discounts this theory, and the mount did not flip (which is normal behavior).  But perhaps PHC2's correction pulses were somehow misinterpreted (after being correctly so a minute earlier), commanding more of an excursion instead of a correction?  That kind of fits the shape of the graph.

 

Perhaps someone else can see something I missed.

 

Any ideas?



#2 rgsalinger

rgsalinger

    Cosmos

  • *****
  • Moderators
  • Posts: 9,270
  • Joined: 19 Feb 2007
  • Loc: Carlsbad Ca

Posted 13 June 2021 - 03:19 PM

I would think that the first thing to do is to see if it happens if you set the DEC aggression to 0. That would mean no corrections are being sent to the mount. If the DEC runs away, then suspect the mount. If it does not then suspect something else - like the PHD settings or a cable dragging. 

 

Rgrds-Ross



#3 Achernar

Achernar

    Voyager 1

  • *****
  • Posts: 12,279
  • Joined: 25 Feb 2006
  • Loc: Mobile, Alabama, USA

Posted 13 June 2021 - 03:21 PM

Did you check the cable for the Dec. motor, that it's seated in the connector fully and that it didn't go bad?

 

Taras


  • rgsalinger likes this

#4 TelescopeGreg

TelescopeGreg

    Gemini

  • -----
  • topic starter
  • Posts: 3,447
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 13 June 2021 - 05:15 PM

I would think that the first thing to do is to see if it happens if you set the DEC aggression to 0. That would mean no corrections are being sent to the mount. If the DEC runs away, then suspect the mount. If it does not then suspect something else - like the PHD settings or a cable dragging. 

 

Rgrds-Ross

Interesting thought!  Easy to try.  With an accurate polar alignment, I might even get some imaging done with RA-only.

 

Did you check the cable for the Dec. motor, that it's seated in the connector fully and that it didn't go bad?

 

Taras

That was my first thought, but it seems to be seated fine.  Of course, wiggling it now might have re-seated things, and I have no idea what specific information is sent over that cable to compare it with the observed behavior.  Presumably power and some sort of rotation commands.  Is there logic at the Dec motor, or is it all in the base?  Any sensors?

 

I found a backup image for the Raspberry Pi, taken a few months ago.  First test, assuming it reproduces, will be to swap SD cards and see what happens.



#5 TelescopeGreg

TelescopeGreg

    Gemini

  • -----
  • topic starter
  • Posts: 3,447
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 14 June 2021 - 01:03 PM

An update. 

 

Last night had clear skies, so I set up the scope again.  I had done a few disconnect / connect cycles of the external cable between the main section of the mount and the Dec housing, and also the hand controller for good measure.  Behavior was the same; after a few minutes of guiding, the mount ran off in the North direction.

 

Turned off the Raspberry Pi (but not the mount - it was already on my target), and swapped SD cards with the backup done this past May.  Booted it, got PHD2 running, and told it to guide.  It complained again about the changed guide rate, so I think an issue is that some setting has changed in the mount.  After doing a calibration pass it started guiding, though it also complained that very few steps were needed for the calibration, again pointing to something odd in the mount.

 

BUT, the AWOL slew to the North did NOT reoccur with the May SD card.  So, the bottom line is that it appears to be an issue with the software, or the software combined with some setting in the mount.  Next step is to reset the mount, and recalibrate the May version of the software, to verify that the calibration steps issue is resolved, then swap SD cards again to the June image, calibrate it again, and see if the slewing issue is also resolved.  I'll also compare PHD2 settings between the two SD cards, to see if something changed.

 

If the June version continues to fail, but the May version succeeds, that will nail this to being a software bug introduced with the latest INDI drivers.

 

Best news is that I got another hour of data on M5, enough to finish the image for the month.


  • Sky King likes this

#6 TelescopeGreg

TelescopeGreg

    Gemini

  • -----
  • topic starter
  • Posts: 3,447
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 20 June 2021 - 03:27 PM

Final, perhaps, update.  But, there's still an open puzzle that someone might recognize.

 

Bottom line, I think stuff is working.  Super hot weather combined with the presence of the Moon have "prevented" me from doing any additional imaging, but I have looked at the befores and afters and think I might understand what was going on, though not why it got into that state.  The key parameter seems to be the mount's reported guide speed, which changed by a factor of 100 somewhere along the line.  The open puzzle is that it seems to have been wrong initially (on the system that worked), and got "fixed" after.  Whether that fix was in the software update I did, or a side-effect of some guiding experiments, is probably lost to history.

 

I have compared the four PHD2 configuration screens (global, camera, guiding, algorithms) from the working system back in May, to the non-working one in June, and to what appears to be working now.  All the same.  But looking at the calibration data, there are differences.

 

Below are 4 screen shots of PHD2's calibration screen.  The first is the legacy working system.  Note the RA and Dec guide speeds are about 50x, which seems oddly large.  Bringing up the mount's configuration utility on the hand controller, it says 50%, not 50x.  But this system calibrated very well, as can be seen by the graph on the left. 

 

Original May phd2 calibration data.jpeg

 

After the software update, and after a recalibration, but *before* the mount and configuration resets is the June graph below.  This is the state of things earlier in this thread, where the mount was still running off in the Dec direction, apparently on its own.  Note the guide speeds have dropped by a factor of 100.  Also note the faint string of dots on the Dec line, which I've not seen before.  I remember a lot of fussing about backlash during the calibration, so perhaps that's what it is?  But the puzzle is why the guide speeds changed so dramatically.  I do recall trying to adjust the RA speed over the past few months, in an attempt to improve the RA guiding.  But that didn't help, and I returned the rate back to where it was before.  Never touched Dec, as it's been great.  I think the changes were done on the mount hand controller, and without a recalibration, so this might have confused the software.  But both RA and Dec numbers changed in scale together.

 

June phd2 settings pg 5.jpeg

 

The next experiment, again without resetting the mount or parameters, was to roll back to the backed-up May SD card image, to see if I could simply roll back the clock to a happier time.  What I found was that PDH2 still complained about the guide rates being different, and that I should recalibrate.  That I did, resulting in the calibration data below.  Note the extremely large spacing between the dots; this was accompanied by a complaint of a large step size, but I accepted the calibration and got some good image data that night.  Note here the guide rates are back to 50x, though I had not changed the mount's settings.  (Ignore the Created date here - the Raspberry Pi didn't have an Internet connection at the time, so had no idea what date it was.)

 

May phd2 settings pg 5.jpeg

 

Tabbing forward.  Thinking about the rates and such, I did the factory reset of the mount, and found the reset button on the Advanced tab under PHD2's Guiding configuration screen.  Re-calibrated yet again, and got the last (and current) calibration data.  Again we're back to 0.5x guiding speeds, and a reasonable step size between dots, though not the same as before.  I think this is probably correct, as I calibrated a lot closer to the celestial equator this time.  No faint dots off the end of the Dec line, either.

 

June phd2 calibration data after mount and calibration calculator reset.jpeg

 

 

SO...  where am I?  As noted above, I have only had the one imaging session with the current guiding parameters and calibration.  It wasn't a spectacularly good guiding session, from a numbers perspective, but not unusable.  Along the way I have fussed a bit with the telescope's balance on the mount, and may have lost the sweet spot that I had been running with before.  The mount's bearings are rather stiff, so knowing where balance actually is can be annoyingly vague.

 

If anyone has any idea of what might have led to the 100x difference in interpreting the guiding speeds, I'd appreciate knowing what it was.  Was there a software change in interpreting the mount's guide speed?  If so, where? 

 

As things are currently configured, I believe I have a usable system.  Just need a good night, sans Moon and heat, to verify that.

 

Final random thought, putting on my software engineer hat for the moment, and looping back to the thread's original topic.  Why was the mount running off in the first place?  The only thing I can think of is that with the speed factors so out of whack, perhaps the software ran off the end of some signed integer arithmetic, wrapping a positive number to negative (or vice versa), making a corrective nudge into one that made things worse.  Evidence for this is that there were some initial nudges in the right direction, then an accelerating deviation off the top of the screen, in the presence of "corrections" from PHD2 that should have had the reverse effect.  Seems like there was a sign flip in there.  I haven't looked at the source - not even sure which source to look at, PHD2, INDI, or the hand controller - but it kind of fits.




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