symmetal

Filter wheels are made such that the thread points towards the camera. Likewise when fitting a filter onto an eyepiece. The more reflective (mirrored) side should then be pointing towards the sky, which is what you want to minimize reflections in your images or views. As you say some imaging trains force you to mount them the other way way round. The 2" UV/IR cut in my ZS61 used for imaging with a OSC camera has to go thread towards the sky. However both sides of this filter seem to have the same reflectivity so it doesn't really matter which way round it is. For unmounted filters there should be an arrow on the rim of the filter (for those filters that matter) and the arrow should point towards the sky. Here's an answer from Baader-Planetarium on the subject. Alan

Great new tutorial. I based my workflow on your old tutorial and was never really happy with the junction between the surface and proms after processing them separately. I like your dodge and burning method on the proms now and processing the whole image at once. I'll try it on some of my images I took last summer to see how they turn out. Alan

I agree with kens post. Here's a chart I'd previously made showing the sky background level to achieve the read noise swamping values that kens mentions. I use unity gain all the time (laziness to avoid multiple darks). Also the offset used affects the sky background level required. I use a constant offset high enough to avoid black clipping at any gain setting. The sky background is pretty much the median value of your image, if the image doesn't have large amounts of nebula in it, or hover the curser over the darkest area of your image to get the actual sky background value. If you use different gain or offsets to those shown I can make a chart specific for you if you want. I did post the excel spreadsheet file on a previous post so you can fill in your own values on that if you have excel or OpenOffice. These are really only useful for LRGB imaging. For narrowband, you'll never achieve the required sky background level unless you're in a very light polluted area. I would need to expose well over an hour to achieve it with Ha so I just expose as long as convenient, normally 600 seconds. Half unity gain is actually 79 and twice unity is 199 but I've used the figures Zwo prefer. (6.0dB (or 2 x gain) is 60 ASI gain steps) With my bortle 3 skies I find 60s for L and 180s for RG and B gets me close to 10x RN^2 sky backgrounds. Alan

I missed your post about the colour shifting when looking at Venus. You're right that atmospheric dispersion would appear the same at all positions when using the barlow (if it was a good barlow ) Also in your initial moon image the fringing is too large for the size of the image, to be just dispersion. Didn't mean to lead you down the wrong path , but it does give you something to be on the look out for in future when you've obtained higher quality equipment. Alan

I find this graph from the BAA article I mentioned above is a bit easier to interpret. At first glance Merlin66' graph gives the impression that red and blue are dispersed in opposite directions. Alan

In 'Setup\Catalog' click the catalog tab and ensure the max FOV number for the catalog required is set high enough to display in the selected FOV number. 10 means display it at all FOV selections. In 'Setup\Chart, coordinates' click the Object filter tab and adjust the 'Deep Sky Filter' settings to taste. Unticking 'Filter deep sky objects' will show the DSO catalogs at the settings set in the Catalog tab previously. This may give a cluttered view so perhaps just reduce the 'Limiting size' setting (and maybe the 'Limiting magnitude') on the 'Deep Sky Filter' settings for the higher FOV numbers,until the abell or other catalogs show as required. Alan

The main cause of the colour fringing would be atmospheric dispersion where the atmosphere behaves like a prism and the blue light is bent more than the red as it has a shorter wavelength. The lower the altitude in the sky of the target the worse it gets as the light travels through more atmosphere. Here's an article from the BAA explaining it. Here's an article from Ian Morrison which also gives some methods of correcting it with various software programs. Alan

I like the description on the Amazon site James posted above which describes it as having a dual LED nixie tube display. I'm sure there aren't many people under 50 who know what a nixie tube is. 7 segment LEDs replaced nixie tubes in the 1970s. Alan

That should be no problem. The series diodes aren't necessary. Alan

If the batteries are permanently in parallel that is fine. Diesel-electric submarines have loads of lead-acid batteries in parallel. If not permanently connected together then a diode in series with each battery is recommended to stop high currents (and sparks) if one battery is much flatter than the other when you connect them together for charging. Use a schottky diode as these have a lower forward voltage drop. Ideally you need to increase the float charging voltage from the charging controller to compensate for the diode drop. Alan

Very impressive Adam for such a short integration time per panel. Alan

Glad it all worked without any problems Adam. Most satisfying isn't it. Alan

Any noise on the power rails can be greatly reduced by a 2 stage LC filter. I run my astro setup from a single SMPSU with a 2 stage LC filter in each distribution output, values tailored to what that output is supplying. This also isolates noise created by the device the output is connected to from affecting the other outlets. Probably overkill but it doesn't cost much extra and gave me an excuse to make a PCB. As many cameras are now powered from USB, which will be very noisy anyway, and they don't seem to be affected by it, they have their own on board filtering methods. As regulated power supply noise is all high frequency then only small values of L and C are needed so take up little space. Probably cheaper than a bank of ultra low noise regulators. Alan

Glad you've found it. You're right I suspect in that the Linux folder layout will be very similar. Alan

AppData is a 'hidden' folder so on the screenshot above select the 'View' Menu at the top and under 'Show/Hide' section select 'Hidden items'. Can't help with the Linux location but I'm sure someone else can help. Alan

These features are specific to each user and so are located in the Users files and not the main Stellarium program location. Try here C:\Users\[Name]\AppData\Roaming\Stellarium Alan

'Dialogue based' in EQMOD deletes any previous sync points that are close to the latest one, so that you don't end up with many sync points close together which causes pointing errors in EQMOD as the others have said. As this didn't cause a problem for you using APT, I assume APT issues commands to the mount to just move NSEW by a certain amount when centring the image. SGP appears to ask the mount to move to a specific location when centring. Because of the incorrct pointing model due to multiple close sync points EQMOD just reports it's already at that location even when it's not in reality. Your 51 pixels is the error in the EQMOD pointing model at that location. If you slewed and centred to a new target well away from your previous one, the centring would probably work OK even using 'Append on Sync' but doing a mosaic you will end up with many close sync points and problems using SGP. I should have mentioned this in my reply yesterday, but thought it had already been mentioned in the thread, but assumed the wrong thread. Alan

In the past the Scope focal length setting had no effect on the program operation and was just used as an entry in the fits header. The image scale set on the camera tab was all SGP needed to know. Maybe something's changed now. As long as it's working again now, is all that matters. Alan

Yes, you may as well use the flattener as it can only make the stars better, considering adjusting the necessary spacing is fairly easy with this model. A standard 30mm T2 extension tube with the flattener set to around 3mm should be a good starting point. Alan

The 67.7mm distance is with the flattener adjustment at zero. Using a DSLR and T2 adapter you have the standard 55mm between the front of the T2 adapter and the sensor. Hence the setting of 12.9 on the flattener adjustment to make the total 67.7mm distance, (within 0.2mm). You can use this 0-15mm adjustment on the flattener to achieve the total of 67.7 when using your filter drawer and extension tubes etc. Alan

I might have been better using my ZS61 at 360mm with the 071, as I cropped a fair amount off the RC51 image. This is the full frame view from Startools processing. Keeping my camera in a sealed box with desiccant when not in use (most of the time ) seemed to have solved the icing problem which this camera is prone to. Thanks David, I don't have Pixinsight but am fairly happy with using levels and masks in PS so will try what Olly has suggested. Thanks Olly. Good idea about applying NR to the whole image and layer masking back in the areas that need to remain sharp. I had done that applying sharpening to just the bright areas, but will have another go. My ASI1600 mono doesn't seem to produce such hard edge halos like this so was wondering if OSC may be more prone. The 071 front glass is fairly close to the sensor which may not help in that respect. I did take some 20sec exposures for the Trapezium but hadn't added them into the image yet. I'll try that next. Alan

Thank you for the comments and 'likes' I suspect you're right. My FLT98 and ZS61 don't give hard edge halos so was hoping the RC51 would be similar. I did use a Baader 2" UV/IR cut mounted in the RedCat. I can try another reprocess with less stretch and blend the halo stars in from that one. I probably wound the saturation back too much too to make the halos less obvious. The default from Startools was way over saturated. I'll have another go. Not having any luminance, more subs will be needed to reduce the noise some more but the moon came up stopping me at the time. The RedCat seems to hold focus throughout the night so a check at the start seems sufficient. I did check it again mid way through with the bahtinov mask but it was still good. Alan

Centre crop of my first 'proper' image from my RedCat51 and ASI071 one-shot colour camera. No ice on sensor this time. Had two clear nights a few weeks ago and just got around to processing them. HEQ5 mount, ZWO mini-guide scope and ASI120MM guide camera. 100 x 3 min subs, unity gain. Stacked in AstroArt, processed in Startools and final tweaks in Photoshop. The darker bits are still a bit noisy so could do with some more subs. Distinct halos around the bright stars are also rather noticeable. Whether this is the scope or the camera, I'm not sure. I could try the 071 with my ZS61 next time to see. VdB 42, 46 and 54 are also visible in the image. Alan

There will always be backlash present as the lakeside motor system is geared down quite a bit. It's always best to eliminate it if possible. It can be set in the lakeside unit itself by its utility prog, or using the buttons on the unit, but it's easier to let SGP do it as it's easier to change. With my two lakeside focusers I use a backlash setting of 30, and set it to always work on inwards travel so that the focuser always reaches its completed position by an inwards movement against gravity. Setting the compensation too high doesn't really matter, it just means the focuser travels further back and forth each time it compensates. As your first curve segment is only slightly flatter on the V curve a, setting of 20 may be fine. If the first segment is then the same or slightly steeper than the second segment then your compensation is good and hopefully your final focus position will actually be at the bottom of the V curve and you won't get the error message. I can't remember as to whether compensation is enabled by default on the lakeside unit itself and set to some value. If you're going to set it by SGP it's probably best to check it's disabled in the lakeside controller so that the two systems don't try to do the same job. Alan

The 'HFR being outside the expected value' message can be a sign of the backlash compensation being insufficient. Is the first segment of the focusing V curve more horizontal compared to the second segment. If so when the final check image is taken by SGP it will not be at the bottom of the V curve causing the error message. The grub screws attaching the focus motor to the focus shaft can work loose causing increased backlash. Alan