I think I know what the problem is and I reported it to the developers for StellarMate. In the case of StellarMate, I use the wifi for my remote connection so like you say, the communication becomes more of and issue. The main problem is the image download from the imaging camera. I showed that while this is happening, the guider communication is completely lost and no corrections can occur for 20 seconds or more. There is just two much traffic over the wifi. The solution is to have PHD2 running on the RPi so its control loop does not communicate over the remote connection.

The alternative solution is to have the image capture to the remote RPi and not download it.

The real issue here bandwidth management. There needs to be a quality of service established that puts the image download at the bottom of the list. But anyway, theres no need to have a PHD2 control loop all the way back to the local computer. So we need better, more efficient comms of status and control only. Its great to hear you're working on that!

I operate over wifi with a 16Mbps camera, and it is not just phd2 that has the issue. The built in guider is subject to this pause as well. I get around it by storing the images locally to the scope computer, as mentioned. I then use rsync to bring the images across to my computer in the house where I do any processing (where it is warm!).

One thing of interest, .fits files are very compressible. I use the compression flag on rsync, and I am able to transfer complete batches of files with rsync while normal operations are still under-way. Compression takes cpu power of course, so not sure how it would run on an early Pi, but the newer multi-core machines should be fine. Would it be possible to add an option to compress the stream with gzip or equivalent? This could make everyone's downloads 3x-4x faster on bandwidth limited connections. If stream compression can be achieved, the receiver would uncompress the stream and use the data as normal.

Here is an example file to show compression:

48576960 May 5 2017 Autosave.fits
15541400 May 5 2017 Autosave.fits.gz

Same here using a Canon 550D DSLR. Even using 100mb ethernet cable (40m distance between switches) takes about 30 seconds to download the image.
Using CR2 format takes a bit less, but the problem persists. I am using the same method, download only to server and sync after that. Without this, It has the same impact on internal guider too.

So the work that I did this last weekend should help some with the bandwidth issues. Basically I set it up so that it gets a very small image from PHD2 of just the star it is currently guiding on, so the whole image download is not necessary. More important the image download to the client is not important for the actual guiding, it is just a request and if it doesn't transfer, it doesn't actually affect guiding. PHD2 is handling all the guiding and so whether or not the image gets updated in Ekos is not relevant to the actual guiding. Another point is that if you want, you can use a camera on PHD2 that is not connected to INDI if you like and PHD2 will still send the guiding information for the graphs and the star image back to Ekos for display. I found in my experimenting that using a non-INDI camera and/or a camera not connected to Ekos actually allows for faster guiding since it doesn't have to transfer the file back to the client at all.

I did a whole bunch of PHD2 stuff today which is currently undergoing testing and should make it into KStars soon. i got the RMS error calculated correctly and the error properly scaled because I implemented a function to get the PHD pixel scale. I also further improved the image work I did before to make it more reliable. I did a bunch of other things under the hood that will make it easier to add more stuff later.

Here is a preview of things to come shortly!

In Ekos, after using it for polar alignment, I disconnect the guiding camera and have PHD2 connect to it only. This should prevent any traffic from it over the remote connection.

Thanks @rlancaste! This is great to have PHD2 well integrated with Ekos!

Yes, this is what I mean. That's how I did my tests I posted here. I either removed the guider from the profile in Ekos or I went one step forward and made it not served by INDI at all. The PHD2 star images, graphs, and guiding results I implemented in the last week will come through with or without the guide camera being connected.

This is awesome. A few months ago, I started working on a PHD2 interface for the MGen Autoguider, that would provide correction and frame messages like a regular PHD2 installation would, from indiserver. While I interrupted that activity to cut wood for my backyard obs, I'll follow this up. I had found Ekos a bit difficult to talk with at the time

-Eric

I just added a new feature to the guide module. The drift plot. By the way, even though this is running with PHD2, it works with the internal guider as well.

WOW! Thank you Rob.

If only my mount works tonight. It is back from warranty work, and well... twice last night it went off into la-la-land. Hopefully tonight it will work and I can get to use this.

Cheers!

Note the change is not pushed to GIT yet, but it should be within a short time. Do you pull your KStars version from the GIT repository, do you get it from the PPA, or do you use a Mac or Windows DMG/Installer? It will take longer to get it to the PPA than GIT, and the Mac/Windows installers will probably not be updated for a day or two.