Guiding glitches due to dropped frames

[coatesg]

Hi all,

On my large scope, I use a small Brix PC on scope to run SGP controlling the CCD etc that interfaces with PHD2. PHD2 runs an ASI120MM using the non ASCOM ZWO drivers - this is on an OAG. Both SGP and PHD2 are connected to the Gemini ASCOM driver.

I've started to notice (1) issues with dropped frames - it appears that every so often, the guidecam stalls in producing a new image of ~exposure 3-4sec - these may take 10-15 sec (sometimes longer) to show. If I'm unlucky, this corresponds to a period of more rapid periodic error (2), and the sub trails.

I have USB traffic set to 40 on the camera (I think - though setting this is much trickier using the ZWO driver - had to go into ASCOM, set there, then reconnect...), but the gain is default in PHD (95).

Any ideas on this? Happy to test in the evening again when everything is on and connected - I wondered if the length of exposure and or high gain is at fault? Am I better using the ASCOM driver rather than native in PHD2? (Seems counterintuitive)

Thanks

Graeme

 

(1) I say "just" noticed, I suspect I've got away with this prior to this (eg at high decs)  nothing has really changed on the setup so it may have already been doing this.

(2) PEC training is second job for me after a strip, regrease, rebalance. The PE looks quite repeatable, so should be able to bring this right down to the few arcsec level from +/-8

 

 

[coatesg]

Probably should add - I can use the camera fine in Firecapture, frame rates are fine....

[bottletopburly]

If your computer is using a HDD not a ssd drive then that’s your weak link , invest in a SSD drive they’re so quick , and 4-8gb ram more the merrier . 

[coatesg]

Runs an SSD - don't think memory is an issue either (has 4GB, not sure it's even getting close to swap file usage). And remember it's guiding rather than recording - it shouldn't be dumping streams to SSD, just analysing single frames. 

[Dr_Ju_ju]

Quick thought, but probably wrong,  is PHD being controlled by SGPro ?, if so, could the pauses be intentional for re-focus etc. ??

[coatesg]

It is being controlled that way, but the pauses/glitches are presenting themselves in the middle of an integration (where it shouldn't be focusing! ;-)

I'm going to try a different USB cable and different PC tonight as well, but I'm otherwise out of ideas... ¯\_(ツ)_/¯ ¯\_(ツ)_/¯

[Dr_Ju_ju]

Have you tried the ZWO Ascom camera driver instead of the native driver? its what I use with no problems.

Also have you checked if there are any USB timeout \ sleep settings on the control panel \ devices.

[coatesg]

So I retested this this afternoon using a different laptop. The camera worked fine straight off - which was a little of as it had pretty much given up the first beforehand (recognised but entirely unable to take an image!). 

So, trying it again on the observatory pc, it suddenly started working again. My money is on a slightly poor cable - I'll maybe replace the current one and see how it goes in future. Odd.....

 

[cjdawson]

Cables tend to be the first thing that goes wrong.  Or rather, the connections get corrosion. The cables are normaly flexed a bit as the scope moves about, shouldn't be a problem, but can introduce noise over a long period.

With 4GB ram, it would be worth loading up the windows task manager and keeping an eye on the amount of ram.  8GB will give you plenty of overhead, but 4GB tends to be a little tight these days with Windows 10.   Windows XP or 7 is more forgiving in that respect.

Another thing to try is switching the USB Cables round, so they all plug into different ports.  Shouldn't make a different in theory, but in practice, might produce a more stable order of connection.

[coatesg]

My suspicion is the cable as well - though it doesn't flex (zip ties along the trusses, pc on scope).

RAM is definitely OK- have checked this with taskman.