Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

Avalon M-Uno slow guiding response


kens

Recommended Posts

I've noticed my M-Uno is slow to respond to guiding pulses. The recommended PHD2 guide exposure for the mount is 0.5 to 1 second at short focal lengths and 1 to 2 seconds for longer focal lengths. I typically use 1s at 1100mm. Now I noticed when testing a new PHD2 algorithm that even with 1s exposure the display was refreshing much slower - more like 2 seconds. When there are no guide pulses the display refreshes every second as expected so its not a camera bandwidth issue. As soon as a guide pulse is issued the display refresh slows down.

The PHD2 debug log indicated that the mount was not responding to a guide command till well after the guide pulse was supposed to end. Sniffing the COM port showed an absence of status requests to the mount compared to the messages in PHD2. So I suspect maybe a problem in the driver. I've reported it to Luciano but I wanted to see if its just me or is a more common problem.

A possibly related problem is in the StarGo application. When I'm slewing the RA and Dec readings update very slowly, if at all.

 

Link to comment
Share on other sites

I’d love to check this out for you, but the weather here has been so bad for the last three months that I simply haven’t been in the observatory.  This is presumably something which can be tested by manual guiding from PHD?

Link to comment
Share on other sites

I can reproduce the issue with the camera simulator. Just set the exposure time to 1 second, confirm that the screen flickers every second then turn on guiding. The flicker frequency slows down  as soon as there is a guide pulse. And when there are no guide pulses needed it reverts to its normal rate.

Link to comment
Share on other sites

Just a thought, PHD2 has a setting that defines how long after guide command has been issued it should start another guide exposure. It is there to let mount "settle" after being moved as to not affect following guide exposure and calculations of star position if there is a bit of a shake in the mount. I usually set it if I use aggressive guide speed and have a large mass on mount.

Let me see if I can find where it is.

Ah yes, Advanced settings dialog, camera tab, Time lapse field - here you can enter value, so check if by any chance there is something entered there that might cause problems.

Link to comment
Share on other sites

Good thought but my Time-lapse is set to 0ms. Its pretty clear in the debug log that PHD2 polls the mount for its guiding status every 32ms but gets a response from the driver that it is still guiding - often more than 1 second after the request even if it was just a short pulse of a few ms. 

I suspect that the ASCOM driver is not polling the mount each time but is caching its response. I might see if I can install the prototype INDI driver to see what happens. Its open source so I can at least check what the code is doing.

Link to comment
Share on other sites

I just connected up my linear. I have the Stargo version. I tried the camera simulator in PHD2 with exposure set to 1 second. But how do you get it to 'guide'? As it tries to calibrate and just keeps doing west steps. Should it simulate star movement with the calibration pulses?

I tried manual guide with a max pulse of 5000ms. I don't get any refresh of the star image until the guide pulse finishes. I checked my guide log but for some reason its blank. The manual guides are showing up.

Do you need to do something to get the manual guiding logged?

Andy.

Link to comment
Share on other sites

I think I set the calibration for the simulator manually using Tools > Modify Calibration > Enter Calibration Data. The actual values don't matter too much since the simulator doesn't actually move in response to guiding. I copied the values from a real calibration.

It is normal for the camera to wait for guiding to finish. But if the guide pulse is much less than 1 second then there should be little or no delay. I don't think manual guiding shows up in the guide log but it shows in the debug log

 

Link to comment
Share on other sites

36 minutes ago, kens said:

I think I set the calibration for the simulator manually using Tools > Modify Calibration > Enter Calibration Data. The actual values don't matter too much since the simulator doesn't actually move in response to guiding. I copied the values from a real calibration.

It is normal for the camera to wait for guiding to finish. But if the guide pulse is much less than 1 second then there should be little or no delay. I don't think manual guiding shows up in the guide log but it shows in the debug log

 

I did some manual guide pulses of 750ms and can see the entries in the debug log. I've attached my guide log.

Here is part of it. Is it the part I highlighted in Yellow that you're referring to?

21:04:24.301 00.187 90092 scope calibration move dir= 3 dur= 750
21:04:24.301 00.000 90092 Move(3, 750, 0)
21:04:24.301 00.000 90092 Guiding  Dir = 3, Dur = 750
21:04:24.301 00.000 90092 IsGuiding returns 0
21:04:24.317 00.016 98436 worker thread done servicing request
21:04:24.395 00.078 90092 PulseGuide returned control before completion, sleep 674
21:04:25.083 00.688 90092 IsGuiding returns 1
21:04:25.083 00.000 90092 scope still moving after pulse duration time elapsed
21:04:25.114 00.031 90092 IsGuiding returns 1
21:04:25.145 00.031 90092 IsGuiding returns 1
21:04:25.176 00.031 90092 IsGuiding returns 1
21:04:25.208 00.032 90092 IsGuiding returns 1
21:04:25.239 00.031 90092 IsGuiding returns 1
21:04:25.270 00.031 90092 IsGuiding returns 1
21:04:25.301 00.031 90092 IsGuiding returns 1
21:04:25.332 00.031 90092 IsGuiding returns 1
21:04:25.364 00.032 90092 IsGuiding returns 1
21:04:25.395 00.031 90092 IsGuiding returns 1
21:04:25.420 00.025 90092 IsGuiding returns 1
21:04:25.456 00.036 90092 IsGuiding returns 1
21:04:25.487 00.031 90092 IsGuiding returns 1
21:04:25.519 00.032 90092 IsGuiding returns 1
21:04:25.550 00.031 90092 IsGuiding returns 1
21:04:25.581 00.031 90092 IsGuiding returns 1
21:04:25.613 00.032 90092 IsGuiding returns 1
21:04:25.644 00.031 90092 IsGuiding returns 1
21:04:25.675 00.031 90092 IsGuiding returns 1
21:04:25.706 00.031 90092 IsGuiding returns 1
21:04:25.737 00.031 90092 IsGuiding returns 1
21:04:25.769 00.032 90092 IsGuiding returns 1
21:04:25.800 00.031 90092 IsGuiding returns 1
21:04:25.831 00.031 90092 IsGuiding returns 1
21:04:25.862 00.031 90092 IsGuiding returns 1
21:04:25.894 00.032 90092 IsGuiding returns 1
21:04:25.925 00.031 90092 IsGuiding returns 1
21:04:25.956 00.031 90092 IsGuiding returns 1
21:04:25.988 00.032 90092 IsGuiding returns 1
21:04:26.019 00.031 90092 IsGuiding returns 1
21:04:26.050 00.031 90092 IsGuiding returns 1
21:04:26.081 00.031 90092 IsGuiding returns 1
21:04:26.113 00.032 90092 IsGuiding returns 1
21:04:26.144 00.031 90092 IsGuiding returns 1
21:04:26.175 00.031 90092 IsGuiding returns 1
21:04:26.206 00.031 90092 IsGuiding returns 1
21:04:26.238 00.032 90092 IsGuiding returns 1
21:04:26.269 00.031 90092 IsGuiding returns 1
21:04:26.300 00.031 90092 IsGuiding returns 1
21:04:26.331 00.031 90092 IsGuiding returns 1

21:04:26.363 00.032 90092 IsGuiding returns 0
21:04:26.363 00.000 90092 scope move finished after 750 + 1303 ms

21:04:26.363 00.000 90092 Move returns status 0, amount 750

PHD2_DebugLog_2018-04-10_210335.txt

Andy

Link to comment
Share on other sites

Thanks so much Andy. That's what I'm seeing too.

So a 750ms pulse is taking 1300ms longer than it should.What the log says is that PHD2 issued the guide pulse ("worker thread done servicing request"). After about 78ms the mount driver passed control back to PHD2 before it was done with the movement "PulseGuide returned control before completion") which is quite normal. So PHD2 waits for the remainder of the 750ms pulse ("sleep 674") and checks if the mount is done yet. The mount says it is still moving ("IsGuiding returns 1"), so every 30ms or so PHD2 polls the mount and finally the mount says it has finished ("isGuiding returns 0") after more than 2 seconds ("scope move finished after 750 + 1303 ms")Now thats just one axis and guide pulses are sent to each axis in sequence so if they are both delayed by over a second each thats a 2 second+ delay. 

By the way, the reason I came across this is that I'm writing a new guiding algorithm in PHD2. The idea is to allow shorter exposure times but apply a "proper" low pass filter (Butterworth or Bessel) to prevent "chasing the seeing". A shorter exposure will reduce the lag between detecting how far the star has moved and issuing the correction pulse and with luck will give even better results with a mount like the Avalon. What I found is that no matter how much I reduced the exposure time in PHD2 it had no effect.

Over at the INDI forum a couple of folks are developing an Avalon driver so I might have a look at that so see if their driver has the same issues or not.

Link to comment
Share on other sites

3 hours ago, kens said:

The idea is to allow shorter exposure times but apply a "proper" low pass filter (Butterworth or Bessel) to prevent "chasing the seeing".

Interesting!  The theoretically 'optimum' solution to this (and I hesitate to use that over-worked word, but it’s correct in this case) is a Kalman filter, assuming you have a suitable state space model of the system and covariance estimates of the model and measurement noise. For the autoguiding problem, this would seem to be very doable. 

However, I have to admit that it’s hard to beat the robustness as simplicity of a simple linear filter.  You’d probably do nearly as well with a single pole exponential average. 

Link to comment
Share on other sites

To pursue a different track, what about guide speed settings? I only know the EQ6-equipped Avalons for which Avalon recommended a very slow guide speed. I never found this to be effective and ran mine at 0.5x sidereal. I wonder if they've defaulted to a slow guide speed now that they have their own software? Is it adjustable?

Olly

Link to comment
Share on other sites

1 hour ago, ollypenrice said:

To pursue a different track, what about guide speed settings? I only know the EQ6-equipped Avalons for which Avalon recommended a very slow guide speed. I never found this to be effective and ran mine at 0.5x sidereal. I wonder if they've defaulted to a slow guide speed now that they have their own software? Is it adjustable?

Olly

I have the guide speed set to 0.4 for both RA and DEC. Will have a play with the settings to see if there is a difference.

Andy.

Link to comment
Share on other sites

3 hours ago, ollypenrice said:

To pursue a different track, what about guide speed settings? I only know the EQ6-equipped Avalons for which Avalon recommended a very slow guide speed. I never found this to be effective and ran mine at 0.5x sidereal. I wonder if they've defaulted to a slow guide speed now that they have their own software? Is it adjustable?

Olly

They recommend a guide speed of 0.25/0.35 RA/Dec at 1000mm focal length. I found that it was undercorrecting so upped it to 0.8. At the time I wasn't aware of this delay problem but it could explain some of the undercorrection. The StarGo allows guide rate to be adjusted in increments of 0.05

Link to comment
Share on other sites

9 hours ago, kens said:

They recommend a guide speed of 0.25/0.35 RA/Dec at 1000mm focal length. I found that it was undercorrecting so upped it to 0.8. At the time I wasn't aware of this delay problem but it could explain some of the undercorrection. The StarGo allows guide rate to be adjusted in increments of 0.05

I'll experiment a bit with increased guide speeds when I get some clear skies. Up to now I've only used 0.4 and 0.5s guide exposures.

Andy.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.