Plate-solving set-up for visual rig

[Lee_P]

So I'm just wondering (as a thought experiment at this stage) of ways to add plate-solving functionality to my visual rig. I'm mainly an imaging guy, but occasionally do visual at events and for public outreach work. So, getting to different targets quickly with spot-on accuracy is important. For visual I use a WO GTF81 and Sky-Watcher AZ GTi. I can control this over WiFi using my phone, which I like. The pointing accuracy is often ok, but I can't help but think of the imaging world, where plate-solving is king. Is there an efficient way of adding plate-solving? My current thought is to use an ASIAIR Mini, small guidescope (I have one spare), and a small guidecam (ASI120MM or somesuch). Tell the ASIAIR that the guidecam is actually the main camera and hey presto, I should be able to plate-solve with that. But this is expensive and likely overkill. Is there a simpler and cheaper solution that anyone can think of? Ideally one that doesn't need lots extra kit and cables (i.e. laptop). Portability and low weight are important factors. I think Celestron have a gadget for this (StarSense?) but perhaps only bundled with their telescopes?

[vlaiv]

Maybe this:

https://play.google.com/store/apps/details?id=com.celestron.skybox&hl=en&gl=US

As far as I can tell - it uses smart phone to plate solve.

All you need is way to mount phone next to main ota. Simple 1.25" diagonal can be used to point smartphone camera lens in the same direction as OTA

Alternative would be maybe to use RPI or some other cheaper single board computer (RPIs are in low supply at the moment, so perhaps Orange Pi or Banana Pi? Lookup Armbian for supported models and hassle free install) and Indigo (there is IndigoSky - pre made RPI images, but as far as I can tell, install on any linux system is easy).

That combination has web app control that you can access with browser on your mobile phone to direct the scope once you setup everything. It will however need all the things that you listed - guide scope and some sort of guide camera to act as main / plate solve camera.

 

[Cosmic Geoff]

A few clues: I have a 102mm f5 Startravel, which when used with an ASI224MC camera, performs plate-solving reliably.

I found that plate-solving could work with my CPC800 + f6.3 focal reducer + camera, but only tried it once.

I fitted an ASI120MC camera to an Astro Essentials 50mm finder/guidescope, hoping to use it for platesolving + aiming, but found it only worked when aimed at dense starfields, e.g. the Pleiades. 

Plate-solving ought to work with your WO GTF81, but you will have to figure out how to swap between eyepiece and camera. Maybe use a flip mirror diagonal?

If you were using a Celestron Nexstar mount I would suggest using the Precise GoTo feature instead of plate-solving, but Skywatcher's Synscan does not seem to have an equivalent feature. 😁

In fact I found my Synscan GoTo to be a bit rubbish in the absence of plate-solving, even without the hindrance of a Wifi connection.

Celestron do a plate-solving app for smartphone, but you have to buy it bundled with a telescope and special camera holder.

Edited January 8, 2023 by Cosmic Geoff
Starsense

[Elp]

I've used an RPI running astroberry and currently use an Asiair for most duties. It just works, especially with the app which is optimised to run on mobile phone screens. People will bemoan the need to use zwo equipment, but if you're savvy you needn't spend a fortune. I often use it with a flip diagonal to plate solve on an azgti (so no guidescope needed if you're going to rely on the internal tracking), but most of the time it runs most of my imaging rigs, and I've never had an issue with them.

[bosun21]

I would just use an asiair mini with your guide scope and 120 camera. As long as your guide scope is aligned with your main scope then it will work just fine. Then all you need is your phone. No laptop required. 

[KP82]

RPi4B (astroberry), RPi HQ camera mounted to a 50mm SW finder and a USB power pack are all you need. This is exactly what I've been using for nearly 2 years. I wrote a couple of python scripts to allow plate-solving with a simple button press and alignment between the finder and the main scope.

Edited January 9, 2023 by KP82

[Lee_P]

Thanks for everyone's advice, much appreciated!

[skybadger]

21 hours ago, KP82 said:

RPi4B (astroberry), RPi HQ camera mounted to a 50mm SW finder and a USB power pack are all you need. This is exactly what I've been using for nearly 2 years. I wrote a couple of python scripts to allow plate-solving with a simple button press and alignment between the finder and the main scope.

Can we hear more ? 

Like, what app is doing the solving, how much it impacts the rpi, what the sensitivity is like, why you use a button , the process to tell astroberry where the solution is currently pointing, how you manage or check for differential flexure, etc. 

There's a couple of solutions for this ( auto alignment Vs guiding)  and auto alignment could be continuous vs guiding which occurs during imaging.

My perfect solution has an auto alignment scope and oag guider. 

[KP82]

3 hours ago, skybadger said:

Can we hear more ? 

Like, what app is doing the solving, how much it impacts the rpi, what the sensitivity is like, why you use a button , the process to tell astroberry where the solution is currently pointing, how you manage or check for differential flexure, etc. 

There's a couple of solutions for this ( auto alignment Vs guiding)  and auto alignment could be continuous vs guiding which occurs during imaging.

My perfect solution has an auto alignment scope and oag guider. 

This setup is strictly for visual only. When imaging I use a more traditional guiding setup (Evoguide 50ED + 120MM) connected to a NUC running ubuntu.

For visual the RPi uses Kstars/Ekos for plate solving (astrometry.net which I find to be more reliable than astap). It's connected to my phone running SkySafari Pro. Because SkySafari does not provide a way to trigger the plate solve nor do I want to switch between it and VNC (cumbersome plus it ruins my dark adaptation), I use the button. Once pressed Ekos will plate solve and then auto align the mount. And since the finder is already aligned with the main scope, whatever it points to will also appear in the eyepiece of the main scope. The correction process gets displayed on the SkySafari (very useful).

Differential flexure is not an issue at all here because there is no continuous exposure involved. The RPi HQ camera (IMX477) is pretty decent for the task. The gain is set to 4.0 and exposure to 2.0 sec in Ekos. So far this seems to be optimal. The combo is also used for precise PA. It takes less than 5 mins (in VNC) and improves the RA tracking significantly.

[AstroMuni]

2 hours ago, KP82 said:

For visual the RPi uses Kstars/Ekos for plate solving (astrometry.net which I find to be more reliable than astap).

Is there a reason you are not using the internal Stellar solver?

[KP82]

45 minutes ago, AstroMuni said:

Is there a reason you are not using the internal Stellar solver?

It always fails to solve no matter what settings I change to. Could be something to do with how Kstars/Ekos are compiled in astroberry or how the internal solver handles the FITS data from the RPi HQ camera.

I don't have this issue when using kstars downloaded from the official ubuntu INDI repo "mutlaqja/ppa" on my NUC with QHY or ZWO cameras when imaging.

Edited January 10, 2023 by KP82

[Elp]

Have you downloaded all the astap databases? Otherwise it needs an internet connection to plate solve to online data.

[skybadger]

Thanks KP82. 

I deleted astrometry.net from my Win pc because it was so slow compared to astap and then found that astap had a dependency on it locally. I use it for between 1800mm and 1200mm focal lengths.

What are you using to pole align that can use the rpi pictures ?

 

[AstroMuni]

16 hours ago, KP82 said:

I don't have this issue when using kstars downloaded from the official ubuntu INDI repo "mutlaqja/ppa" on my NUC with QHY or ZWO cameras when imaging.

It may have something to do with sensor size. I have trouble using ASTAP & Stellarsolver in some areas of the sky using the ASI224, but thats both on RPi & Linux Mint.

[KP82]

On 10/01/2023 at 17:22, Elp said:

Have you downloaded all the astap databases? Otherwise it needs an internet connection to plate solve to online data.

The standard H17 database does cover the fov of an IMX477 with 180mm focal length (SW 50mm finder). It could be at its limit which may explain why astap was unreliable (I might give the H18 database a try). astrometry.net with the correct databases downloaded have been working beautifully.

On 10/01/2023 at 21:24, skybadger said:

Thanks KP82. 

I deleted astrometry.net from my Win pc because it was so slow compared to astap and then found that astap had a dependency on it locally. I use it for between 1800mm and 1200mm focal lengths.

What are you using to pole align that can use the rpi pictures ?

 

The astrometry.net database files are huge for smaller fovs. Maybe that's why it was slow on your PC assuming it was a fairly old PC you were using?

The PA module in Ekos.

On 11/01/2023 at 09:00, AstroMuni said:

It may have something to do with sensor size. I have trouble using ASTAP & Stellarsolver in some areas of the sky using the ASI224, but thats both on RPi & Linux Mint.

The internal stellarsolver presumably shares the same database with astrometry.net. If astrometry.net can solve the pictures taken by IMX477 + 180mm FL, I don't understand why stellarsolver can't.

[AstroMuni]

8 minutes ago, KP82 said:

If astrometry.net can solve the pictures taken by IMX477 + 180mm FL, I don't understand why stellarsolver can't.

Perhaps some setting thats different in Ekos. Have you tried asking on the Ekos forum https://indilib.org/forum/index.html

[AstroKeith]

Stellarsolver uses astrometry.net, so in theory should work. 

However, astrometry.net can require a significant number of arguments to accompany a solve request. Many are optional, but many are key to successful solves. Image scale limits for instance are critical.

Stellarsolver may be making shortcuts when it calls astrometry.net. Most worrying for me is that astrometry.net normally refers to a astrometry.cfg file to find its default settings. Stellarsolver doesnt use this and buries the settings in its main program.

After some considerable experimentation I have found a set of arguments that enables astrometry.net to solve my images with about 99% success, in about two seconds, on a raspberry pi.

[skybadger]

2 hours ago, KP82 said:

 

The internal stellarsolver presumably shares the same database with astrometry.net. If astrometry.net can solve the pictures taken by IMX477 + 180mm FL, I don't understand why stellarsolver can't.

that would be my point too. why would ASTAP be quicker than astrometry if ASTAP has a dependency on astrometry ? Also why would ASTAP fail and astrometry succeed if they are using the same source data files ? That hints at the wrong config settings. Maybe too many stars for small scopes/focal lengths. 

 

[KP82]

2 hours ago, AstroKeith said:

Stellarsolver uses astrometry.net, so in theory should work. 

However, astrometry.net can require a significant number of arguments to accompany a solve request. Many are optional, but many are key to successful solves. Image scale limits for instance are critical.

Stellarsolver may be making shortcuts when it calls astrometry.net. Most worrying for me is that astrometry.net normally refers to a astrometry.cfg file to find its default settings. Stellarsolver doesnt use this and buries the settings in its main program.

After some considerable experimentation I have found a set of arguments that enables astrometry.net to solve my images with about 99% success, in about two seconds, on a raspberry pi.

I believe you're right. Stellarsolver could be making too many assumptions on data in its shortcut such as fov and resolution. 

Anyway Ekos plate solves with astrometry.net very quickly (2 - 3 secs) and accurately, so I can't be bothered to fix the stellarsolver on my RPi.

[StevieDvd]

Plate-solving can be slow if you have a lot of catalog files to go through and you do a blind-solve (passing no details of focal length, area of view etc).  Reduce the number of catalogs to reduce the search and the blind-solve can be fast too.

But if you pass the right settings the solve can be quicker with the full catalog, but if the settings are wrong then a solve-error can occur. A blind-solve can then give a clue to the correct settings and catalog used.

 

 

[AstroKeith]

I'm using a 6 deg fov (cheapo 50mm cctv lens on an ASI120MM-S). I was initially surprised to find that blind solving (ie no RA & Dec seed) was as fast as seeded. Bracketing the image scale by +/- 5% was critical.

Also binning x2 helped on speed and reliability. I also turn off plots etc.

Looking at the index files needed for such a large field of view, I can see they are quite small, and after the first solve, the PI OS automatically keeps them in ram.

The 6deg fov is perfect for visual use. It produces a solve accuracy of about 20 arc seconds which is more than good enough. Plus it means I dont need to physically align it with my main scope. I have a software routine than automatically measures the finder to main scope offset and save it for the session.

As I have my own drive design, I was able to code in the option of an automatic plate-solve at the end of each 'goto', which then triggers any adjustment needed (aka 'goto++')

[KP82]

6 hours ago, AstroKeith said:

I'm using a 6 deg fov (cheapo 50mm cctv lens on an ASI120MM-S). I was initially surprised to find that blind solving (ie no RA & Dec seed) was as fast as seeded. Bracketing the image scale by +/- 5% was critical.

Also binning x2 helped on speed and reliability. I also turn off plots etc.

Looking at the index files needed for such a large field of view, I can see they are quite small, and after the first solve, the PI OS automatically keeps them in ram.

The 6deg fov is perfect for visual use. It produces a solve accuracy of about 20 arc seconds which is more than good enough. Plus it means I dont need to physically align it with my main scope. I have a software routine than automatically measures the finder to main scope offset and save it for the session.

As I have my own drive design, I was able to code in the option of an automatic plate-solve at the end of each 'goto', which then triggers any adjustment needed (aka 'goto++')

IMX477 with 180mm FL produces 2deg x 1.5deg fov. So the index files required are substantially bigger. However with the correct details passed to the astrometry.net solver it is still very fast. The 1.55um pixel size produces a resolution of 1.78 arcsec/px which is a little too much but the Pi HQ camera is OSC so binning doesn't work unfortunately.

The function of measuring the offset automatically sounds really neat. I had to write a script to produce a live feed of the camera with a crosshair overlay in the centre and display it on a webpage for alignment with the main scope.

Edited January 12, 2023 by KP82

[AstroKeith]

12 hours ago, KP82 said:

IMX477 with 180mm FL produces 2deg x 1.5deg fov. So the index files required are substantially bigger. However with the correct details passed to the astrometry.net solver it is still very fast. The 1.55um pixel size produces a resolution of 1.78 arcsec/px which is a little too much but the Pi HQ camera is OSC so binning doesn't work unfortunately.

The function of measuring the offset automatically sounds really neat. I had to write a script to produce a live feed of the camera with a crosshair overlay in the centre and display it on a webpage for alignment with the main scope.

To do the auto alignment between finder and scope I do the following

I point the main scope accurately at a bright star, usually Polaris as its not moving.

I do the usual capture and solve, but ask for plots.

Astromtery.net produces a report with the stellar sources listed in order of brightness. The list includes the x,y pixel position of the detected stars in the image. The brightness star is is of course the main scope sightline.

I display the star name to give me confidence the process has worked OK.

I store the x,y position of that star (ie the main scope sightline)

In all future solves, I call RA,Dec =  xy2rd_wcs(x,y) (part of the full astrometry.net suite) which returns the RA & Dec of the main scope sightline.