Guide camera is dropping frames
TomH
Hi,
I'd appreciate any suggestions on diagnosing a camera that has started after several months to regularly drop frames during guiding. Not sure if this is a software or hardware issue. Camera is a 290MM mini. Example log is here: https://openphdguiding.org/logs/dl/PHD2_logs_M3fk.zip
Random sets of images fail to show in PHD2 during guiding, anywhere from a single frame to >15s worth of frames. during that time it appears the most recent guide instructions are repeated, meaning that when frames are lost there are often large spikes in pointing error. Is there a way to see in the logs where these drops are occurring? For example, essentially every spike over 3'' error in section 5 of the above log is due to lost frames.
This issue seems to have suddenly started around 3/2 no clear change in equipment. I've tried multiple cables, multiple cable lengths, different laptop USB ports, hub and no hub, different power cable for other equipment, etc. with no clear improvement. I've been unable to reproduce the issue except when outdoors and guiding, meaning the complete setup works fine for long periods when indoors. I even tried putting the camera in the fridge but was unable to provoke an issue.
Any suggestions to see where the drops are occurring in the logs, or to help diagnose what may be going wrong? Would appreciate any help.
mj.w...@gmail.com
TomH
I believe the compensation pulses are a result of the dropped frames, and not the other way around. When frames are dropped there is an increased likelihood of simultaneous spikes in RA and DEC. For example, from about 19:58-20:00 in section 5 there are RA spikes with many coinciding DEC spikes, many of which have a DEC compensation spike immediately after (sometimes over-correcting, especially if more frames are lost during that period). From what I can tell PHD2 continues to receive frames and update the guiding graph during DEC compensation seconds.
My best guesses to the issue at this point are bad PHD2 settings, issues with the guide camera in cold temperatures, or issues with USB connections in cold weather. The guide camera itself seems fine in sustained cold temperatures, and everything worked when temperatures are colder than now. Dropped guiding frames do not coincide with imaging camera frame transfers, so I don't think it's a bandwidth issue. Setting the "use subframes" option did not help things, and that should decrease the required bandwidth to near zero. I also tried the ZWO native driver with the same results.
If anyone has thoughts on the problem in general or the PHD2 settings validity I'd appreciate any input.
bw_msgboard
Hi Tom, I’m not entirely sure what I’m supposed to be looking at here. During the sessions around 20:53 on 3/3, you were getting a bunch of alerts announcing that the pulse guide commands to the mount weren’t being handled correctly. Then, starting at 21:23, you started getting timeouts from the guide camera – simple requests to start an exposure weren’t completing within 15 seconds. Both of these kinds of errors can occur when the USB subsystem is failing in some way. You’re using the EQMOD mount driver which is very stable and is known to handle pulse-guides correctly, so I think this is pretty clearly a hardware problem. In the daytime session at 09:36, you also got another camera timeout, same as before.
I think you’ve mis-analyzed the spikes in session 5, those have nothing to do with lost frames. If PHD2 has a problem getting a frame, it generates an alert message, always. There is a cadence to all these operations, camera exposures and guide commands are not overlapped. So when you issue a giant guide pulse of 5 seconds, there will be a time delay of at least 5 seconds before the next guide camera exposure I actually started. During that time, nothing else will be done with any of the devices, and PHD2 never just “repeat” guide commands. The problem you’re probably seeing is that this 5-sec delay in handling a Dec guide command on top of the elapsed time for the next exposure is allowing the tracking error in RA to build up. The spikes you’re talking about don’t appear to have correlation with lost frames. If you want to know when you’re having these USB-related problems, open the debug log file and do a search for ‘Alert’.
There is a fairly extensive set of suggestions in the PHD2 manual regarding USB problems – it’s in the Trouble-shooting section:
https://openphdguiding.org/manual/?section=Trouble_shooting.htm#Problems-_Camera_Timeouts
Of course you may have done a lot of this. If you think you have temperature-related problems, those are likely to appear with devices like hubs and other connection points rather than with the guide camera itself – although I don’t know how cold it is there. I also think it’s a poor idea to be using Dec backlash compensation when the reversal delay is as long as 5 seconds so I think you should turn that off.
Hope you can track down the problems,
Bruce
--
You received this message because you are subscribed to the Google Groups
"Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/52ce87cd-488b-482e-97fa-709d4add7bd8n%40googlegroups.com.
TomH
I'm assuming that PHD2 shows every frame it collects in the interface. What I'm seeing is a lack of change in the displayed image and guiding graph for several seconds, then a spike appears in the guiding graph and a dec backlash command is sometimes (but not always) visible immediately afterward. The graph updates behave as if time stopped during the lapse in image updates. Only the long lapses >15s seem to show in the log, but there are visible short lapses in the 1-10s range I only know about from watching it live.
Is there an alternative to using the long DEC backlash compensation pulses? I'm trying to avoid guiding in only one direction. GA measures the DEC backlash to be around 6000ms, and without it the guiding generally drifts for about 45-75 seconds before the mount responds to pulses. I have recently updated the guiding rate to 0.7x sidereal from the lower default, but not tested that with a lower backlash compensation time.
Brian Valente
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/3b8f950e-0113-41ad-9cd9-510bda827f01n%40googlegroups.com.
bw_msgboard
See below.
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of TomH
Sent: Sunday, March 07, 2021 12:45
PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding]
Guide camera is dropping frames
Bruce, thanks very much for the input. I have indeed
tried most everything on that PHD2 page related to the camera. I looked back at
several older debug logs and see no camera timeout alerts, despite operating in
colder temperatures (min ~23F in February, ~30F during the session referenced
above). I'll see if moving the dew heater to the guide camera makes a
difference.
I'm assuming that PHD2 shows every frame it collects in the interface. What I'm
seeing is a lack of change in the displayed image and guiding graph for several
seconds, then a spike appears in the guiding graph and a dec backlash command
is sometimes (but not always) visible immediately afterward. The graph updates
behave as if time stopped during the lapse in image updates. Only the long lapses
>15s seem to show in the log, but there are visible short lapses in the
1-10s range I only know about from watching it live.
That’s what I tried to explain. If you’ve issued a mongo 5-second Dec guide pulse, nothing is going to happen in the UI in terms of graph updates or refreshed camera images until that 5-second correction has completed. If the max-guide-pulse parameter has become huge because of trying to use Dec backlash compensation, these huge guide pulses may happen even when there hasn’t been a Dec reversal.
Is there an alternative to using the long DEC backlash compensation pulses? I'm
trying to avoid guiding in only one direction. GA measures the DEC backlash to
be around 6000ms, and without it the guiding generally drifts for about 45-75
seconds before the mount responds to pulses. I have recently updated the
guiding rate to 0.7x sidereal from the lower default,
but not tested that with a lower backlash compensation time.
The time taken to reverse the axis scales inversely with the mount guide speed. So a 6 second reversal delay at 0.5x sidereal would become something close to a 3 second delay with the guide speed set to 1x sidereal. The plain truth is that you really need to improve the mount mechanics to fully solve the problem. If you can’t do that, you should probably spend a little time and learn to use uni-directional Dec guiding.
Bruce
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/3b8f950e-0113-41ad-9cd9-510bda827f01n%40googlegroups.com.