PHD2 doesn't send guide pulses

[Lukas Bauer]

Hi everybody,

I am fairly new to PHD2 and have a pretty complicated problem. I already asked on Astrobin and we haven't been able to find a solution for months.

The problem is, that although I have guiding enabled and everything in the settings correct (checked by experienced Astrobin users) PHD2 doesn't send guide pulses.

My equipment (regarding guiding):

Skywatcher NEQ6 Pro
Guidescope (FL 180mm/AP 50mm)
Touptek planetary camera (used for guiding)

I control my mount with GSS (Green Swamp Server) via ASCOM (Ascom PulseGuiding is activated - not via GSS but when I was using EQMOD I activated it).
--> I switched to GSS because when using EQMOD my mount stopped tracking after setting it to siderial rate after a few seconds, but I still have it installed, although I connect everything with GSS).

The calibration is OK and PHD2 is able to move the mount as it wants, but as soon as it starts guiding it just doesn't send guide pulses.

The guide log from last night is attached below. As well as a 5 min exposure and a 10 min exposure and the screenshots from the guiding assistant (at v1 I touched the telescope by accident - very clearly visible in the graph - , so I ran it a second time).
I also included the backlash graph - what can be seen in there, is my backlash bad, does it need to be adjusted, or is it ok?

One thing I can already tell you is that every time it says MountGuidingEnabled = false, I started the guiding assistant (should be twice I think). When looking at the small text at the top it always says that guiding is enabled - except once in the beginning where I tried what would happen if I turn it off and on again.

I would be so happy if anybody knows, what could be going on here. Any help is appreciated!
Thanks in Advance!

Lukas

[Bruce Waddington]

Well, I guess this is one for the books. :-(  At the point you started the guiding session, you had the Min-Move settings for both RA and Dec set to 20 pixels!  That isn't something PHD2 did to you, it's something you did yourself.  So you were telling PHD2 to not generate guide corrections unless the guide star deflections were over 90 arc-sec (20 pixels).  They never were, so there were no guide corrections generated.  Then you ran the Guiding Assistant twice and both times it recommended that you set the Min-Moves to 0.12 for RA and 0.19 for Dec - note the decimal points.  Each of those recommendations had a button next to it saying 'Apply', but you ignored all of that and continued running with Min-Move values of 20.  That's why you continued to not see any guide corrections.

You may recall from a few hours ago that I sent you a 'welcome' message and I highlighted, in bold, the need for us to see both the guide and debug log files along with a link describing exactly how to upload those files.  But you didn't do that and we don't have all the information we need to help you with any of your other questions.  Please take another look at the information I sent you and invest the time needed to read that material.  A modest investment in time doing that now will save you hours of wasted time going forward.

Regards,

Bruce

[Lukas Bauer]

Oh, thanks for pointing that out to me! I thought of clicking apply but I was unsure if then I am just clicking random buttons in hope to find a solution, so I just let it be. But why is it set to 20 with the default settings (I reinstalled it and there were the same settings).

I will try it tonight and let you know if it works now.

When should you have sent me the welcome-message or where should I find it?

Attached below you can find the updated folder with the debug log.

By the way, as far as I can read from the backlash graph, I have pretty large backlash, so I should probably adjust that too, right?

Thanks for the help!

Lukas

[Bruce Waddington]

The welcome message was sent from me to the e-mail address you used for the PHD2 forum.  E-mail is used for administrative purposes or to discuss things like specialized testing that is directed to you specifically but not to everyone on the forum.  You should check to see if that message was blocked as spam or otherwise lost in the shuffle.  Here is the message content:

Welcome to the forum.  If you are relatively inexperienced with PHD2, please read the User Guide (built-in Help and online files) along with the Best Practices document  The User Guide is updated with every release of PHD2 and contains a great deal of information.  The ‘Search’ facility in the Google forum is also a useful tool because many questions have been asked and answered repeatedly. When you need help, be sure to follow the instructions for uploading your log files to our server – there is little we can do to help you without seeing that data.  Conversations on the forum are conducted in English, so if that is not your primary language, we ask that you use an online translator before posting your question.  This is simply for efficiency – you can translate it once versus every possible responder on the forum having to do it individually.

 https://openphdguiding.org/documentation/

https://openphdguiding.org/phd2-best-practices/

https://openphdguiding.org/getting-help/

 The "Getting Help" link describes the process we want you to use to upload PHD2 log files.  That same link is posted at the top of the home page for the forum.  Guiding is an inherently complex process because of the extremely small tolerances that are needed for imaging.  We do everything we can to simplify the user interface but you really do need to read the available support documentation in order to get an understanding of what's going on. 

When you re-installed PHD2, you probably didn't first un-install the existing version.  Therefore, all the previous settings remain in the Windows registry, which is intentional.  PHD2 is routinely updated and re-installed and no one wants to have to start over with all their settings.  As I said in the original message, you made some sort of mistake that set the Min-Move values to 20 -  there's no way to know when or why that happened, but PHD2 didn't just invent those numbers.  The program starts with reasonable default values for all settings including Min-Move values.

The documentation referenced above contains detailed explanations of the Guiding Assistant along with many other things you need to know in order to get good results.  If the Guiding Assistant makes a recommendation, you should probably apply it unless you have specific, fact-based reasons not to.  That includes your declination backlash measurement.  Yes, 2 seconds is a bit high but that may be an over estimate and is still likely to be handled well by the PHD2 declination backlash compensation feature.  That algorithm is adaptive, so give it a little time to adjust before you try to assess its behavior. Again, all of that is covered in the User Guide.  When you next try to get going, you should run both the Calibration Assistant and Guiding Assistant and try to follow their instructions.

Regards,

Bruce

[Lukas Bauer]

Thanks for sending me the text of the email. I'll look if I find the original email.

I actually did unistall PHD2 before reinstalling it, but maybe the settings still carried over. I don't know but I already changed it to the recommended values.

Should I upload the Log files again, or is it ok if I leave it as it is (the ZIP-File I attached)?

Thanks!

Lukas

[Bruce Waddington]

You don't need to upload the log files again at this point, let's just do it going forward.  The debug log file gets very large for an all-night session and it's too big to be accepted as an attachment on the forum.

Bruce

[Lukas Bauer]

Hi, 

the Min Move setting was actually the thing stopping my mount to function properly, thank you so much!
However, I often got the  "PulseGuidecommand to mount has failed - guiding is likely to beineffective" error. In one of your PDFs which I found through the links you sent me, you wrote that if this doesn't happen frequently I could just ignore it. But I got this pretty much every 10-15min or so. Which means that if I want to take pictures, I have to stopp the mount from tracking and manually start it all over again.

Because I don't think that this something that I should ignore, I uploaded the log files from last night. I hope that we can solve this issue too.
Log files Friday 08.23.2024

Thanks!
Lukas

[Brian Valente]

Lukas

>>>> if this doesn't happen frequently I could just ignore it. 

Is there a reason you are constantly re-calibrating?

every 10-15 minutes is not frequently, I think you can ignore it. You only did a few runs >10 minutes so it's hard to tell how that looks over a longer period of time

Generally it appears your mount is working and guiding.

There are some issues with your mount performance

In the few longer runs, you can see the RA jumps 10-15" which is instant and is unrelated to guiding. Here's an example from your 15 min run:

The source is likely mechanical and does not have a regular period. You should probably investigate this with a user group familiar with your mount, or with Skywatcher directly. Unfortunately these kinds of things can be difficult to track down

Brian

--
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/87fcb996-a496-473d-b747-4011a9a951ffn%40googlegroups.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

[Lukas Bauer]

Well, that doesn't sound so great.

I calibrate it over and over again, because I don't know if it saves the calibration after closing and opening PHD2. But I would assume, that if you are questioning this, that I don't have to re-calibrate it so often?

I am going to continue gathering data over the next few nights, to see if the error really isn't periodic. Or do you think that there is no chance that this error even could be a periodic error?

I'm also going to observe that PulseGuiding alert to see how frequently it really is, but shouldn't this error never appear? Because you would need to constantly check PHD2 if there is no error.

Thanks for the help!

Lukas

[Brian Valente]

Look at the example graph, you can see there isn't a period to it, it happens at random intervals

It would be more helpful if you did a longer run say an hour or so

>>>I'm also going to observe that PulseGuiding alert to see how frequently it really is, but shouldn't this error never appear? Because you would need to constantly check PHD2 if there is no error.

This alert means the mount did not respond to a guidepulse in a reasonable amount of time. There are a lot of reasons for this, it could be a bad cable, problems with connection, etc. 

If it happens every so often, it's not a big deal because it's a blip and won't impact your guiding. However, if you have this issue continuously it's going to impact your results. 

For example, your last guide run if you remove the big RA excursions, you can see RA and Dec are not terribly high and very close together. This indicates to me that your guidepulses are adversely affecting your overall results. You could see if the timestamp for the blips correspond to guidepulses failing, in which case you get two birds with one solution. 

The other thing I just noticed from the run above is your Dec aggression should be 100%. Not sure how it got to 70%

Are you fiddling with any parameters or leaving them at default?

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/feff60c1-01ca-4fbf-8572-4c591d1ffd36n%40googlegroups.com.

[Lukas Bauer]

Yes, I am going to collect more data regarding the guiding problem with longer runs. (maybe even tonight)

But regarding the error message - it doesn't go away once it appears. I can click close as often as I want, but it just keeps appearing until I stop the mount tracking and start tracking and guiding all over again.

I turned my Dec aggresion to 70% because there were times yesterday, when PHD2 wouldn't make Dec corrections (error too small) but then the error got big enough, so it made a correction but it was wayyy too much and just sent the mount anywhere. When I turned it back to 70% the problem dissappeared, so I thought I leave it like that.

Usually I don't fiddle with any parameters, when I don't know what they do, but I think aggression is pretty self-explanatory.

That's also why I don't understand why my min-move setting was set to 20 because I can't remember even touching these settings. But that's solved now doesn't matter anymore.

[Bruce Waddington]

The problem you're having with the "pulse guide" failed messages has two underlying causes.  The first is a bug in the GSServer which has been reported here multiple times and is essentially unique to that driver.  I don't know if anyone has bothered to ask them to fix it or if such requests have simply been ignored.  The mechanism for generating this error message in PHD2 is to apply a generous timeout mechanism to any pulse-guide commands that are issued.  The timeout value is the sum of the length of the guide pulse (e.g. 100ms) + 2 seconds.  In this example, if the driver is reporting that the mount is still executing a guide command after 2.1 seconds, PHD2 times out and shows the message.  Clearly something is wrong at this point.  Since this doesn't happen with every guide pulse, I think there is probably some other underlying problem between the driver and the mount firmware - e.g. a communication hiccup or something - that triggers the whole timeout process.  The bug in the driver is to not recognize the problem and take some sort of sensible recovery action which is what mount drivers are supposed to do.  In contrast, the EQMOD driver - which the GSServer tries to replace - virtually never reported these kinds of problems.  As you have found, the driver basically just stares at the wall, reporting that the mount is still in the process of guiding (and moving) although it almost certainly is not.  The only apparent recovery for you is to stop and restart sidereal tracking.  There is nothing PHD2 can do to work around this.

I can see you still haven't moved past the 20-px MinMove problem, perhaps harboring a suspicion that PHD2 just did this for some unknown reason.  It didn't.  If you have saved all your PHD2 logs since the time preceding all this, you could know exactly when it happened - but I suspect you haven't, most people don't.  One thing you need to remember is that these UI controls are "live":

So if your cat walked on the keyboard or you did a face-plant on the keyboard or you are using a remote access app and unknowingly left the cursor positioned in this area of the screen, unintentional changes can be made.  In that vein, are you intentionally trying to guide in only one Dec direction?  So you really are fiddling around with the guide parameters despite what you've said.  And no, "aggression" isn't really self-explanatory when the aggressiveness level has nothing to do with the problem.  I don't think we're going to get you through all these beginner problems unless you run with the default settings and let us understand what's going on with the mount.  And of course, this is all futile when the driver is just causing you to run un-guided for long stretches of time.

Bruce

[Lukas Bauer]

Ok, thanks. So basically what I'm reading is that I should try EQMOD again and see if I can get it to work properly?

No, I'm not intentionally trying to guide in only one direction, thanks for mentioning that. (In the log files from tonight I already changed it to auto)

Thanks for letting me know that the aggression doesn't have any impact on my problem. I thought of moving it down, so it wouldn't send such a big guide pulse, when detecting a error (not such an "aggressive" guide pulse). Somehow it appears to have solved this problem, but after reading the message from Brian I changed it back to 100%.

So in these log files every setting should be pretty much default, except the ones which the guiding assistant told me to do (min-move and Dec backlash compensation).

https://openphdguiding.org/logs/dl/PHD2_logs_3gGW.zip

Lukas

[Lukas Bauer]

So, I just installed the newest version of EQMOD and tried it out. And I have to say that I am really suprised!

Here is the updated log file:

https://openphdguiding.org/logs/dl/PHD2_logs_2Q8T.zip

It seems like these weird random spikes dissappeared and the guiding didn't even stop once. I could only try 16 min, but I think that this might be the solution.

Maybe I had an older version before which stopped tracking so often, but this time it didn't stop. Everything functioned as it should. 

I'm going to test again when the next clear sky comes, but I really hope that my problem could be fixed.

What I still don't understand is, why my mount has so much backlash in Dec, even after adjusting it (by following a youtube tutorial). I really don't want to tighten the screws any further because they are already pretty thight and I don't want to ruin anything. But that doesn't regard PHD2.

I'm going to tell you after trying it the next time, if it works now or not.

Thank you so much!!!

Lukas

[Brian Valente]

>>> What I still don't understand is, why my mount has so much backlash in Dec, even after adjusting it (by following a youtube tutorial).

It's possible your mount simply has backlash you can't totally remove. That's not uncommon. All GEMs have some amount of backlash, the question is can you guide it out and/or is it objectionable.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/2e889648-ab27-45b8-a889-c6a2e096eddan%40googlegroups.com.

[Lukas Bauer]

Hi, last time I tried to use EQMOD I thought that it would finally work.

But after I tried it again yesterday I was pretty dissappointed. While I don't have the PulseGuiding error with EQMOD it still doesn't work as it should. I very often had those huge spikes in my guide graph which you can clearly see in the guide log. But I 
can't convince myself that this is a mechanical issue because I tried to take 60 exposures - each 30 sec - and got only 39 that were actually usable. Without guiding, I don't have this problem, which means that it is something related to guiding.

Could backlash be the cause of this problem? I don't know how much backlash I have in the Ra axis or how to measure it, but the tightening screws are also pretty thight, so I don't want to tighten them any more.

I also saw that there are a lot of dithering messages in the guide log. This is because I didn't think of dithering before I started the mentioned 60 exposures, so I forgot to turn it of before testing. But normally I want to have dithering enabled, right?

By the way dithering also can't be the reason because you can see these spikes even before the mount started dithering.

https://openphdguiding.org/logs/dl/PHD2_logs_YqAL.zip

I would really appreciate any help!

Lukas

[steve]

Hi
JTOL... We once had similar random spikes which we traced to an air conditioning thermostat. Do you get the spikes if you power from e.g. a car battery?
Worth a try?
Cheers

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/0cae6eab-9c30-444a-9945-f7feb75c632bn%40googlegroups.com.

[Lukas Bauer]

So what you're saying is that if I connect the mount through a normal 230 V socket in the house that the electrical consumers in the house  could be the cause?

I mean there isn't a lot of power usage during the night in the house, but I will try it out.

Thanks!

Lukas

[Lukas Bauer]

But what I just realised is that this can't be the cause because the these spikes would also occur when tracking normally without guiding. But these issues only show themselves when guiding. Without guiding there is no problem with the mount.

Lukas

[Lukas Bauer]

Hello,

Yesterday I put the mount outside and tried it again. I noticed, that when I want to control my camera (Canon) with APT, the problem gets much worse. 

In the included guide logs from yesterday you can see at the 5h guiding, that in the beginning APT was open, and at 0:30 a.m. I closed the program. When trying to take test exposures the error occured pretty much every 2 min (mostly 10-20 sec) before exposure finishes, but it could also just drift away in the middle of an exposure. After closing APT and just letting it run through the night, the error occured much less frequently - sometimes even 20 min without an error.

A second strange thing I noticed way that at 22:20 p.m. yesterday the mount just started slowly slewing to somewhere - I still don't know why it did that.

With the now new found knowledge that without APT it still happens, but much less frequently, I can only assume that this isn't a mechanical issue. As I already said, there is no error without guiding, so the mount is able to function correctly. So it has to be something regarding the electronics and software.

By the way, you can ignore the end of the guidelog - that's when a house was in the way of the object, so obiously there is no star to guide on.

I also saw a dramatic reduction in the reolution of the star preview. This problem was also mentioned on this platform already and he solved this problem with using the 2.6.13 dev1 verision of PHD2. I did that too and this now works again.

https://openphdguiding.org/logs/dl/PHD2_logs_Ej79.zip

Thanks in advance for the help!

Lukas 

[Lukas Bauer]

Hi, I just came back from a night of trying again. Here are the log files:

https://openphdguiding.org/logs/dl/PHD2_logs_4XmD.zip

Here are the different "stages" of the night:

1. The beginning: I ran the calibration as usual and set the mount just a tiny little bit off balance in the Ra axis (east heavy) and planned to stay just in the eastern half of the sky, to reduce Ra backlash, as I found out through a quick research. Immediately after running the calibration assistant I tried guiding with no other software open than PHD2 and EQMOD. That was also my most successful try that night. There were only two spikes for 1.5 hours which I was really happy with. But even these spikes shouldn't be there. However this try was without any camera software open - but to take pictures I need to control the camera.

2. At 22:47 p.m. I slewed the mount via APT to Alpheratz which was quite high in the eastern sky at that time. I left the telescope east heavy, because the first try seemed kind of successful. After slewing to Alpheratz I closed APT and let PHD2 guide for a while - again only EQMOD and PHD2 open. This try also seemed reasonably good, but there were still two huge Ra spikes. 

3. At 23:41 p.m. I additionally just opened APT. I didn't connect anything, I just started APT. And at that point the problem started to only get worse. Even with APT just opened, there were now eight spikes instead of two during a shorter period of time. The telescope was still east heavy.

4. At 0:37 a.m. I connected the mount and camera to APT. I didn't control anything nor take pictures, I just connected it. You can already see that despite the short time period of 30 min there were a lot more spikes than usual, even to a point where it just completely lost the star. The telescope was still east heavy.

5. At 1:12 a.m. I slewed to Hamal, because Alpheratz was getting too high and as I said, I wanted to stay in the eastern half. At this point I started guiding again and additionally started to take exposures with my camera. As you can see, despite the short time period there were now a lot more spikes than before. When PHD2 lost the star completely again I stopped and started guiding again, but that didn't help very much. The telescope was still east heavy.

6. At 2:18 a.m. I slewed to Menkar, because Hamal got too high. I also disconnected the camera from APT and only left the mount connected to APT. Immediately there is a big improvement. Despite two huge Dec spikes it pretty much ran without problems. The telescope was still east heavy.

7. At 3:02 a.m. I additionally connected the camera to APT again, but did not take exposures. And at half the guiding time of No. 6 there were more than double the amount of errors just because I connected the camera to APT. The telescope was still east heavy.

8. At 3:28 a.m. I disconnected the camera, slewed to Aldebaran and put my counterweight down, which made the mount pretty west (!!!)  heavy. To my surprise and against the explanations of the internet my guiding actually was just a bit better than compared to east heavy. There was only a single error. The mount was connected to APT, the camera not.

9. At 3:54 a.m. I reconnected the camera to APT again. As you can see the problem gets worse again.

10. At 4:35 a.m. the sky started to birhgten again, so I figured that I am just going to try to slew to a target, guide and take some quick exposures. I started with 300 sec (5min), but 30 sec before the exposure finished the mount had the error (Guiding started at 4:44, error occured at 4:48 - this pretty much aligns with the said little less than 5 min). I then thought that maybe this was just a coincidence and tried 120 seconds. But again the error started in the second half of the exposure. Then I tried to go even shorter, 60 sec. But again right before the end the error came in. Then I tried 30 sec and the error came again, just right at the beginning. I tried 30 sec again, but the error returned right before the exposure finished again.

All of this trying indicates that this cannot be a mechanical issue, because the extent of the error depends on the used software and connected devices, or if these devices are doing something or not.

Does anybody know what could be the cause of this very strange behaviour?

I appreciate every bit of help!

Lukas

[Bruce Waddington]

I suspect you've got a massive amount of stiction (static resistance) on the Dec axis probably from an attempt to eliminate Dec backlash.  This is causing all kinds of problems:

1) It can't be handled well by the PHD2 Dec backlash compensation algorithm, especially with such large corrections.  The algorithm is really focused on normal backlash.  You should disable the PHD2 dec backlash compensation.

2) The large backlash compensation pulses, couple with the stiffness of the Dec axis, is causing the RA axis to "rock".  Some people refer to this as "cross-talk" between Dec and RA although that just describes the symptom rather than the problem.

All of this behavior is exacerbated by any sort of dithering activity during imaging.  If you disable the Dec backlash compensation, you may find that the picture changes.  You may eliminate many of the big RA excursions and the Dec behavior won't be so unstable.  You will, however, probably continue to see long delays in reversing the Dec axis movement at which point you will need to improve the Dec axis mechanics.

Bruce

[steve]

Hi

Slacken the load on the conical bearing at the base of each axis and ensure that the brass clutch pads are free to move when you release the clutches. Make certain that when balanced you can move each axis with your little finger and that it remains put at any angle.

Cheers and HTH

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/f570dff9-aca6-4e4e-bf6d-d1b90fa00b77n%40googlegroups.com.

[Lukas Bauer]

Hi,

@Bruce Thanks for the fast and really helpful feedback. You are correct, the Dec axis is forced to be out of balance because of the mounting shoe of the telescope, which is really, really short. I have been recently working of building a adapter plate for the Dec axis to be able to balance it out, but I am at a stage where I lack tools and need to wait until I receive the needed parts.
I will disable the Dec backlash compensation. Would you recommend, to upgrade my mount with a Rowan belt mod? Currently it uses gears, which is probably where the huge backlash occurs.

@stev The clutch pads are free to move when releasing the clutch, I also tried to clean them already to improve the clamping effect of the clutch. I hope that I am able to soon finish my mentioned adapter plate then I can finally balance it out.

As soon as I can implement the mentioned improvements I am going to get back to you and let you know if it works.

Thank you all so much!

Lukas

[Lukas Bauer]

Hello,
because of other inconveniences I wasn't able to build the adapter plate yet. But I did try to use another laptop #2 for my guiding. I tested it on Oct. 6th (log files are uploaded). With the other laptop #2 everything worked fine as it should. I then compared the settings and the only setting which was different was the search region for the stars, which actually was lower on the other computer #2 (the one which worked).

With the now compared and therefore same settings I tried the mount again with my laptop #1 (the one which doesn't work) tonight. As already expected it didn't work. The error still showed up. I also tried to reinstall PHD2. But as I had already found out a few months ago, when deinstalling, downloading and reinstalling it again, not all settings were removed completely. For example my profile was still available after reinstalling it. Do you have any idea what I could try next? I suspect it has something to do with how the computer processes the programm. That's why I would also like to know, how to fully remove every data so that PHD2 can't find it again after reinstalling. That's how I could do a manual "hard" reset to start from 0 again.
Log Files: https://openphdguiding.org/logs/dl/PHD2_logs_SH8G.zip

Any help is appreciated!
Thanks in advance!

Lukas

[Lukas Bauer]

Hello, 

I'm reaching out to you because I can hardly believe that nobody has any ideas on what I could try to solve my problem.
Is there really no one here who can offer any guidance or suggestions?

Thanks in advance!

Lukas

[Lenny Shaffer]

The difference is probably the difference between the computers, not the software. Obviously if #2 works OK then whatever is different between it and #1 is your problem. Amount of RAM? Operating system or upgrades to it? The software is working for thousands of people.

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/3770250e-8630-433f-8af1-8c332b7be574n%40googlegroups.com.

--
Murphy's Law of the Week: "Law of cooperatives: In any particular situation, if three things can go wrong, they usually do in sequence, each facilitating the occurrence of the next."

[Lukas Bauer]

But in terms of technical components, my laptop #1 should easily "beat" laptop #2. It is way newer and has better technical specifications than laptop #2. Therefore I cannot figure out what I could change to try and get it running on laptop #1.  Do you have any idea, what laptop configurations I could check?

[Lenny Shaffer]

One thing a lot of people overlook is the power settings under Windows. Things like the USB ports get powered down to save energy therefore your scope hardware and mount isn't going to be able to function correctly. Your computer won't be able to communicate with the ports. Just one main possibility.

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/8087d6fc-3374-4184-b758-3b55d683b3a8n%40googlegroups.com.

[Brian Valente]

Lukas what exactly is the error you are seeing on the new (not working) laptop?

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/8087d6fc-3374-4184-b758-3b55d683b3a8n%40googlegroups.com.

[Lukas Bauer]

I already checked the power settings months ago. They are set correctly - no energy saving is activated.

The error is already described in detail in the last message from me with included log files. But here is the short version:

On my main laptop #1 (new laptop) I can get PHD2 to guide, but there are very frequently pretty large spikes in guiding. Mostly before the end of an exposure of the main camera. This issue does not occur on the old and functioning laptop #2. But I can't use this laptop every time, because it doesn't have enough USB ports and my dad needs it too. I haven't tried it with a USB hub yet, because this can't be teh solution - just taking another laptop because mine doesn't work as it should.