Welcome, Guest
Username: Password: Remember me
08 Apr 2018
INDI development team is happy to announce the release of INDI Library v1.7.0. This new exciting release builds on the maturity of INDI Library and comes with many new supported devices and fixes for existing drivers.
Read More...

TOPIC: Working on PHD2 support

Working on PHD2 support 7 months 4 days ago #21544

  • rlancaste
  • rlancaste's Avatar Topic Author
  • Away
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 1246
  • Karma: 12
  • Thank you received: 322
About 2 weeks ago, I found that using PHD2 running on my Raspberry Pi was giving better results than trying to guide over the network using Ekos. I think a number of people probably do that already as I have seen it in the forums quite a bit. The reason it gives better results is probably in large part due to network communication speed, but I don't know exactly. Regardless, there is support in Ekos for controlling PHD2 remotely during your imaging session. Anotherwords, the remote computer (the PI) is running PHD2, and Ekos running on the local computer is giving it some commands like telling it to start guiding, dither, connect devices, etc. Ekos already supports this.

The biggest drawback to this method was that there was reduced information available in Ekos from the external program. I decided to tackle this problem. A few days ago, I found that Ekos was already getting enough information to display the guide errors and the graphs, it just needed some minor correction to get the information displayed. I worked with Jasem to correct this issue. On Friday, I decided to see if I could get the guide star image PHD2 reports to display in Ekos, since it would be nice to be able to monitor the star it is trying to guide on. After a number of hours over the last couple of days, I finally got that mostly working. There are just a couple of other PHD2 items that I plan to work on the next couple of days, and then PHD2 remote support should be a lot more useful!

Hopefully this helps more people than just me. Just a couple of more days and I should be able to work out the other issues.

Here is what I have working so far:

Attachments:
The following user(s) said Thank You: knro, Casaro68, jpaana, maudy, xsnrg

Please Log in or Create an account to join the conversation.

Working on PHD2 support 7 months 4 days ago #21551

  • jpaana
  • jpaana's Avatar
  • Away
  • Senior Boarder
  • Senior Boarder
  • Posts: 78
  • Karma: 1
  • Thank you received: 27
I use PHD2 with Ekos as well, though both run on the observatory computer on the same screen so I haven't missed the graphs in Ekos too much :) Anyway, one thing I've meant to dig into is that after dithering Ekos sometimes seems to start exposure too early so I'm not sure if it handles settle end event correctly from PHD2. I've worked this around by using long enough fixed delay, but that's not really solution either...

Please Log in or Create an account to join the conversation.

Working on PHD2 support 7 months 4 days ago #21553

  • gbeaton
  • gbeaton's Avatar
  • Away
  • Gold Boarder
  • Gold Boarder
  • Posts: 232
  • Karma: 1
  • Thank you received: 22
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!

Please Log in or Create an account to join the conversation.

Working on PHD2 support 7 months 4 days ago #21554

  • xsnrg
  • xsnrg's Avatar
  • Offline
  • Gold Boarder
  • Gold Boarder
  • Posts: 219
  • Karma: 2
  • Thank you received: 40
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
The following user(s) said Thank You: gbeaton

Please Log in or Create an account to join the conversation.

Working on PHD2 support 7 months 4 days ago #21555

  • nmac
  • nmac's Avatar
  • Offline
  • Gold Boarder
  • Gold Boarder
  • Posts: 309
  • Karma: 2
  • Thank you received: 62
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.

Please Log in or Create an account to join the conversation.

(PT) SC@ROS Observatory
x86_64 Atom PC / TS 6" F4 Newtonian / Canon 550D / GPU CC / Datyson T7M / Arduino Moonlite DC Clone- HEQ5 Pro
x86_64 C2D / Explore Scientific ES80480 / Atik 420m / ES FF 2" / ASI120MM - Arduino Moonlite DC Clone - Vixen GPD2
www.flickr.com/photos/139335144@N03/
Last Edit: by nmac.

Working on PHD2 support 7 months 4 days ago #21564

  • rlancaste
  • rlancaste's Avatar Topic Author
  • Away
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 1246
  • Karma: 12
  • Thank you received: 322
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.

Please Log in or Create an account to join the conversation.

Working on PHD2 support 7 months 3 days ago #21578

  • rlancaste
  • rlancaste's Avatar Topic Author
  • Away
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 1246
  • Karma: 12
  • Thank you received: 322
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!

Attachments:
The following user(s) said Thank You: knro, Casaro68, jpaana, gbeaton, maudy

Please Log in or Create an account to join the conversation.

Working on PHD2 support 7 months 3 days ago #21581

  • gbeaton
  • gbeaton's Avatar
  • Away
  • Gold Boarder
  • Gold Boarder
  • Posts: 232
  • Karma: 1
  • Thank you received: 22

rlancaste wrote: 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.


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.

Please Log in or Create an account to join the conversation.

Working on PHD2 support 7 months 3 days ago #21582

  • gbeaton
  • gbeaton's Avatar
  • Away
  • Gold Boarder
  • Gold Boarder
  • Posts: 232
  • Karma: 1
  • Thank you received: 22

rlancaste wrote: 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!



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

Please Log in or Create an account to join the conversation.

Working on PHD2 support 7 months 3 days ago #21585

  • rlancaste
  • rlancaste's Avatar Topic Author
  • Away
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 1246
  • Karma: 12
  • Thank you received: 322

gbeaton wrote:

rlancaste wrote: 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.


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.


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.

Please Log in or Create an account to join the conversation.

Re:Working on PHD2 support 7 months 2 days ago #21602

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

Please Log in or Create an account to join the conversation.

Re:Working on PHD2 support 6 months 4 weeks ago #21668

  • rlancaste
  • rlancaste's Avatar Topic Author
  • Away
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 1246
  • Karma: 12
  • Thank you received: 322
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.

Attachments:
The following user(s) said Thank You: knro, nmac, jpaana, gbeaton, maudy, tkottary

Please Log in or Create an account to join the conversation.

Time to create page: 0.212 seconds

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!


Gallery

Replica

Why INDI

Replica