StuartT

Solved

you have to "open with.." Microsoft Windows based script host

who knew!?

3 minutes ago, Oddsocks said:

I don't know EQASCOM at all but the error message is common when an applications scripting interface is not registered correctly with Windows.

Try Mouse-Right-Click on the program shortcut for EQASCOM and select "Run as Administrator" from the pop-up contact menu.

Let EQASCOM launch fully then close it down again without making any changes.

Now launch EQASCOM normally, without ADMIN rights this time and try to configure, does this fix the problem?

EQASCOM setup appears to be a script, so can't be run as administrator

It looks like an ActiveX error, but I thought that was something to do with web browsers?

1 minute ago, scotty38 said:

Is the com port etc set up correctly?

Seems to be

I am trying to set up my new mini-PC following Patriot Astro's video step by step. I've installed ASCOM and connected the mount to test the connection, but I am getting this error. I ran ASCOM diagnostics and it tells me every test has been passed. Any idea what the problem is?

18 hours ago, wuthton said:

You might want to upgrade to Win 11 Pro as you can then connect with Windows RDP which is far superior to the likes of Teamviewer as it works over your local network rather than bouncing around servers. You only need Pro on the remote PC.

Thanks. The Quieter 3Q already has Win11 Pro on it.

My laptop is Win10, but I hope it will work ok

3 hours ago, wuthton said:

If you do go down the on mount PC route, get one with plenty of usb ports as USB hubs are nothing but trouble. I use a Zotac CI320 in the obsy and a Raspberry Pi on my portable setup.

3 hours ago, scotty38 said:

Ah yes, recall the "fork" issue you were seeing.

I think the on scope PC will be a good move, however I can't help thinking that's not your real issue but I'm lost as to what else it can be at the minute.

I've taken the plunge and ordered the Mele Quieter 3Q (Win11, 8GB RAM)

Fingers crossed!

38 minutes ago, scotty38 said:

Yes you have to use the "fork selector" in PHD2 but other than that all was fine and dandy. Choosing native drivers was fine too but from your screen shot you don't seem to have those listed either..

The problem with the fork selector in PHD2 is that it was showing either two 2600s or two 174s - so I could never tell which camera I was actually connecting to. I'd only find out when it would then tell me I didn't have a dark library (so it had obviously connected to the imaging camera instead). Occasionally PHD2 connects ok, but in general it doesn't. 

29 minutes ago, scotty38 said:

Was yours one of the powered types?

Do you still have the USB and power going through the mount? I know you said other apps work but what happens if you bypass that just for the sake of testing?

No, it was not powered. It was just a long, heavy gauge USB cable

No, I have abandoned the mount hub, as it's apparently a problem.

I have spent SO much time trying to fix this problem. It's really been driving me crazy.

I wonder if it is because my laptop only has USB-C ports? These are incredibly flimsy! The slightest movement and everything disconnects.

Another argument for a mini-PC perhaps?

there are people using 15m USB cables it seems

2 hours ago, scotty38 said:

Glad you finally listened 🤣🤣🤣 🤣

 

thanks to @scotty38 too 😬

Now.. I have just been trying out a closer connection (as it's a sunny day so I can take the covers off). I connected the laptop 'direct' to the UPBv2 via a 1m cable. I did (eventually) manage to connect everything up. So it definitely seems to be an improvement. However, it took several attempts (and two laptop reboots) to get NINA to see any of the ZWO drivers.

So it's definitely not the whole story. 

Although NINA couldn't see my cameras, ASI Studio, SharpCap and Windows could all see them just fine and download images! So there clearly seems to be some kind of issue with NINA.

Maybe a mini-PC would be better? Maybe it wouldn't?

Someone* helpfully suggested a reason I have been having all this trouble. My rig is connected to the laptop via a 15m USB cable. Apparently USB signals can't travel more than a few metres before getting messed up (🤦‍♂️)^2.

So he suggested I use a mini PC on the telescope and then wifi out to that.

* thanks @Stuart1971

22 hours ago, Marvin Jenkins said:

Wow how do you follow that! I say with something small and different.

I recently saw in my big 50 by going to bed early after working too much.

However, good friends from the USA sent me this. They know I am Astro mad and a geology nut. This seems to encapsulate both and look great.

well! Quite the coincidence. My team at the office bought this for me for my birthday this year! Very nice of them (knowing I am an astronerd). It's now on my mantelpiece 

5 hours ago, sharkmelley said:

The reason for the offset is to ensure that the values coming from ADC are unbiased, given that the ADC has read noise.  Suppose the offset is 100 and the pixels have received no light.  The ADC will report some pixels as 100, some as below 100 and some as above 100, all because of the read noise.  But the average is exactly 100, which is the correct (i.e. unbiased) value for a pixel that has received no light.

Now suppose the offset is zero and again the pixels have received no light.  The ADC will report some pixels as 0 and some above 0 but it cannot report values below zero because the ADC does not produce negative values.  Therefore, the average ADC value will be greater than 0 which means the ADC is giving a biased estimate of the true value.  This would cause all sorts of problems for low light imaging.

Mark

Perfect! Thanks so much. I get it now. 🙂

(ok. Full disclosure. I don't understand this at all)

Surely what we are all trying to capture here is light. So pixels with interesting information in them will be non-zero (i.e. light). Black pixels are just space. So why should we care about them?

Thanks everyone. I think I kind of understand this. I think I need to do some more reading though.

22 minutes ago, Stuart1971 said:

What you are doing is adding a tiny bit of signal to all areas of the image, even the darkest areas with very little light hitting them, so with a value of 1, this will only help the bright areas, you need a value of approx 25 offset, to add signal to the darkest areas of an image…if the whole image is very bright right into the corners, then you could use a lower offset indeed…but that it normally not the case at all…

I'm still not really getting what is so bad about a 0 pixel though. If there is no signal, isn't it ok for it to be 0? And if there is a tiny bit of signal then it won't be zero anyway (because the signal will give it a value). 

Or is it because noise can be negative as well as positive, so you have to add a baseline signal so that you avoid having a negative pixel value?

17 minutes ago, symmetal said:

You can see if your camera offset is sufficient by looking at a the image statistics of a bias frame. Every image will include the camera bias signal added to it and during calibration this bias component is subtracted. If this bias frame contains zero value pixels calibration won't work correctly.

Noise will also be superimposed on the bias frame so while adding say 50 offset should add 50 ADU to each pixel, if you examine individual pixels, while most will be a value near 50, some will be higher and others lower, due to noise. Noise can add as well as subtract from the ideal pixel value and a few pixels may be ADU 20 or so.

Looking at the bias image statistics this will give the average ADU value as well as the minimum and maximum ADU value. Offset is added until this minimum ADU value is always above zero, with a bit more added on for safety.

So the offset ensures that the camera analogue output with positive and negative noise values added will always be higher than the minimum analogue voltage the ADU will accept to do a successful conversion.

Image calibration will subtract this offset and any other fixed signal values added or subtracted during the read process, but the noise will remain. Stacking many images reduces this noise component.

The number of actual ADU added by increasing the camera offset by 1 depends on the camera design and the camera bit depth, but I assumed it's 1 here to make it a bit simpler.

Hope that helps more and isn't more confusing. 😊

Alan

I've just looked at the pixel values in my master bias (using PI statistics) and they are between 0 and 1 (so normalised). I assume you want the 16-bit values? (as it's a 16-bit camera). Is this what you mean by ADU? If so here they are.

Master_bias_1x1_15C_gain_105_offset_50

count (%) 100.00000
count (px) 26091648
mean 500.326
median 500.219
avgDev 0.795
MAD 0.667
minimum 478.881
maximum 554.740

So they are a lot more than 50! I'm not really sure what I am meant to be looking at here. for comparison, here is a master dark

Master_dark_35sec_gain_105_offset_50_bin_15_C_bin1x1

count (%) 100.00000
count (px) 26091648
mean 500.328
median 500.280
avgDev 1.092
MAD 0.920
minimum 468.100
maximum 23832.271

(it's interesting that the dark frame is not lighter on average than the bias frame. I assume that means this camera has negligible dark current?)

err...

thanks 😬

15 minutes ago, carastro said:

Crumbs that sounds awful.  I have a similar problem with my dual rig, having 2 Atik cameras downloading to one laptop.  I can open 2 iterations of the software and can grab each camera, but the data just hangs when it tries to download it.  I gave up in the end and now use separate laptops for each camera. 

Carole  

gosh! So it's not just me then. I guess that's sort of reassuring. 😬

The strange thing is, Windows device manager sees both cameras perfectly fine. But somehow both NINA and PHD2 get terribly confused. I'm thinking I may have to ditch the guide cam (ASI174MM mini) and find one from a different manufacturer so the drivers aren't clashing. 🤷‍♂️

I read the following here:

The offset value of a camera is a little bit more straightforward. This automatically fills a small amount of the pixel-bucket before any light is gathered. This is to ensure that there are no 0-value pixels on each frame. We want to avoid 0-value pixels at all cost because we then lose any small amount of information that might be there. It is impossible to create information out of nothing, so ensuring that no pixel has a value of 0 when it is read out helps us.

What I don't understand is, if there is a tiny bit of signal, then there wouldn't be any zero value pixels anyway surely?

i.e. if the tiny bit of signal is 1 and we have no offset, we'll end up with 0+1=1 So why would setting an offset of, say, 25 help us? That just means we have 26. Either way, it's not a zero

2 hours ago, carastro said:

Nice work Stuart

Carole 

thanks Carole. I had a nightmare trying to get my guide cam and imaging cam both connected (in PHD2 and NINA respectively). They are both ZWO and they endlessly clash. So after two hours of trying I gave up on guiding and relied on the mount alone. The longest subs I could manage were 90s before starting to see elongated stars. Not bad considering that, I thought.

3h with my Esprit (reduced to f/5.4), ASI2600MC Pro, L Extreme filter. Processed in Pixinsight (Moon 95%)

On 09/12/2022 at 13:49, Mandy D said:

I get a 404.

It's working Mandy. I just checked it

On 29/10/2022 at 19:35, Gfamily said:

There's a nice comparison you can make to pass on the insane scale of the Universe - that if you put the Earth-Sun distance at one inch, then one light year is a mile. So the nearest star is 4.2 miles away.

It's always impressed me just how close this comparison is (inches/miles/light years). Accurate to 0.1%