matt_baker

3 minutes ago, Taman said:

The sensor is 43MP and ZWO binned it to get 11MP. The new update unlocks the full resolution of the camera. There should be an option to switch between the two.

Why would they bin it in the first place?

1 minute ago, Taman said:

I spotted this yesterday, ZWO have just released a new driver update that unlocks the binning on this camera.

Have you just downloaded the latest update? If so, you should be able to now choose between the two modes.

Tony.

How does that work? Was the camera 43MP to begin with but was binned down to 11 by ZWO?

Just now, wimvb said:

If it's on the filter, it will vary from one filter to the next, and may be absent on a certain filter. Otoh, the specks are much too small to be on a filter. In what order did you take the exposures for the different filters? Can you repeat the results, ie, can you take flats for the various filters? One exposure per filter should do it. Is it on all the green and blue exposures? For instance, could it be tiny water droplets that were sitting on the sensor, but have dried up since? In that case, you wouldn't see it any more. And it would vary in size/intensity for subsequent exposures. So by the time you got to the red filter, it could have been gone. I'm just grasping at straws here.

Does that happen? My wildest guess is that that wouldn't create specks, but a swiping vignetting pattern or gradient.

In any case, I would take flats and see if the problem persists, or if it was a one time event.

I went from R to G to B. Only shows up on G and B

14 hours ago, wimvb said:

Time to open the filter wheel, I’d say.

I honestly can't figure out what it could be. If it was dust then surely it would be present in the red data too? I did 40-50 lights of each filter so it's not like there's less to integrate for it not to appear

I've had a look at the uncalibrated, registered data and it's definitely there, albeit hard to spot. It's a little black trail as the exposures go on. It's a very odd thing and I was thinking the exact same because it isn't consistent throughout the image, just certain spots, and the fact that it doesn't show up at all of the red data. I'll keep having a look

Really confused as to what this is in my G and B of M31. Red is completely fine, but G and B seem to exhibit walking noise even though they were all dithered the same amount, same distance and same night.

Red

Green

Blue

I do realise that my DBE is rather scuffed on G and B but it doesn't make a difference

I was wondering that it might be a potential software issue too. I can post my guide logs if anyone wants to have a look along with the EKOS indi logs

It's still doing it unfortunately, not as often, but it sure is still there.

I used a separate power supply completely to rule out it being the PSU that goes to the distribution. Albeit not a 13.8, just a 12v 5A brick.

I find it odd because only in the last 2 months has it done it, before it was completely fine.

In other news, I have managed to tune the backlash on my DEC nicely and I'm getting a consistent 0.6" with the HEQ5 since I've also recently serviced it

Went for round two

Edit: Added TIF for more accurate representation 

v4.tif

Good luck again everyone.

Went for the same effect as last time by having one SCNR'd and the other not because I like the look of the greens in this particular Nebula. I didn't want to completely over do the sharpening and curves either, just go for a nice, soft look but I may go back and add some more sharpening

Processed in PI

Non-Linear:

Crop>DBE>Decon (Only Ha)>TGV>MMT>Masked Stretch

Linear:

Star Halo Reduction on OIII and SII>Pixelmath combine SHO>Ha as Lum in LRGB combine>Starnet>MT>Curves>LHE>Export

Definitely looks like something to do with the master bias. Potential light leak?

"Actually, I've been working on this for some time, but preferred to keep it silent until now. I already started exploring the possibility of adding optional GPU support to several critical parts of our PCL development framework a few months ago. As a starting point, a version of PCL (and hence of PixInsight) with OpenCL kernels implementing some important bottlenecks (such as inner convolution loops, statistics and linear algebra routines, etc) should be ready sometime this year.

As I already have said many times, however, the amount of pending work and ongoing projects that we have ahead is huge, and right now we have more important things to do than adding GPU support. So this is not at the top of the stack, but is undoubtedly important and I am taking it into account"

This is what Juan said back in April

12 seconds seems a bit long for a flat frame. What bandpass is your ha filter?

Are you able to provide the raw stacked files and I'll see if I can pinpoint the issue?

Just wondering if the master flat has been calibrated with flat darks?

Invert > SCNR > Invert > SCNR 0.8

Just now, Magnus_e said:

Are you sure? Are there different ways of inverting the image? I used IMAGE -> Invert, and got this.

Like it is now run SCNR, then invert it back to normal after applying

Invert the image and use SCNR 

I think you're suffering from tilt on the top right of your image too

Okay, gone out tonight and it's still doing it. I guess I'll have to buy a 13.8v power supply? Only thing is I want the portability and not have to lug around a big PSU

Finally got round to completing my SHO rendition of the Cygnus Wall

I had a lot of problems with the mount for the last few months but that was down to my stupidity and daisy chaining extension leads, so tip of the day, don't be like me and do that

I might add more Ha since I only got 2 hours but the signal is that strong nonetheless that I may not.

Imaging telescope: TS Optics TS Photoline 90mm f6,6 Triplet FPL53 Apo CF

Imaging camera: ZWO ASI 1600MM Pro

Mount: Skywatcher HEQ5 Pro (belt mod.)

Ha: 27x300" (gain: 139.00) -15C bin 1x1

SII: 35x300" (gain: 139.00) -15C bin 1x1

OIII: 45x300" (gain: 139.00) -15C bin 1x1

Integration: 8.9 hours

C&C welcome

Matt

I really don't want to jinx it but I think it was down to daisy chaining the extension lead

Edit: I literally just jinxed it 

On a side note, the freq. is barely ever so I can cope with it. Of course it shouldn't happen anyway but oh well, at least I'm not throwing away a 1/3 of my frames

The only thing I can test at the moment is if me daisy chaining the extensions caused something as I've currently got the setup outside

I've plugged the brick straight into the reel so now I'll wait and see

Just now, fozzybear said:

Matt,

Is the extension reel at 30m 230v then attached to the power brick 12v then attached to your hub? or is the extension 12v

It's reel > extension lead > power brick > DCHub

The only reason I don't plug directly into the reel is that it doesn't have surge protection. Obviously with a new one I could do just that

I've got a HEQ5 Pro and I'm using a RPi with astroberry. I also have a 1600MM hooked up with the cooler running at about 30%. This is all running from a DeepSkyDad DCHub2 through a 12v 10A power brick I bought from Amazon

My guiding is okay at about 0.8"RMS but at random points (not periodic), either the RA or DEC will spike massively then recover quite quickly but this does mean I'm having to throw away quite a few subs which of course I don't want.

The possibilities of this being an issue would be either a dodgy extension reel since it is quite old, the DCHub, the extension lead or the power brick which could be potentially causing voltage drops.

I did have a dew heater but I've unplugged it since it was actually causing voltage drops when slewing and caused the mount to act sporadically. I doubt it's the mount either since I very recently serviced it myself and it still happens

Any thoughts?

Edit: Also to note that the extension reel is 10A not 13, could that be an issue? 

Edit 2: Not sure how safe it is to be doing this either but the extension reel is 30m long and I'm probably only using half of it so how much of a problem does that cause too?

Matt

How did you end up fixing this?