A320Flyer

Just an update:

I managed to get the roof open this morning and have a look at adjusting belt tension. On removing the two small access panels for the RA and Dec, a fair amount of rubber swarf was evident. Using a soft brush and a substantial amount of lung power, I cleaned in and amongst the gears and belt teeth. The belts themselves seemed to be adequately tensioned but the adjusting grub screw on the RA axis was quite loose. I nipped this up to finger tight and closed up the access panels. 
Now, it’s forecast to be 100% cloud cover here for the next four days but I will test my guiding at the first available opportunity and report back. 

Bill

1 hour ago, wimvb said:

The 10 s period is caused by a belt that is too loose. You just need to remove the RA belt cover and tighten the belt a little. I had the same with my AZ-EQ6 and this fixed it.

Btw, have you tried guiding without PPEC (does the EQ6-R have mount stored PPEC?). The Predictive PEC guiding algorithm in PHD, together with multi-star guiding usually gives good results.

I’ll give the belt a little tighten tomorrow 👍

I understand from the developer of GS server that it writes the ppec to the mount. Guiding is a little better with ppec enabled than without. 

Thanks. 

Thanks for that, Michael. As you suggest, I’ll wait to see if any eq6r-pro experts chip in. 
Bill

Hi,

I have a new EQ6R-Pro mount and recently moved over to NINA for imaging, which entails using PHD2 for guiding.

I have calibrated succesfully, run the Guiding Assistant, applied the recommendations, run the PPEC Training in GS Server and enabled the PPEC.

After adjusting the guiding agressiveness for RA and Dec, I can achieve a Total RMS Error of around  0.7-1.0 on a typical night. 

My issue is that RA rms is always worse than Dec rms (usually by a factor of around 3). No matter what adjustment I make , I cant seem to improve this.

Is this typical? Should the rms errors not be very roughly similar on each axis? My stars are usually quite round, although I suspect they could be a little tighter.

I have attached last night's guide log. The two longer periods of guiding are those at either side of the meridian flip.

Can anyone offer any explanation or advice?

Many thanks

Bill

PHD2_GuideLog_2022-02-27_190003.txt

17 hours ago, malc-c said:

Bill, to quote TimK's reply to your post on Cloudy nights

According to EQMOD prerequisites  website the EQ6R-Pro does indeed have 180 teeth on the RA worm gear, giving 479.6894 seconds.  

Hope that helps

Yes, thanks. I’ve now got everything I need. 👍

Can someone explain how to calculate the worm period on a EQ6R-Pro. I know it’s 479sec or thereabouts but how do you calculate it it based on the mount’s specification details. 
Thanks

Bill

On 15/10/2021 at 04:33, DaveSw said:

I have a circuit using and Arduino to vary the light intensity (for various filters) that will be controlled by the Kstars/Ekos/Indi software I use.

Would this work with NINA? That would be very useful. Are you willing to share?

On 09/10/2021 at 09:23, Newforestgimp said:

Hi Bill,

I have no means to print these but intrigued all the same , do you have a design for an RC8” ? & how much would you charge for making and posting ?

regards

Andy

Sorry, just saw your post. 
Unfortunately, I don’t have a design for this. The difficulty is that there is a limit to what can be printed on the small-sized heated bed of the printer. Up to about 120mm aperture for a refractor is about as far as you can go. ☹️
Bill

Cheers. I have the scope but waiting on the flattener. Tried imaging with my A183 but stars were horrible without the flattener. Your stars are excellent so I’m looking forward to getting the FF. 
Bill

Very nice. Did you use the dedicated 0.8x reducer?

Hi,

Here is my attempt. Processed in PixInsight with the following workflow:

Combined Sii, Ha and Oiii to give SHO colour image

Stretched using HT

Colours remapped to Hubble Palette with Curves, using appropriate ColourMasks

Saturation increased

Ha used as Lum

Slight Deconvolution

NR using TVGD and MMT

Stretched using HT

Contrast increased on high SNR areas using iterations of LHE

Detail increased in background using HDRMT

Lum merged with SHO

Dark Structure Enhance using the DSE Script

Small stars decreased in size/intensity using MT and a star mask

Transferred to Photoshop for final colour balance and slight sharpening of the smaller details.

I rotated the canvas 180deg so that the highlights appear to be lit from above, as I think this looks more natural.

Sh2-155.tif

Having seen the latest very interesting posts on small observatories, attached is a write-up I did for my local Astro Society on a very small imaging observatory in my back garden. Its been operating very successfully now for a couple of years without any real issues. I have only very recently modified the lift-off lid so that more of the panel against the fence remains in place - this made the roof a lot lighter and much easier to flip open. I have since also installed an EQ6R-Pro with dual imaging capability, which is significantly bigger than the HEQ5 it was originally designed for, so I had to cut down the pier a little to accommodate that  - otherwise its all as described. I hope this might be useful to anyone thinking of doing something similar.

Bill

The Garforth Nano Observatory.pdf

I got myself a Sharpstar 61EDPH ll so I had to make a Flats Box for it. I've attached the files if any good to anyone 

Bill

Sharpstar 61EDPH ll Flats Box.zip

I look at an RGB image a bit like a cake mix or cocktail - it’s difficult to extract the individual ingredients once they are all mixed together. In an RGB image, the luminance is perceived and if we want to extract a good approximation of it, we need to say roughly how we think it is made up. Hence RGBWS. 

Here is a quote from a well known PI guru on the PI Forum:

well it gets pretty deep into color theory but for the purposes of PI it modifies the R/G/B channel weights for the purposes of extracting something closer to true Luminance when extracting L* from an RGB image. you want them to be weighted equally which is why you change the weights to 1,1,1.

the human eye is most sensitive to green so with default channel weighting in an RGB image the green channel participates more in the calculation of L* than the other channels. if you're trying to get an equivalent L image that might have come from an L filter, there's no green bias there - all wavelengths pass equally thru the filter.

it doesn't seem to do anything because it doesn't really change how the data is displayed, just how it is interpreted behind the scenes.

On 22/09/2021 at 11:40, Viktiste said:

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?

4. 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. this ensures that the R, G and B channels all contribute equally. You could use 0.33, 0.33 0.33 as long as they are all egual.  If you used 1.0,0,0 say, you would effectively just extract the Red channel.

2. No mask. Just three HT and four Curves something like this:

No NR on RGBHa; the Convolution carried out on 9. sufficiently dealt with the noise.

After the PI process, I transferred to Photoshop to smooth the IFN. I duplicated the image, made a mask for the galaxies and blurred the background using the Dust & Scratches filter, reducing the opacity to suit. I prefer PS for doing this but if you wanted to do in PI, you could probably do it by using MLT to switch off the lower layers and blend the results with PixelMath and a luminance mask.

Hope this helps.

Bill

On 15/09/2021 at 20:37, Viktiste said:

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

Thanks for your comment. I hope this helps.

 Referring back to my saved PI Project:

1.       Dynamic Crop and DBE on all masters.

2.       Renamed masters as Ha, Lum, Red, Green, Blue.

3.       Added Ha to Red using PixelMath, straight Red+Ha, rescaled, no mask. Renamed this as RedHa

4.       Added Ha to Lum using PixelMath, straight Lum+Ha, rescaled, no mask. Renamed this as LumHa

1.       Channel Combination using RedHa, G and B. Renamed this as RGBHa

2.       BN and CC on RGBHa.

3.       Masked Stretch on RGBHa.

4.       RGBWorkingSpace on RGBHa with all channels as 1.0.

5.       Extracted the Lum from RGBHa.

6.       Several small saturation boosts in Curves, using the extracted Lum as a mask.

7.       SCNR.

8.       HT to balance the channels.

9.       Convolution to slightly blur.

10.   Repeat RGBWorkingSpace on RGBHa with all channels as 1.0.

11.   Set this RGBHa aside for later.

1.       Noise Reduction on the LumHa using Jon Rista’s method (https://jonrista.com/the-astrophotographers-guide/pixinsights/effective-noise-reduction-part-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.

3.       HDRMT to compress the dynamic range of the galaxy cores, using 5 wavelet layers, de-ringing on, lum only on, no mask.

1.       If required, extract the Lum from RGBHa. Balance this Lum using LinearFit, with LumHa as the reference. Add this extracted Lum back into RGBHa using ChannelCombination, using CIE L*a*b*, with a* and b* disabled. This ensures that RGBHa is at a similar brightness as, and ready to receive, LumHa as luminance data. This step may not be necessary if both the luminance and colour are already at similar levels.

2.       Add LumHa into RGBHa with ChannelCombination, using CIE L*a*b*, with  a* and b* disabled.

3.      Make a star mask for the smaller stars and reduce their size/brightness using MT.

4.      Rename as LumHaRGBHa.

Thanks for all the help on this.

I used PHD2's Polar Drift Align routine to get better PA. I then re-ran the GA. I let it run for longer than the minimum recommended 2mins and I noticed that the RA drift line started to come back on itself (see attachment). This indicated to me that the RA drift was primarily down to PE.

So I used EQMod's Auto PEC routine to record a PE curve and play it back as PEC. I then re-did PHD2's GA and this gave almost perfectly flat RA and DEC drifts (albeit with the general raggedness caused by seeing). 

I followed this up with an imaging session where guiging RMS was consistently less than 0.5arcsec. 🙂 

Again, thanks for all the help.

Bill

55 minutes ago, Tomatobro said:

 sidereal speed difference after 2 mins unguided with 13 arc secs drift . Should guide ok.

Thanks for your response. Yes, it does seem to guide OK but I'm a little concerned that it should really track better than it does. All other screen grabs I've seen of a GA plot generally shows a random variance - not a dive like I've got. Should I be concerned?

Hi,

I'm trying to setup PHD2 for guiding. Everything is connected and I can calibrate and guide. However, when I run the Guiding Assistant to fine-tune the settings, I see a marked drift in the Ra axis (see attached screen grab and log file).

This is a brand-new EQ6R-Pro, straight out of the box.

I have pretty good focus on the guide star, good balance and reasonable PA.

Any suggestions as to cause and how to rectify would be very much appreciated.

Thanks

Bill

PHD2_GuideLog_2021-08-22_163523.txt

Most sit on the outside of the dewshield. It’s only the SW150P that sits inside the tube. I had to do it that way because of the limit on the size I could get on my print bed. HTH

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

Bill

23 minutes ago, bottletopburly said:

Do you have pictures of finished product bill .

Pictures of my SW150P and SW ED72 boxes, plus an exploded Inventor pic of the SW150P box.

Hi.

My name is Bill and, couple of years ago, my friend Chris and I began making Flats Boxes for our local Astro Society members. They were 3D-printed and custom made to fit perfectly over the top of your scope. They came as a kit of parts that was easily put together using very basic DIY skills. They took about 1hr to build (just a tiny bit of soldering) and produced an excellent flat field.

We were going to try and market them to other Astro Societies as a way of fundraising but the pandemic put paid to that.

Nevertheless, as a “Thank You” for all the help that this forum has given us over the years, Chris and I would like to donate the designs and print files to the community.

There are Flats Box designs to fit the following scopes:

ED80-102

Esprit 120

Starwave 70ED

SW ED72

SW 150P/150PDS

Takahashi FSQ-85EDX

TMB105-65 Thomas Beck

TS70

WO12134 LZOS

The designs have been done using Autodesk Inventor, which was then used to export the STL files for printing. Both the IPT and STL files are included in the attached Zip file. All you need to supply are some daylight LED’s, some lengths of cable and a power supply.

A basic set of instructions and an information leaflet is attached.

They were generally printed at 50% infill using RepetierHost.

Obviously, no warranty etc, etc, is provided. All we ask is, if you modify one of the designs for use on a different scope, maybe consider posting your design back here for others to use.

We hope they are of some use to members.

Clear Skies

Bill and Chris.

Flyer.pdf Instructions.pdf Flats Boxes.zip

Hi,

Excellent data once again. This is my go at processing. Mostly done in PixInsight, with final tweaks in Photoshop:

Slight Crop on each channel

DBE on each channel

Slight NR (MLT) on R, G and B

Combined R, G and B into RGB colour

RGB stretched with HT

SynthLum created by summing Lum, R, G and B

Slight NR (MLT) on the SynthLum

SynthLum stretched with HT

HDRMT on the centre of the Iris

Small iterations of LHE on the centre of the Iris, progressing outwards to the dusty clouds with increasing Kernal Radius

Combined the SynthLum with the RGB using Channel Combination

Starnet++ to shrink the stars slightly, then MT to further reduce the size of the very smallest stars

Transfer to Photoshop as a 16bit TIFF

Curves, Levels and Selective Colour tweaks

Flatten and save as JPEG

Cheers

Bill

On hindsight, I felt that using the SynthLum made the stars too soft and I lost definition. This is basically the same LRGB but using straight Lum.

Hi,

Excellent data. So pleased to be given a chance to process it. Anyway, this is my go at processing. Mostly done in PixInsight, with final tweaks in Photoshop:

Slight Crop on each channel

DBE on each channel

Slight NR (MLT) on Ha, R, G and B

Combined R, G and B into RGB colour

BN and CC of the RGB image

RGB stretched with Masked Stretch to preserve the colour

Ha stretched with HT to match mean intensity of the RGB

Ha added to the RGB in blend mode Lighten (MAX function in PixelMath) to give HaRGB

Lum given a very light Deconvolution, using a mask to protect the stars and background

Slight NR (MLT) on the Lum

Lum stretched with an initial application of ArcSinh, then HT to match mean intensity of the HaRGB

Slight LHE on the galaxy arms (using the same mask used for Deconvolution)

Ha added to the Lum, again in blend mode Lighten, to give HaRGB

HaRGB intensity matched to Lum with LinearFit

Combined the Lum with the HaRGB using Channel Combination to give LumHaRGB

Transfer to Photoshop as a 16bit TIFF

Curves, Levels and Selective Colour tweaks

Slight reduction in size of the smaller stars

Flatten and save as JPEG

Cheers

Bill