Viktiste

On 01/12/2021 at 19:39, ollypenrice said:

One of my robotic clients returned a defective new iOptron mount and, interestingly, the person at Telescope Service who dealt with the return said he wouldn't recommend iOptron mounts for robotic use. I can't give you any more information than that.

Olly

Having just bought a CEM70 I think I know why. It will pinch the RA axis just a few degrees below horizontal. 

And the mount will keep track of the ra position even if you loosen the clutch and move it manually. I'm not sure I see the benefit of that either as a plate solve will get you back on track in about a minute or so. And if you move the mount manually you will likely loosen both the ra and dec clutches.

Maybe there is more to it than this and  I don't understand the whole picture (hoping someone else will chime in...).

I just bought a CEM70 without the encoder. I don't understand the benefit of the encoder if you are guiding with PHD2. I 'think' what the encoder does is substantially increase the ra tracking accuracy so it enables you to  take long exposures without guiding. But the extra cost is also substantial, so I opted out on the encoder.

I like that wooden pier 👍

The NINA interface has quite a learning curve. But once I got the hang of it, I found it to be a very good piece of software. Resetting the layout should bring the windows back for you, and you can test that without any gear connected at all.

CRC label off. 

5 hours ago, Newforestgimp said:

I’ve just discovered that McAfee seems to think that “Ioptron commander port checker.exe” is a virus and quarantined it each time I’ve tried to connect to mount before reinstalling, do you think this could be why commander will only connect once directly after a fresh install ?

Yes, absolutely!

It should be possible to tell McAfee to allow Ioptron commander.

Why use McAfee anyway? The firewall + virus program that comes with windows is good enough...  My mount LapTop is dedicated for that purpose, so I have disabled firewall etc. on it. But then I have no private stuff (like e-mail etc.) on it.

I highly recommend this:

And try to reset your layout: options - Imaging - reset layout

I think your camera is connected ok. Here is is how my ASI 1600mm looks like when connected in NINA:

And here is how my imaging screen looks like:

It looks to me like you have "lost" the windows layout under the imaging section. Try to toggle these buttons on/off:

A little late too, but - under Image parameters you can press 'Acquire from Image' and select one of the raw files that does work. That will make sure your stacked image gets the correct date + coordinates. I have had better luck with the France server than the UK server.

Also, if you get an error similar to 'Error: Insufficient photometric data: Got 4 sample(s); at least 5 are required', then untick 'Automatic limit magnitude' and manually play with the 'Limit Magnitude'. As per this post on the Pixinsight forum: https://pixinsight.com/forum/index.php?threads/imagesolver-fails.16215/#post-105315

2 hours ago, Newforestgimp said:

Regard to labelling ports are we talking physical labelling like stickers or tagging ports in device manager or something ?

Physically labelling.

I did a little bit of testing. I connected my CEM70C to all  4 USB ports on my PC (powered down mount after unplugging , powered up before connecting to the next usb). It connects to COM9 in all 4 cases and Commander 7.0 connects every time. Disconnected mount, Deleted the COM9 in device manager as described above, reconnected mount.  It now connects to COM5 (not COM9) and Commanders connects ok w/o any reinstall.

Good to hear you made some progress.

7 hours ago, carastro said:

Unfortunately that does happen, I have all my ports labelled now so I make sure I use the same ones every time.  Including the hub if I use one.

I do the same, I think is good practice (even if it theoretically should not be needed). 

For what it is worth, you can expand the Ports (COM & LPT) section in Device Manager and see what COM ports are assigned at the moment, and which ones have been in use earlier. Just like in the USB list you can delete the gray ones. Remember to tick on show hidden devices.

In an effort to reduce frustration and to try to make it more stable, always use the same USB's. Once everything is connected and working delete all the gray USB ports and COM ports. Maybe that will help, maybe not. 

7 minutes ago, Viktiste said:

I am guessing that when you connect the mount with a USB cable (not a EQDIRECT cable) then com ports are not applicable?

That was incorrect guessing. I just checked with my CEM 70 mount, connected via a USB cable.

In device manager I see it listed as COM 9:

And this is it under USB serial Bus controllers:

I don't have ex

1 minute ago, david_taurus83 said:

Regarding the Serial to USB method. I should have been clearer, this is the only way to connect a CEM25P to a PC and it worked great. It didn't have a USB port on the mount. Sounds like your GEM45 does so the Serial to USB method may be obsolete.

I am guessing that when you connect the mount with a USB cable (not a EQDIRECT cable) then com ports are not applicable?

Windows 10? If so you can try this (with the mount usb cable disconnected):

Go into Device Manager (search for it on the start menu). In device manager select view - show hidden devices. Then expand the 'Universal Serial Bus controllers'. Grey usb icons are equipment that has been connected, but are not connected now. You can delete these (RHClick - delete). This forces windows to forget that device has ever been connected and will force a reinstall of it the next time it is connected.

See if that helps.

I voted after 2038. 

Here is an interesting read about Elon Musk's thoughts about it, written by Tim Urban (4 part series on Elon Musk). https://waitbutwhy.com/2015/05/elon-musk-the-worlds-raddest-man.html In part 3 (written in 2015) he guessed the first manned mission to mars in about 10 years. I'm thinking these people are way too optimistic by nature. I also think the dream of colonizing Mars is so costly it will not happen until we have no other choice. Life on mars is probably going to be pretty grim too, with temperatures on a lucky summer day ranging from +20ºC  to -150ºC the same night.  Better not be drunk and fall asleep on a late evening outside the Martian Bar 🤪

11 hours ago, johninderby said:

Irrelevant side note here but Columbus bought maps of the east coast of North America from fisherman in Bristol before setting off. They had been fishing mainly off the coast of Newfoundland for many years and the fishing vilage of Walker Newfoundland was founded in 1491. 

Just about 500 years after Leiv Eirikson sailed there... [another irrelevant side note 🙂]

https://en.wikipedia.org/wiki/Vinland

On 24/09/2021 at 21:25, A320Flyer said:

Since an RGB image does not have a separate luminance channel, it is usual to set all channels to have equal weighting prior to extracting the luminance.

I'm not sure I understand that. Equal weighting? Does not a RGB image consist of unequal weighing of the RGB channels? If they were equal the image would appear black and white?

Thanks for elaborating Bill.

I'm going to have another go at it when I get the time.

CEM70 + TriPier 🙂

Still debating with myself what should go on top of it. I'm thinking either a Celestron Edge HD 11 or a TS-Optics 10" f/8 RC. I'm Leaning towards the TS RC (for price reasons obviously) but am a bit in doubt, mostly because of collimation. 

Thanks to A320Flyer for detailing his PixInsight process for the M81 & M82 LRGB+Ha IKO dataset.

I have tried to follow your process, I get much better results than before. JonRista noise reduction was a good read. But I am still nowhere near your image, especially the way you get the smooth IFN out, and also the blue tone in the galaxy.

A couple of questions if you don't mind:

4. RGBWorkingSpace on RGBHa with all channels as 1.0. 

What is the purpose of this? Does it do anything since all factors are set to 1?

2. Stretch using several small iterations of HT until the galaxies are well defined, and then use several small iterations of Curves to bring up the background and IFN whilst keeping the galaxies controlled.

I guess this is where I fail miserably. Did you use a mask at some point during this HT/curves process?

Did you at some stage apply Jon Rista's  noise reduction to the RGBHa or only at the monochrome LumHa?

Thanks in advance 🙂 

On 21/09/2021 at 12:39, A320Flyer said:

Thanks for your comment. I hope this helps.

Thank you so much for posting this. I have some follow up questions 😉

But perhaps the competition thread is not the correct place, so I made a new thread here

https://stargazerslounge.com/topic/383551-m81-m82-lrgbha-iko-dataset-processing-with-pixinsight/

On 03/08/2021 at 21:31, A320Flyer said:

Here's my attempt. Processed in PI with Ha added to Red, Ha added to Lum then combined together

Any chance you could share some more details of your PI workflow? Wonderful result.