NINA & PHD2 mount disconnect issues

[Frostak]

Hello,

I'm running into issues with controlling my mount through NINA and PHD2. I have a wired USBa connection to Win11 pc. The PC is running SynscanPro app to control the mount (configured in serial mode). Both NINA and PHD connect to the mount, I'm able to control the mount, slew to target, calibrate and start guiding. However after some time (at random from 1-5 minutes usually) both NINA and PHD lose connection to the mount (even if the mount wasn't slewing) and I can no longer control it through these programs, even manual slewing. PHD starts complaining about PulseGuide not working and NINA doesn't even realize the telescope was disconnected (keeps showing info in EQ tab tho not updating, when reslewing it keeps waiting for the mount to send reply etc.). The interesting thing is that I can still control the mount through SynscanPro without issues. If I restart all programs (so far I tried this only with restarting Synscan as well) they are able to connect again but the connection drops like before. So the issue seems to be in communication between NINA/PHD and Synscan, maybe ASCOM driver?

I've tried reinstalling all drivers, changing some com port settings like baud rate. I also tried connecting the mount through wi-fi but even tho Synscan connects properly PHD isn't able to connect to the mount like this for some reason (it can't find the mount or if I set a static IP it complains it doesn't support PulseGuide even though it does). I want to try to rollback ASCOM driver to an older version that is working for some other people.

Has someone run into issues like this or has some idea of what I could try to resolve this issue?

Equipment:
SW Star Adventurer GTi
Win 11 mini PC (decent specs), connected to router through wired connection for Remote Desktop control
USB cable is the one that was included with the mount
All is powered through portable power supply Newsmy N1200P

Software:
ASCOM platform 6.6 SP1
ASCOM driver for Synscan 1.3.1 (want to rollback to 1.3.0)
SynScan Pro app 2.3.8
NINA 2.2
PHD 2.6.11dev4

[scotty38]

I've never used it but I've seen plenty of comments on the NINA discord about Synscan being an issue, if not the issue. Any chance you can try running it all without it?

[Dr_Ju_ju]

Have you ensured that all Device Manager/ Universal Serial Bus controllers / Power Management tab (if available), have the "Allow the computer to turn off this device to save power" unchecked  

[Frostak]

1 hour ago, scotty38 said:

I've never used it but I've seen plenty of comments on the NINA discord about Synscan being an issue, if not the issue. Any chance you can try running it all without it?

I've tried getting EQMOD to work yesterday but no luck with that so far (EQMOD wasn't able to find the mount even when I specified the COM port manually based on device manager). I'm not sure tho if I can get that working with the normal usb cable since a lot of people are talking about some special cables. I'm a beginner so I'm not sure if there is any way to bypass Synscan completely, so I'll be happy for some pointers on how to do that
 

1 hour ago, Dr_Ju_ju said:

Have you ensured that all Device Manager/ Universal Serial Bus controllers / Power Management tab (if available), have the "Allow the computer to turn off this device to save power" unchecked  

I went to power management and disabled Selective usb suspend (or something like that). In device manager I didn't find any such setting on the COM port. Only settings such as baud rate, buffer size etc. were there, but I might be missing something. I'll double check it when I get to the pc. But since Synscan remains connected and PHD disconnects even when actively guiding it doesn't feel like the usb port powering down.
EDIT: Thinking about it now I didn't check if there are any specific settings for the mount in power management, I'll check that thanks.

Edited June 15, 2023 by Frostak

[Frostak]

Just an update, I managed to get the wi-fi working. There should be clear skies today so I'll have an opportunity to test it out.

For anyone who's struggling with similar setup (being in 2 networks as one, one used for remote desktop and other one the wi-fi from the mount), what I did was switch the mount from Access Point into Station mode. Then I connected the mount to the router and assigned a static IP. After that I connected everything using the static IP and finally both NINA and PHD2 managed to connect to the mount  Hopefully this way they won't disconnect anymore~

Edited June 15, 2023 by Frostak

[Frostak]

Unfortunately, even being connected through wi-fi doesn't help the disconnecting issue. ASCOM just disconnects from SynScan after a while. At least now I know the issue isn't in the connection to the mount.

I've tried to connect using EQMOD and GS server (using a com port), but both of them just refuse to connect to the port, as if they just couldn't find the mount on the given port. When I try to connect through SynScan through a serial connection on the same port it connects without any issues. I have also set the baud rate to 115200, but that didn't help at all. At this point I'm at my wits end, no idea what else to try

Edited June 16, 2023 by Frostak

[malc-c]

Just to clarify a few things:

EQMOD & GSS - If using a EQDIR cable plugged in where the handset normally connects to then the resulting COM port needs to be set to 9600.  If your mount is using the latest revision of motor boards and you are using a USB B-A cable, then the Prolific chipset driver needs to be installed and the resulting COM port set to 115200.  All other port settings can be left as default.

The error message is not really helpful (why don't programmers explain the issues in less techy speak) - but my guess is it's not a com port issue, they tend to be time out errors when the application isn't able to get a response to the initial commands to interrogate the control board's firmware.   What is your normal workflow?  - In the past there have been issues where people open EQMOD via the EQASCOM folder, and then having selected the EQMOD HEQ5/6 option form the drop down menu in the other applications such as  CDC / NINA a second instance of EQMOD is launched and this conflicts with the one already running and "hogging" the com port.

Can't comment on the wi-fi option as I've never needed to use that form of connection.

[knobby]

I'd second the 9600 baud rate, I've seen lots of posts where people recommend 115200 but when I had my HEQ5, it was far more stable at 9600.

[Frostak]

4 hours ago, malc-c said:

Just to clarify a few things:

EQMOD & GSS - If using a EQDIR cable plugged in where the handset normally connects to then the resulting COM port needs to be set to 9600.  If your mount is using the latest revision of motor boards and you are using a USB B-A cable, then the Prolific chipset driver needs to be installed and the resulting COM port set to 115200.  All other port settings can be left as default.

The error message is not really helpful (why don't programmers explain the issues in less techy speak) - but my guess is it's not a com port issue, they tend to be time out errors when the application isn't able to get a response to the initial commands to interrogate the control board's firmware.   What is your normal workflow?  - In the past there have been issues where people open EQMOD via the EQASCOM folder, and then having selected the EQMOD HEQ5/6 option form the drop down menu in the other applications such as  CDC / NINA a second instance of EQMOD is launched and this conflicts with the one already running and "hogging" the com port.

Can't comment on the wi-fi option as I've never needed to use that form of connection.

Thanks for the info. I have the USB B-A, so a dedicated usb slot on the mount. However even if I install the prolific chipset driver my pc doesn't use it and uses the standard USB Serial Device driver as seen on the screenshot above. I've tried to manually select driver and force it to use the prolific driver I downloaded from sky-watcher website, but with that I got a warning and the device didn't seem to be working at all.

As for the workflow, I'm still trying to figure it out, this is the first time I'm trying to control everything through a pc, with guiding and all. The disconnect issues I mentioned were happening when using SynScan. With EQMOD I'm not even able to connect. But the workflow I tried is pretty much just this:
 

1.  Connect the mount.
2. Turn on the mount
3. Check which port was assigned to the mount in device manager
4. Start up EQMOD toolbox (I think that was the name) or GS server depending on which one I was trying to set up at that moment
5. Set the COM port and baud rate (in GSS the mount type to Sky Watcher as well)
6. Try to connect

I didn't get past point 6 with EQMOD and GSS, so I didn't even get to NINA or PHD.

EDIT
I've tried to look into the issue of profilic driver not working. I went over to their website and downloaded a tool that can tell what driver is required based on the cable connected to specified COM port. After running it though it said that there is no PL2303 chip. Would that mean that I don't have the correct cable? It was the one that was packed with the mount so maybe if SynScan doesn't need that it just doesn't have the chip needed for EQMOD to work?

Edited June 16, 2023 by Frostak

[malc-c]

Once windows assigns a com port for a device it normally reserves that for the next time it's connected, so you shouldn't need to do all the checking.  Suggested workflow:

• connect the mount to the computer using a standard USB  A-B cable as the mount has the USB to TTL serial convertor built in.  You will only need to set up the baud rate the very first time the mount is connected.
• rather than make a manual connection by launching toolbox, launch EQMOD from within an application such as  Cartes du Ciel or NINA.  So you are only launching on instance of EQMOD

With the driver issue.  When MS was developing  windows 7  it wanted to install as many manufactures drivers as possible under a licencing agreement.  Prolific for whatever reason were excluded so form then on you had to locate and download the driver, with the most common being the 2303 chipset.  I've attached a 64bit version of the 2303 driver that I've used for a USB to serial convertor cable on my old D400 (shutter release cable).  It works fine on my observatory PC which is running windows 10.

I can't comment on any supplied cable  with the mount as I don't know what gets supplied.  Generally any synta mount / synscan box that has a USB type B port only needs a standard run of the mill USB cable - nothing special.  If using that then you will need a 2303 driver as the boards used in these versions of synscan used an ARM based processor and have the 2303 chipset built in, or at least the first generation did.  If they have changed to FTDI chipsets then this will be installed automatically, but device manage will report its using an FTDI driver.

PL2303_64bit_Installer.zip

[Frostak]

Thanks a lot, both for information and the driver. It's nice to know what's going on with the drivers. I'll try it out later today.

As for the SynScan workflow that was causing disconnects. Yesterday I realized that I didn't try running only PHD. So I've used shutter release cable for taking photos, SynScan to slew to target and PHD for guiding. To my surprise PHD didn't disconnect and was guiding the whole night just fine (about 4 hours). So it seems it is NINA after all that is causing the disconnects. One more thing I tried tho was forcing ASCOM SynScan driver to use local ip (127.0.0.1), so that might've helped as well. I'll try older version of NINA that works fine for my friend with the same workflow I tried. I'll still try the EQMOD way as well, as from what I hear it's much more stable than SynScan and see where I go from there. Hopefully I'll manage to get both apps working together soon.

[malc-c]

What you are experiencing seems to be a common issue with NINA having connection issues.  You could also try Green Swamp Server as an alternative to EQMOD and see if you get the same connection issues with NINA, or if last nights experience of running for hours without a dropped connection.  One other possible cause that one or two SGL member discovered is when using some astro cameras as they basically hogged the USB bandwidth whilst capturing which resulted in the mount not being able to report back to EQMOD / GSS when it polled the mount.  Once the planetarium software passes on the instruction to slew to target and the mount has completed the slew and acquired the target, there is very little traffic between EQMOD / GSS and the mount, but it only needs one transmission to be lost and it seems game over with the dreaded lost connection / mount not responding messages 

[Frostak]

Well I finally got EQMOD and GSS to work! The driver you sent wasn't working, but by chance I've come across a post where someone was saying they've had similar issue and it was caused by mount's firmware. So I updated the firmware and the mount connected even without profilic driver

I'm still not sure if this will help with the NINA dropping connection issues, but we'll see when I'll have the next opportunity to go under clear skies. Big thanks to everyone for help!  Even though my fix was something different I've got a lot of insight, thanks again ^^

[malc-c]

Well there is a lesson to be learnt on both sides. I was on the assumption that the firmware was up to date... I should have asked at the beginning if you had done that rather than take it for granted.

[scotty38]

22 hours ago, malc-c said:

Well there is a lesson to be learnt on both sides. I was on the assumption that the firmware was up to date... I should have asked at the beginning if you had done that rather than take it for granted.

Speaking of lessons learned, I learned to keep my mouth shut and not say that I didn't think the issue would be NINA. Mind you I just ignored my own lesson so we know what will happen now 🙂

Edited June 19, 2023 by scotty38