Hi Barry, thanks very much for your comprehensive reply. I was considering calling out to other Dragonfly users as this thread started with the Pegasus UPB and (once that issue was resolved) got sidetracked by me towards the Dragonfly. Understandably many or most users will only consult this forum when they run into trouble. I am sure there are lots of happy SGP4 users with a Dragonfly, but it could be hard to get their attention. Glad you entered the discussion here.
@Ken or other moderators: feel free to move the Dragonfly related posts in this thread to another thread. Not sure how you guys usually deal with that.
So far I have not had any problems with SGP 3.2 and Dragonfly, but I do with SGP 4.1 and Dragonfly as described in previous posts in this thread. Unfortunately this has now boiled down to some generic problem with SGP 4.1 in my particular setup that is perhaps not even related to the Dragonfly. Ken is helping me figure that out while working on possible solutions in the next beta.
I also use Dragonfly to control my ROR observatory on a rural site. Hardly any internet connection there, so no real remote operation, other than from my house at that site over a LAN that is partially wired and partially wireless. I am very pleased with the setup where SGP controls the entire session and Lunatico products like CloudWatcher and Dragonfly ensure the roof gets closed and the session gets paused when clouds roll in overnight. GNS will wake me up with an alarm when necessary. All in all a great way to make the most of a clear night and still get some hours of sleep without running the risk of rain or other issues damaging the equipment. I am sure you appreciate all of this just as much. Only thing missing is to be able to do this using SGP 4.1.
On my obervatory computer I had to roll back to SGP 3.2, but on a regular laptop I have continued testing SGP 4.1 with and without Dragonfly. This was all daytime testing, mainly to review connectivity and other functionality. While doing that I found the same intermittent connection issues that you describe between SGP and Dragonfly, or actually between the Dragonfly application and the Dragonfly hardware while SGP is apparently trying to connect to the Dragonfly ASCOM driver.
In my case the cables are also almost five years, the network switch is even much older and the wireless access point and router are about a year old. All network connections have proven to be fine and stable though for RDP sessions to the observatory computer and for an IP webcam to keep an eye on the mount from within the house. It is only when using SGP 4.1 with the Dragonfly that I notice these connectivity failures. Without any further proof that does not mean that this is actually caused by SGP 4.1, but you might want to check if the problem disappears when rolling back to SGP 3.2 same as on your remote location.
It is also my preference to first start all other applications that are used by SGP, prior to starting SGP itself. This will eliminate any timing issues in the communication when SGP connects to hardware via the drivers launched by those other applications. This is also advised by Lunatico developer Jaime.
At least you can run a sequence with SGP 4.1 and your Dragonfly, although you do suffer from these disruptive network connections. In my case I can not even start an SGP 4.1 sequence. Surely the rootcause must be related to my particular configuration. It is good to know that there is light at the end of the tunnel as you have shown it is possible to operate a Dragonfly with SGP 4.1 and run a sequence. Many thanks for that confirmation.
Cheers,
Hans