StarQuew - Web INDI client and sequence generator

[GuLinux]

Hi all,

I'd like to share with you a first beta version of my new software.
You can think of it like an "Ekos light": a web based INDI client and sequence generator, particularly suited for embedded environments like the Raspberry Pi.

You can find a the software and some docs about installation in the github page: https://github.com/GuLinux/StarQuew

Please share your thoughts and feedback
 

[wimvb]

Looks like a nice lightweight package for those who don't need the full power of ekos. Is the page layout compatible with mobile devices, such as tablets or smartphones?

[GuLinux]

2 hours ago, wimvb said:

Looks like a nice lightweight package for those who don't need the full power of ekos. Is the page layout compatible with mobile devices, such as tablets or smartphones?

Well, not yet for smartphones (or to put it better, it's compatible, but not optimized), but tablets should be ok. It's a low priority goal, but I'd probably concentrate a bit more on functionality first

[GuLinux]

Hi all!

I was finally able to produce a stable, and more importantly, easy to install version, so a first "public beta" is available.

Release link: https://github.com/GuLinux/StarQuew/releases/

Raspberry Pi image: https://github.com/GuLinux/StarQuew-PiGen/releases/ (Instructions: https://github.com/GuLinux/StarQuew-PiGen/blob/master/README.md)

 

And a video tutorial on how to use the program.

 

 

 

 

[han59]

Nice work. This looks promising.

Now a server link to planetarium program(s), guide program and plate solver(s).

Did I see a FITS preview function on the video?

Han

P.s. I lived a few years in Ealing as an expat.  The Skies orange/red where not inviting to do astronomy. I unpacked my telescope only two times.

http://www.hnsky.org

 

 

[GuLinux]

Cheers!

Yes, there's a FITS preview option. Needs some optimization, but I find it quite useful.

Autoguiding and plate solving are already well into my todo list, although for the first I really don't have a clue on how to do it (I mean, PHD has some nice APIs, but it still requires to be started on a X server, which kinda defeats the whole point of StarQuew. Implementing a new autoguiding engine from scratch.. well... surely more appropriate, but what a huge task!)

 

What do you mean by "Server link to planetarium program" though? If you mean starting some kind of desktop planetarium, then it should be client side, not server side, right? (and if that's the case, it mostly depends on planetarium software providing an URL handler).

[wimvb]

26 minutes ago, GuLinux said:

Autoguiding and plate solving are already well into my todo list, although for the first I really don't have a clue on how to do it

What about lin_guider? Ekos guiding is based on it.

[GuLinux]

 

3 minutes ago, wimvb said:

What about lin_guider? Ekos guiding is based on it.

Yes, that's another option I was thinking about. It's still a relatively big task, stripping away all the UI, and making some API to create a web frontend, but since it's written in Qt4 (which I'm more familiar with) it might be more suited than phd2.

[han59]

1 hour ago, GuLinux said:

What do you mean by "Server link to planetarium program" though? If you mean starting some kind of desktop planetarium, then it should be client side, not server side, right? (and if that's the case, it mostly depends on planetarium software providing an URL handler). 

The link is useful for importing positions rather then typing them. If you want to image two objects, you will need a position in the middle or will need the position of a  faint object, moving comet or just want to make an mosaic, the planetarium program can provide the positions.  Have a look to interfacing of the acquisition programs as APT and CCDCIEL with  CDC, HNSKY. APT can also talk with the C2A and SkytechX planetarium programs.

Secondly a link to a plate-solved image or exporting the frame showing the dimensions and position can be exported to the planetarium program to see which fuzzies are on the image.

PHD2 is pretty established. An Linux version is available. A link to this popular guiding program will be essential to many users.

The planetarium program will most likely not use INDI as client but provided an own server interface. Same with PHD2.

Planetarium server commands:

https://www.ap-i.net/skychart/en/documentation/server_commands

http://skytechx.eu/?page=skserver

http://hnsky.org/help/uk/hnsky.htm#server

An example of exporting an position:

 

 

 

 

[GuLinux]

35 minutes ago, han59 said:

The link is useful for importing positions rather then typing them. If you want to image two objects, you will need a position in the middle or will need the position of a  faint object, moving comet or just want to make an mosaic, the planetarium program can provide the positions.  Have a look to interfacing of the acquisition programs as APT and CCDCIEL with  CDC, HNSKY. APT can also talk with the C2A and SkytechX planetarium programs.

So basically you just want to tell your mount (connected through the StarQuew server)  to move to the position your planetarium (on your desktop) is pointing to?

If that's the case, nothing needs to be done, that's what INDI is for. StarQuew already starts an INDI server, you just need to load your telescope driver as well, then connect your planetarium via INDI, and that's it.

I know not all planetariums support INDI, but to be honest, trying to support other protocols is definitely out of scope. Besides, a lot of software do support INDI (CDC, KStars), and they're available on multiple platforms.

35 minutes ago, han59 said:

Secondly a link to a plate-solved image or exporting the frame showing the dimensions and position can be exported to the planetarium program to see which fuzzies are on the image.

Plate solving is something different here. It can be used locally on the server to sync the telescope coordinates, then the planetarium will notice that the coordinates of the telescope will have moved.

My idea was to implement a plate solving page inside StarQuew, not using a "link" to an external program

 

35 minutes ago, han59 said:

PHD2 is pretty established. An Linux version is available. A link to this popular guiding program will be essential to many users.

The planetarium program will most likely not use INDI as client but provided an own server interface. Same with PHD2.

PHD also supports INDI, thats not a problem. The problem is PHD can't run without an X server, you would need to open a VNC session to your StarQuew server just to setup PHD. Which is what I wanted to avoid in the first place. This is something that the guiding program itself need to do, not StarQuew. I already raised a ticket for PHD (https://github.com/OpenPHDGuiding/phd2/issues/683) but it's quite unlikely it's gonna be implemented, unless it gets a decent amount of requests.

 

But we'll get there, as @wimvb mentioned there are other options as well (lin_guider).

 

[han59]

9 hours ago, GuLinux said:

So basically you just want to tell your mount (connected through the StarQuew server)  to move to the position your planetarium (on your desktop) is pointing to? 

 

- No, that serves no purpose. The idea is to fill the (StarQuew) sequence with info from the planetarium program, so name, RA, DEC and orientation of the object to be imaged. StarQuew is then the client to the planetarium program server at port xxxx. At the moment, I don't know if planetarium programs can be controlled via INDI.

- I'm not aware of an PHD2 INDI driver to control PHD2. PHD2 can be controlled as client of the PHD2 internal server at TCP/IP address 127.0.0.1, port 4400.  Why would you need a X-server? The Linux version of PHD2 can use INDI to control mount and guiding camera.

https://github.com/OpenPHDGuiding/phd2/wiki/EventMonitoring

 

[GuLinux]

1 hour ago, han59 said:

- No, that serves no purpose. The idea is to fill the (StarQuew) sequence with info from the planetarium program, so name, RA, DEC and orientation of the object to be imaged. StarQuew is then the host to the planetarium program server at port xxxx.

So basically it's for embedding WCS coordinates into the fits file, right?

I still think that's very low priority, and INDI already supports WCS, so it makes no sense to have one different implementation for each planetarium software.

Besides, I think you can still do it without a planetarium at all. As soon as I have plate solving in place, that should be sufficient to set coordinates to the Telescope module ,which in turn should provide WCS coordinates for the CCD module.

1 hour ago, han59 said:

 - PHD2 linux version uses INDI to control the camera and mount. But for automated start/ stopping of the PHD guiding and so on you would have to connect to the PHD2 internal server at TCP/IP address 127.0.0.1, port 4300. Why would you need a X-server?

https://github.com/OpenPHDGuiding/phd2/wiki/SocketServerInterface

 

Yes, but as far as I know, there is no way to compile PHD2 without a GUI. And those APIs anyway don't allow a full control of the guiding process. You'd still need to open PHD2 via VNC, and set it up.

[han59]

16 minutes ago, GuLinux said:

So basically it's for embedding WCS coordinates into the fits file, right?

 

No. it is to set the target object RA,DEC position in a sequence line.

 I can't see in the video how you set the target position (RA,DEC) but that would a basic feature of a sequence unless you want to do it all manual. A sequence line should contain camera settings (exposure, binning, temperature.....) and the object position for mount (RA, DEC),  guiding settings (exposure, ditter...),  auto focuser settings (every .. th image, focus focus method).

This automated sequencing will only work if you have plate solver in place to home in to the specified target position unless you have superb mount.

[GuLinux]

22 minutes ago, han59 said:

No. it is to set the target object RA,DEC position in a sequence line.

 I can't see in the video how you set the target position (RA,DEC) but that would a basic feature of a sequence unless you want to do it all manual. A sequence line should contain camera settings (exposure, binning, temperature.....) and the object position for mount (RA, DEC),  guiding settings (exposure, ditter...),  auto focuser settings (every .. th image, focus focus method).

 This automated sequencing will only work if you have plate solver in place to home in to the specified target position unless you have superb mount.

For now it is all manual, yes.

Remember that the first intended audience is for people with *very* lightweight and minimal setups, like Star Adventurer and similar.

Telescope support (GOTO etc) and plate solving are going to be implemented, sure, but what you ask is something far more advanced (and there are already plenty of other software doing that).

IMHO setting target position is not really a basic feature of a sequence. What I would do (even with a GOTO mount) is to slew to the target, then focus, set exposure values based on the histogram of a preview capture, and *only* then create a sequence.

Calculating the correct exposure is the critical step here, and you want to do it on your actual target, and since you're already pointing there, what would be the advantage of adding a GOTO step to a sequence?

Sure there might be cases where you already know in advance what exposure you want, maybe because you're doing a subject already well tested with your equipment, but again, I don't really see this as a typical use case

[han59]

Manual is fine. I did till 2 years ago. So your program automates camera control.

Fully automated imaging has the advantage you can sleep while it is happening, focus is updated regularly and with plate solving in place, imaging series can continue the next clear night. 

For me the auto focus to compensate for temperature drift and plate solving are the big improvements. I still stay awake to review and change target.

My typical exposure time and cooling temperature are pretty constant. As long it is not too bright like M31 center where it should be equal or less then 50 seconds, I stick to 200 seconds. It is just a number but I could also have taken 100 seconds. It is a compromise of lost time by downloading each image, percentage lost images due to guiding problems, data size and have enough images to recover from the 12 bit A/D resolution to something close to 16 bit by stacking.

Gain is always at unity gain. so I don't have to update my darks and flat-darks/bias all the time and keep them for a few months. I see no real practical advantage of playing with the camera gain.