M31 with Sharpstar 61EDPH ASI1600mono

[Tommohawk]

So this is sort of first light with the 61EDPH. I say sort of because I had a short window of clear sky previously which I used just for testing - the upshot was that I got unacceptable chromatic aberration so put serious imaging on hold until I could sort it - and I think I have succeeded.

First thing to say is that the field is lovely and flat - much better than anything I could achieve with the TS72/reducer combo which I bought previously and returned as unsatisfactory which fortunately 365 Astro were happy to exchange. There is an example image posted with the advertising spiel which shows the flat field so I was fairly confident. The chromatic aberration is a big issue but it's not easy to determine if the scope is the issue, or the filters, or maybe a combination. Reading around on this at length is appears the ASI1600mm is very sensitive in the short blue/UV area, and the ZWO blue filter passes very short wavelength blue. So as great expense and with fingers and everything else crossed I lashed out on an Astronomik blue filter which doesn't pass much below 420nm.

The results are much better and the huge blue CA is now controlled. Couple of things - the 31mm filter is only 1mm thick, so its nowhere near parfocal with the R and G. But I refocus between filters so this isn't an issue. Also it has a metal frame which sits nicely in the ZWO EFW, but requires slightly longer screws to hold it in place - available from well known auctions site for about £1.50. One further thing - the blue stars are now way tighter, but now the red dominate slightly. This isn't a big issue I don't think. I wondered if the Astronomik blue filter just seemed better because it passes less light overall, but when doing flats alongside the orginal blue the exposure time was shorter for the same histo which suggests this isn't so.

I haven't done Lum cos my Lum is always awful - very poor resolution. I have some thoughts on that, but that's for another thread I think.  For this I combined RGB and a handful of Ha in APP to make a pseudo Lum image. 

Anyhow, I tested it on M31 - an old favourite but lots of stars to check out the CA. Processed with Astropixel processor which I am becoming  big fan of, but combined and processed in PS still. I did a big stretch version for the galaxy, and a low stretch version for the star layer which  seems to have worked OK. I didn't do anything different for the core, but it hasn't blown out too much I think.

There's plenty better examples but this was captured in a pretty brief period over 2 nights whilst entertaining over Xmas so slightly disorganised! 

BTW the 55mm reducer back focus was achieved with: 16.5mm F/M ZWO spacer + 11mm F/F ZWO spacer + 1mm M/M adapter to 20mm EFW + 6.5mm camera flange to sensor. 

14x300s Ha, 90x60s R, 56x60s G, 63x60S B. All at -15 degC. No dithering so the sky a bit streaky - that's the next issue to deal with!

As ever happy for any thoughts and benign criticism!

Edited January 16, 2020 by Tommohawk

[tooth_dr]

Really lovely detail Tom and nicely framed.  I'm not sure if there is a slight colour cast, I cant decide!

[Davey-T]

Great result for all that effort Tom, just bought a SharpStar 150mm f2.8 HNT, first imaging light last night, got a couple of issues so need more clear skies to play about with it.

Dave

[vlaiv]

Apart from the fact that color balance is quite a bit off, and that you have issues with background and red star halos - very nice image indeed. So let's address some of those issues.

First off, in order to control star size you should really use lum - but not any lum filter. If your scope is not well corrected - and by the looks of it and your story - it seems to be not so well corrected - you need to use "special" lum filter - astronomik L3 (I think, let me check that) - indeed it is L3:

It will prevent bloating from both blue side and also from red side of things as it finishes rather early on both sides of spectrum. Bloating is due to unfocused light - and most of it will come from either sides of spectrum. Cut those "wings" and you have yourself smaller stars.

Since their RGB filters also follow this - L3 curve, maybe swap red as well?

Now for background. I'm seriously surprised that you have such background on ASI1600 cooled version. I've seen such background before and it almost always comes from CMOS sensors that are not cooled and as far as I gathered - it is related to offset and calibration.

What offset did you use, and how did you calibrate image?

[Tommohawk]

1 hour ago, tooth_dr said:

Really lovely detail Tom and nicely framed.  I'm not sure if there is a slight colour cast, I cant decide!

Thanks and thanks for the other likes!

1 hour ago, Davey-T said:

Great result for all that effort Tom, just bought a SharpStar 150mm f2.8 HNT, first imaging light last night, got a couple of issues so need more clear skies to play about with it.

Dave

Thanks Dave - I really liked the look of the f2.8 - would be interesting to see how it performs. wondering what issues you  might have - hopefully just teething troubles 

53 minutes ago, vlaiv said:

Apart from the fact that color balance is quite a bit off, and that you have issues with background and red star halos - very nice image indeed. So let's address some of those issues.

First off, in order to control star size you should really use lum - but not any lum filter. If your scope is not well corrected - and by the looks of it and your story - it seems to be not so well corrected - you need to use "special" lum filter - astronomik L3 (I think, let me check that) - indeed it is L3:

 

It will prevent bloating from both blue side and also from red side of things as it finishes rather early on both sides of spectrum. Bloating is due to unfocused light - and most of it will come from either sides of spectrum. Cut those "wings" and you have yourself smaller stars.

Since their RGB filters also follow this - L3 curve, maybe swap red as well?

 

Now for background. I'm seriously surprised that you have such background on ASI1600 cooled version. I've seen such background before and it almost always comes from CMOS sensors that are not cooled and as far as I gathered - it is related to offset and calibration.

What offset did you use, and how did you calibrate image?

Hi Vlaiv - thanks for your comments. Yes I wondered about the Astronomik LUM filter - it may well be much better. Trouble is they cost a bomb, and the same is true for the red which might also be better than the ZWO red.

Its frustrating because I've had good results gernally with my Newtonian with the ZWO filter, and having lashed out on a new refractor looks like I'm stuck with  needing new filters - will probably have to wait a while. 

Re the background - its not perfect but I'm not sure what defect you're referring to? It's a bit streaky probably due to fixed pattern effects which this camera is known for and apparently should fix with dithering. Cant recall what offsets I used - same as normal. Calibration was done in APP with darks, flats, and dark flats.   

[vlaiv]

3 minutes ago, Tommohawk said:

It's a bit streaky probably due to fixed pattern effects which this camera is known for and apparently should fix with dithering

Dithering will certainly help there, but this should not happen regardless. I never saw it in my images with ASI1600, but have seen it with other sensors where I could not calibrate it properly.

I'm specifically referring to this one:

background striation effect.

Now FPN of ASI1600 is something that will in principle calibrate out if you use enough calibration subs and residual will act like regular noise unless there is some disturbance in distribution - like improper offset and clipping. You can check if that is the case by examining your dark subs. Do any of them have ADU value of 16 anywhere in pixels? (or value of 1 if you divide with 16 each sub to make it 12bit value) - run a stats on any dark and see what the min value is - it needs to be higher than 16 if offset is properly applied.

 

[Davey-T]

1 hour ago, Tommohawk said:

Thanks Dave - I really liked the look of the f2.8 - would be interesting to see how it performs. wondering what issues you  might have - hopefully just teething troubles 

Got a thread in the telescope section, only took a few shots with DSLR the other night, seems to be a fair bit of coma and very dodgy stars in one corner.

Ordered an expensive HG laser collimator and attachment for fast scopes as recommended by somebody so won't do any fiddling until it arrives

Dave

[Tommohawk]

12 hours ago, Davey-T said:

Got a thread in the telescope section, only took a few shots with DSLR the other night, seems to be a fair bit of coma and very dodgy stars in one corner.

Ordered an expensive HG laser collimator and attachment for fast scopes as recommended by somebody so won't do any fiddling until it arrives

Dave

Had a look at that thread - I guess fast scope with big sensor is going to need spot on alignment. But the idea of having to fettle a brand new scope always seems a bit wrong! Maybe inevitable I guess. Good luck!

 

13 hours ago, vlaiv said:

Dithering will certainly help there, but this should not happen regardless. I never saw it in my images with ASI1600, but have seen it with other sensors where I could not calibrate it properly.

I'm specifically referring to this one:

background striation effect.

Now FPN of ASI1600 is something that will in principle calibrate out if you use enough calibration subs and residual will act like regular noise unless there is some disturbance in distribution - like improper offset and clipping. You can check if that is the case by examining your dark subs. Do any of them have ADU value of 16 anywhere in pixels? (or value of 1 if you divide with 16 each sub to make it 12bit value) - run a stats on any dark and see what the min value is - it needs to be higher than 16 if offset is properly applied.

 

For now I'm still imaging with SharpCap - we have discussed before the potential issues with not using the Ascom driver although this doesnt seem to be an option any more. Gain is 139, offset 25. I am looking at moving to NINA mainly because dither with Sharpcap isnt straightforward. But NINA has its own issues - it looks very promising as a comprhensive control and imaging suite, but the imaging module has too many quirks for my liking. Probably just a matter of finding time to get to grips with it.

My ASI is the cool, not pro - not sure if that makes any difference. Also not sure how to check the ADU values in the darks - can I see this with FITS liberator? FIT lib image headers shows Gain 139, BLK LEVEL 25 - this is the offset maybe?

[vlaiv]

11 minutes ago, Tommohawk said:

Also not sure how to check the ADU values in the darks - can I see this with FITS liberator? FIT lib image headers shows Gain 139, BLK LEVEL 25 - this is the offset maybe?

Don't think it makes any difference that your camera is not pro - neither is mine and I've never had those issues. It is quite possible that SharpCap is for some reason at fault here, but just to be sure - fits liberator will give you details that you want:

This is one of my 240s darks at -20C with offset 64, it has min value of 80 (needs to be larger than 16).

There is one more thing that you can check to see if everything is all right (I've come across that being issue so we can make sure all is fine in your case) - make max zoom on preview and move mouse cursor over the image and observe single pixel values that are being displayed in info section - pixel values need to be divisible with 16.

If you notice any number that is not divisible by 16 (and it is easiest to see that if any pixel value is odd rather than even - then it's not even divisible with 2), then we have a "problem" of some sort. This needs to be done on uncalibrated raw files straight from camera (darks for min value, and both darks and lights for values divisible with 16).

[Tommohawk]

5 hours ago, vlaiv said:

Don't think it makes any difference that your camera is not pro - neither is mine and I've never had those issues. It is quite possible that SharpCap is for some reason at fault here, but just to be sure - fits liberator will give you details that you want:

 

This is one of my 240s darks at -20C with offset 64, it has min value of 80 (needs to be larger than 16).

There is one more thing that you can check to see if everything is all right (I've come across that being issue so we can make sure all is fine in your case) - make max zoom on preview and move mouse cursor over the image and observe single pixel values that are being displayed in info section - pixel values need to be divisible with 16.

 

If you notice any number that is not divisible by 16 (and it is easiest to see that if any pixel value is odd rather than even - then it's not even divisible with 2), then we have a "problem" of some sort. This needs to be done on uncalibrated raw files straight from camera (darks for min value, and both darks and lights for values divisible with 16).

OK thanks for that - have checked and all darks have min value 16, and all the pixels I checked on the darks and lights have values divisible by 16. Obviously I couldn't check all the pixels of all the subs!! Checked one from each of the Ha and RGB.

Re the LUM bandwidth it does seem likely that reducing this would be better, but here's a thought. If the scope/filter system isn't parfocal for RGB, ie it needs refocussing between filters, then one of things is true. Either the filters themselves aren't parfocal (which admittedly is now the case with my odd 1mm thickness Astronomik filters, but wasn't with the ZWO filters) OR the scope has a different focus for the various wavelengths. If the latter is true, then LUM subs will be doomed to poor focus because it wont be possible to focus RG and B all to  the same point. I cant help but think this is the case.

One way to prove which is true would be to try the RGB filers in the Newt - if no refocus required between R G and B, then this proves the filters are parfocal. And in that case given the need to refocus with the refractor, LUM will never be completely focussed.  

Either way, LUM is nothing more than the sum of R G and B data, so stacking the RGB into a super LUM must give the same result as the LUM - but possible better focussed. Admittedly if one is going the route of binning RGB and doing LUMs 1x1, then there may be a timesaving benefit in LUMS but only if perfectly focussed throughout the band.

Maybe there's a theoretical SNR benefit with LUMs?

[vlaiv]

4 hours ago, Tommohawk said:

Either way, LUM is nothing more than the sum of R G and B data,

Lum is much more than sum of R, G and B.

For example - if you were to create synthetic lum, and you took 1h of R, 1h of B and 1h of G and you stack those together - you will get poorer result than doing 1h of lum. Difference will be in read noise (if there were no read noise 1h of each R, G and B summed would be the same as single hour of Lum).

This means that 3h total of imaging will give you poorer result than single hour of lum. Lum is good, otherwise people would not use it.

4 hours ago, Tommohawk said:

and all darks have min value 16,

That is bad - it means that your offset is too low. You want none of your subs to have any value equal to 16. There is nothing you can do now to fix your data - but you can increase offset for future use. Make it larger than 50 or so (I use 64).

[Tommohawk]

Ok I take your point about noise with lum vs RGB pseudo Lum. But experience seems to show that that with my setup Lum lights are poorly focused. I need to try the experiment with the filters and the newt that I mentioned above.

Regarding the gain and offset I'm 99% sure I'm using the settings you recommended ages ago,  that is gain 139 offset 25. 

Maybe time and experience has shown that higher offset is better? 

[vlaiv]

10 minutes ago, Tommohawk said:

Regarding the gain and offset I'm 99% sure I'm using the settings you recommended ages ago,  that is gain 139 offset 25. 

Maybe time and experience has shown that higher offset is better? 

I'm sorry if I mislead you for those parameters, but in all honesty, I don't recall recommending using 25 as offset. I did recommend unity gain on more than one occasion (pretty much every time gain of ASI1600 popped up in discussion ) but really can't recall offset of 25 for this camera. As far as I remember, I did say couple times that offset of 50 should be fine and that I use offset 64 which might be too much but won't produce ill effects and is on safe side.

I also gave instructions on several occasions on how one should determine proper offset for their camera - exactly as I described above - you shoot bias subs - small number of them (dozen or so is enough) and stack using minimum (you want to see what is minimum value of sub minima) and inspect for minimum value. If it is equal to minimum value camera can record (usually 0 or 1 scaled with number of bits - in ASI1600 case it is 1 but since camera records 12 bit format and stores it in 16bit format - scaling factor is 2^(16-12) = 16, so minimum value will be 1*16 = 16).

[Michael Hogan]

Think of getting the Sharpstar 76EDPH later if the 61 can do this

 

[Tommohawk]

I didn't even know there was a 76edph! I think it has different optics though, possibly better - looks like a triplet.

The other thing is that the recommended flattener doesn't look like a reducer. So not so wide field and a bit slower I guess. 

The mechanical bits look the same though and it does seem pretty good in that regard. The focuser is nice and smooth and holds my Asi1600 with 7 position EFW no problems even when vertical. The only thing I'm not keen on is the single rather weedy screw that holds the clamshell. 

[Tommohawk]

On 18/01/2020 at 15:57, vlaiv said:

I'm sorry if I mislead you for those parameters, but in all honesty, I don't recall recommending using 25 as offset. I did recommend unity gain on more than one occasion (pretty much every time gain of ASI1600 popped up in discussion ) 

Well I wondered if I remembered wrong but I found the 139 gain 25 offset idea here. But TBH if it wasn't for the advice I've had from folk like yourself I wouldn't be getting any images at all.... So I'm not losing any sleep over it!

[vlaiv]

19 minutes ago, Tommohawk said:

Well I wondered if I remembered wrong but I found the 139 gain 25 offset idea here. But TBH if it wasn't for the advice I've had from folk like yourself I wouldn't be getting any images at all.... So I'm not losing any sleep over it!

Indeed, again, sorry for that - I remember now, there has been drivers change in the mean time (and couple more since) and indeed I've re done my dark after that with new settings.

[vlaiv]

28 minutes ago, Tommohawk said:

Well I wondered if I remembered wrong but I found the 139 gain 25 offset idea here. But TBH if it wasn't for the advice I've had from folk like yourself I wouldn't be getting any images at all.... So I'm not losing any sleep over it!

Just checked - Indeed, I myself was using 25 offset back in 2017 and have changed that to 64 in 2018. I do remember something about drivers update, but have no idea if it was related:

Here are some of my backed up files:

just a few months later:

Once again, I'm sorry to have caused confusion.

[Tommohawk]

Well.... I got diverted for a while from this because we had a spell of clear sky so I got busy with a new session. More issues with flats, so I'm back to this thread.

So whatever I do with the brightness setting, when doing darks the min value indicated below is only 16. I've tried setting the brightness in Sharpcap, or the offset in NINA to the maximum which is 100, and still this value is only 16. So whats that all about? 

Edit: I tried this initially with gain set at 300 which I normally use for narrowband, and the min value wont go over 16 no matter what the offset. BUT just tried it with Gain at 139, and then the min value is 432, with offset 100. However this is dependent on exposure length - with gain 139 and offset set to 100, I need minimum 8 seconds exposure to get the Min value to exceed 16.

So how is this going to work with short exposure flats? Cant see how I can fix that?

Edit 2. And now I find the results are ridiculously variable - I had this value to 160 with G139 OS 64 at 640 ms exposure. But when I try again its not the same. Its driving me insane

 

Edited January 25, 2020 by Tommohawk

[Tommohawk]

Hi Vlaiv... or anybody.. hoping youre still following this!

I tried using the ASCOM driver in NINA, and I tried reloading the ZWO driver, and I tried the earlier version of the ZWO driver. For darks, nothing seem to get the Min ADU over 16, unless I put the offset over approx. 90

Here's a typical dark, Gain 139 Offset 64 60s at -15.

Also one of the flukey ones which  I cant replicate - exp only 0.64s because I was trying to see how dark flats would work.

Any further thoughts?

2020-01-26_21-24-36_Ha_-15.00_60.00s_1.fits

G139 OS64 2s_00001 19_40_23_OIII.fits

 

Edited January 27, 2020 by Tommohawk

[vlaiv]

@Tommohawk

Here is what I think about it all:

On 25/01/2020 at 19:24, Tommohawk said:

So whatever I do with the brightness setting, when doing darks the min value indicated below is only 16. I've tried setting the brightness in Sharpcap, or the offset in NINA to the maximum which is 100, and still this value is only 16. So whats that all about? 

My position on using sharpcap to do DSO AP is quite clear - don't do it. Use Nina or maybe SIPS or SGP lite - these are all free to use and work well (in fact I did not try Nina, and I stopped using SIPS once I ran into trouble with large files - it mistook my ASI1600 mono subs for color of different size - maybe it was early drivers or maybe it was that particular version of SIPS which is now updated. In any case I use SGPro now, but I think any of listed should be better than SharpCap).

I'm not saying that SharpCap is not good - I'm just saying it should be used for other purposes - like planetary imaging and EEVA / live stacking.

Here is example why it's not best option:

We have two dark subs taken with same settings except for exposure length. First is one minute and second is 0.64s. But look at Mean value. There simply is no way that one minute exposure has lower mean value than 0.64s one, and certainly not by 50%. It is obvious that camera is working in different regime for these two subs. SharpCap is probably putting camera into mode for fast readout and that changes the way camera works (maybe producing offset issues, or offset instability or whatever).

On 25/01/2020 at 19:24, Tommohawk said:

Edit: I tried this initially with gain set at 300 which I normally use for narrowband, and the min value wont go over 16 no matter what the offset. BUT just tried it with Gain at 139, and then the min value is 432, with offset 100. However this is dependent on exposure length - with gain 139 and offset set to 100, I need minimum 8 seconds exposure to get the Min value to exceed 16.

I still think you should do Gain 139 / Offset 64 for your subs. Indeed this sub has 12 pixels with value of 16, but histogram is well separated from right side:

Here is same sub from my ASI1600 (also 1 minute exposure, gain 139 and offset 64):

Very similar looking graph. Only difference is that mine has min value of 224 while your has min value 16.

It could be that your camera has few "cold" pixels. Those pixels have really low value and you need to really pump your gain to raise their value enough. Since you only have 12 of them (according ImageJ and histogram):

I don't think you should worry too much about them. Dithering will sort this even if these are dead pixels (and I don't thin they are dead pixel, just cold, since this other sub shows that they indeed can hold value larger than "zero" / base value).

 

[Tommohawk]

OK, thanks, that's really helpful - you make it all sound so easy.... I guess you can take that as a compliment!!

I'll set my default offset to 64 and press on with NINA - I've been using it for these comparisons and in doing so have become more familiar with it. It does seem to have a number of quirks, but I guess I can adapt - of course we have so few decent nights for imaging I don't want to risk getting it wrong and losing a good night. 

I did wonder if perhaps there was a light leak on the shorter sub. I have a metal lens cap + metal foil but because I'm just tinkering I don't have a dark hood/dark room as I normally would for darks.

I'll play around with this a bit more and see if I can figure out why Sharpcap seems to be an issue. The author is very switched on so its hard to believe he's "got it wrong" but maybe as you say it's not primarily for DSO work and has some adaptations which aren't ideal.

BTW am I right in thinking you also keep with unity gain (139) for narrowband too? I've always had passable results with 300 gain, but maybe I should change.

[vlaiv]

12 minutes ago, Tommohawk said:

he author is very switched on so its hard to believe he's "got it wrong" but maybe as you say it's not primarily for DSO work and has some adaptations which aren't ideal.

It's not really down to sharpcap as a piece of software. It works well for what it was originally intended. It has more to do with the fact that ZWO has two different drivers and we can't be sure if those drivers talk to the camera in the same way (set same settings). Native drivers and ASCOM drivers. Facts are that:

1. ASCOM drivers take much more to download than native drivers. Native drivers can achieve 15+ FPS on full frame, but for me ASCOM download lasts almost a full second (so 1fps or less).

2. We see that subs coming from native drivers and ASCOM drivers are in some way different - mean ADU level does not behave as one would expect if things were "simple". We simply can't avoid conclusion that somehow these two drivers behave differently

On numerous occasions I've seen people having issues with SharpCap and native drivers when trying to do DSO imaging / long exposure. I can't tell if that happens with SharpCap and Ascom drivers and whether multitude of options in SharpCap (like brightness / contrast / white balance / whatnot) is simply confusing people and that is why they are getting issues.

For that reason alone I recommend people to stay away from DSO / long exposure imaging with SharpCap. Otherwise I think it is really good piece of software and I recommend it for planetary and EEVA use.
 

19 minutes ago, Tommohawk said:

I did wonder if perhaps there was a light leak on the shorter sub. I have a metal lens cap + metal foil but because I'm just tinkering I don't have a dark hood/dark room as I normally would for darks.

On next session, when you do full set of subs (flats, darks, flat darks and lights) - maybe post one of each so we can try to see if everything is in order and if there is some possible light leak. There is set of "sanity checks" that one can do on the data (histogram clipping, mean adu levels, simple calibration on single frame and looking for irregularities) to determine if everything seems to be in order.

20 minutes ago, Tommohawk said:

BTW am I right in thinking you also keep with unity gain (139) for narrowband too? I've always had passable results with 300 gain, but maybe I should change.

Only benefit that gain of 300 vs gain of 139 will have is lower read noise - ~1.2e vs ~1.7e. That is not major difference. In fact that is only ~x1.42 higher read noise on unity gain. Only impact of read noise is on many short vs few longer subs. Since no one is doing single exposure images and we all stack - it will be the matter of using certain exposure length.

Rule is simple - use exposure length at which other noise source becomes dominant over read noise. Let's say that Sky/LP noise becomes dominant at 1 minute and read noise of 1.2e. What sort of exposure do you need to get the same result from 1.7e read noise? We've seen that difference is x1.4 and LP noise raises like square root of LP signal which raises linearly with time. This means that you need x2 longer exposure (because sqrt(2) = ~1.41 = 1.7/1.2). You only need to use 2 minute exposures at unity gain and you will get the same result. Using minute and a half will get you like 90% there and not 50% - again it is the story of diminishing returns like sub duration in general - after a certain point, gains from going with longer subs are just too small.

I don't mind imaging at gain 139 for NB - just use longer exposure.

[Tommohawk]

3 minutes ago, vlaiv said:

I don't mind imaging at gain 139 for NB - just use longer exposure.

OK. Currently for NB I use Gain 300 offset 50 (but will switch to 64) and do 300s subs. Sky here is approx class 4 Bortle. So maybe gain 139 and keep with 300s subs? 

Also, whilst I'm busy picking your brain, what's your thoughts on the USB setting? 

 

1 hour ago, vlaiv said:

On next session, when you do full set of subs (flats, darks, flat darks and lights) - maybe post one of each so we can try to see if everything is in order and if there is some possible light leak. There is set of "sanity checks" that one can do on the data (histogram clipping, mean adu levels, simple calibration on single frame and looking for irregularities) to determine if everything seems to be in order.

That would be great thanks - I plan to redo flats and darks today. Not sure when I'll next get any lights though - might be a bit clear tomorrow, maybe enough to test.

[vlaiv]

6 minutes ago, Tommohawk said:

OK. Currently for NB I use Gain 300 offset 50 (but will switch to 64) and do 300s subs. Sky here is approx class 4 Bortle. So maybe gain 139 and keep with 300s subs? 

Also, whilst I'm busy picking your brain, what's your thoughts on the USB setting? 

Could you check one of your NB subs for background sky levels - that should tell us what the deal is. Easiest way is to run stats on selection without any nebulosity and check for median value (that will deal with any stars in selection).

I believe I have USB setting at 64 as well. I changed it to be the same as offset - simply because I did not notice any difference in my setup when changing that and I did not want to go very high with it.