symmetal

I did initially order a replacement set of tablets from FLO and opened up the camera to replace, them but icing occurred again when I next tried to use the camera after a couple of weeks. It's not worth taking the trouble to open the camera to replace or dryout the tablets, and potentially let in dust. The little screw on tube with a couple of tablets which Zwo used to include with the 1600, which fitted on the access hole I mentioned above, isn't supplied with the 071, or other cameras now I believe, but the access hole is still there on the side of the camera. The little tube was not effective as the volume of desiccant it contained was not enough, which I why I assume it's not included now. Alan

I assume you've cooled the camera as that looks very much like ice forming on the sensor. Try taking flats without cooling and I expect they will be fine. My 071 had the same problem the first time I used it. The flats show it clearly, but individual subs look fairly normal. It seems the 071 sensor chamber is not as airtight as other cameras and the desiccant tablets quickly get saturated. When not in use I keep my 071 in an airtight food container with a big bag of desiccant, and remove the screw on the side of the camera (under the black plastic sticker) which allows outside air to enter the chamber. This allows the internal tablets to transfer their moisture to the large bag outside. The humidity meter in the container reads 9% all the time. I haven't had any icing problems since. I've had it in use for several nights in a row with no icing issues, but when it looks like there will be no imaging for a while I put the camera back in the food container. 🙂 Alan

Do you find that the focuser value for what it believes is optimum focus tends to move in one direction. In other words each time you focus with the same filter the focuser position result tends to be a little less than previous optimum focuser position values, and that this trend continues from previous sessions. This indicates that the focuser is sometimes not moving as far as it should. The gull shaped final step indicates that for that final step, the focuser only travelled around half as much as it was commanded, either due to too much friction or possibly, but unlikely, slipping under gravity as the stepper motor wasn't powerful enough to hold it. There is no feed back from the motor to the control software so the focuser position values are just counts of the pulses sent to the stepper. It has no idea as to whether the focuser actually moved as commanded. If the focuser didn't move as far as was thought on the last step, then when the focuser moves outwards to the supposed optimum position for the final validation step it actually ends up further out than it 'thinks' it is. The focuser thinks it is at position 3860 but is actually at the physical position corresponding to say 3880, so the validation HFR is worse than it should be, hence the poor quality value. From the graph the optimum HFR should be around 1.3 but your validation is most likely significantly higher than that. I find that my validation HFRs are very close to the optimum HFR, and often slightly better, and the quality is 99 to 100% each time, so haven't experienced re-runs. With a smaller step size you will find that the fitted curve matches the lower values better as it likes to see a shallower bottom V shape rather than a sharp one. Alan

You can get 2 core stranded cable from many sites on ebay like this up to 4.5mm. At £22 for 10m it's not too pricy. 😀 Alan

I use ASTAP with SGP now, and it's much better than PS2 when your slews have missed the target by more than half a degree or so. If PS2 finds it in its first region of search it's a similar time to ASTAP, but ASTAP seems to solve in a couple of seconds even if you're several degrees away from the target. For the same error PS2 would take several minutes at best. I had PS2 set up to abort and blind solve if it didn't solve after about 10 regions. The only time ASTAP fails to solve and reverts to blind solving is when I leave the cap on. 😁 Alan

The other thing is maybe the focus friction screws to remove any slop in the drawtube are possibly too tight and the focus tube friction when it's near the top left of the curve is a bit too much for the stepper motor. This would cause the final check focus to be possibly reported as being outside the predicted optimum setting though. I don't know what autofocus system you have, but the lakeside ones have significant gearing, so can usually cope with fairly stiff focusers. Alan

Hi Gkarantzalos, Yes, that looks like typical Redcat coma on the left. Some early examples though were a lot worse than yours. I don't know how good the current versions of the Redcat are in comparison, but I'm sure FLO will help you out. 🙂 Alan

The 10x(R^2/P) equation seems to calculate the exposure when the sky electron flux equals 10xR^2 at unity gain. Using the website calc you linked I get 1.21 -e/pix/s with my ZS61 scope and ASI1600 at unity gain. Inserting that in 10x(R^2/P) gives me 24 secs. The exposure I need to achieve a 16 bit camera output sky background ADU = 10*R^2, (as per the formula I use, mentioned above) is around 75 seconds, three times the exposure. At unity gain the sky electron flux should be the sky background ADU contribution. The camera output sky background 16 bit ADU will be the sky background ADU contribution plus the camera offset, and adjusted for the bit depth of the camera when converted to 16 bit. Assuming the calculation for the sky background electron flux is correct, I'm trying to see where the discrepancy is occurring at the moment. 🤔 Alan

Your curve is only showing 7 steps. I use 9 steps which is the default i believe. It's more likely to ignore an odd sample. Also, your step size as shown is too large. You need a couple of samples down near the optimum setting for best curve fit. At your oprimum HFR of around 1.3 shown your first sample on the top right should have an HFR around 3 or 4. The curve should be more of a U shape rather than a sharp V. A step size of around 20 should be better. Backlash setting is fine. If it wasn't the first line segment of the graph (top right) would be less steep than the second segment. The exposure is important in getting sufficient stars bright enough to measure and not too clipped. Too far from optimum exposure will give an uneven graph. Also bin the auto exposures at least 2x2. The exposures I use at 2x2 binning are 2 secs for L, 5 secs for R, G & B, and 25 secs for NB. The only time mine ever does a focus rerun by itself is when the initial focus setting is too far off that it doesn't go through a minimum after around 7 steps. It then does a large focuser shift and tries again. Alan

Your impressions are right if recorded means output from the camera. 🙂 The camera will record in 12 bit (normal mode) or 10 bit, (high speed mode). If you select 8 bit o/p it will discard the necessary number of LSBs and if you select 16 bit o/p it will append the necessary number of zero value LSBs. Alan

An 8 bit image discards the 8 least significant bits of the 16 bit image so the overall image brightness or histogram won't change. The histogram is very useful to ensure you don't clip the exposure. 🙂 Thanks for the detailed explanations though vlaiv. Very useful, and also to InFINNity Deck's article he linked to in his post, which helped explain the method used in planetary imaging to determine optimum image scale. Alan

That's not as bad as it looks Dave. You have a double peak for each colour and a shallow slope to the left which implies that the vignetting is not very symmetrical about the centre of the image for some reason. The peaks for the two rightmost colours are closer together so their individual double peaks have merged together. The whole histogram is well away from being clipped at the edges so it should calibrate correctly. This assumes that your light source is even over it's whole area. You could rotate your light box by 90 and 180 degrees and/or shift it left or right so the camera is viewing a different area, and see if the flats still have the same shape histogram. If they don't then the flat box illumination isn't flat so will cause calibration problems with coloured patches on your images. Alan

When exposing for flats you need to display the full histogram, especially with OSC, so that you see the 3 flat 'bumps' for the three colours and that none of them are near the edges. I just aim to get them centred in the middle of the histogram. With SGP only the unstretched (top) histogram is relevant. The stretched histogram, and the corresponding stretched preview image just seems to display the brightest bump only so doesn't mean much. Though the image does show the top bump stretched correctly. Not sure why kirkster's is all white though as the image statistics don't indicate any clipping. I use Astroart for calibrating (as Olly recommended it and it's just so easy to use 😀) and when I first tried the ASI071 OSC, I calibrated just the same as a mono image and then selected the RGB demosaic option from the Color menu to get the colour image. This produced an awful result with severe colour patches over the image and a residual grid of lines from the bayer mask. I then noticed there was a debayer option in the calibration setup panel, and selecting that and the corresponding bayer pattern (best done first with trial and error on a daytime image, as the Astroart debayer 1 of 4 pattern selection icons don't seem to correpond with reality 😁) I thankfully ended up with a colour image that looked good with no funny colour patches or superimposed grid. Not sure what the difference is between the two methods but it works. Alan Edit: Thinking about it the first method registers and stacks the frames before debayering which would certainly cause problems. 😁

If you're already using a nano, wouldn't it be easier to drive a mosfet from one of the nano PWM pins as a dew controller. You can then do away with the stepper motor and the separate dew controller modules. If you change the corresponding timer prescalers for the PWM pin(s) used you can have a 31kHz PWM frequency instead of the default slow 490Hz, and then if required, a small filter on the 12V going to the mosfets will remove any PWM switching pulses from affecting the main 12V distribution. 🙂 Alan

Are you using 'random' dither in PHD2. I've found it's not very random and tends to one direction. When cropping the edges after stacking only 2 adjacent edges need cropping off. I thought that 'circular' dither may be better but the final result is not much different. Alan

Not bad at all for the first try with the camera. 🙂 Alan

That's a pity. I didn't check all the features out, just that the program ran. I don't think the V11 upgrade will help anyway, as I assume you need to run the setup.exe on it to patch the V10 program which it won't let you do. I do have an old xp machine I could install V11 on, and then copy the files over to the win 10 machine. Is there a quick test that I can do to verify whether it then works OK on Win 10, and would save you having to swap files across between the two machines. Alan

Hi Hallingskies, The latest Skymap Pro version I have is V10 on CD from 2003 along with a Pictures CD, and the upgrade disc to V11 from 2005. I haven't used it for 10 years or so, when it was used under Windows XP I think, and I tried installing it on Win 10 (64 bit). It reported that it was incompatible and couldn't run. However, if instead of clicking on Setup.exe (or using the CD autorun.exe feature) you double click Skymap32.exe on the CD it runs fine. I just copied the CD contents to a folder on the hard drive, along with the separate Pictures CD, and ran it from the hard disk without issues. The V11 upgrade CD contains everything apart from the Skymap.exe program so I copied them to the existing V10 folder overwriting everything, and Skymap still ran fine, although it reported it was still running V10. I believe the Setup.exe file on the CD is a 16 bit program to enable the 32 bit Skymap program (or any other program) to be installed on 16 and 32 bit systems. Windows 10, (32 bit and 64 bit) will run 32 bit programs but not 16 bit which is why it baulked when running setup.exe. If your version won't run by running Skymap32.exe directly, I can let you have my version 10 plus V11 upgrade, if you wish, as I don't use it anymore. 🙂 Alan

Hi KEJ, You'll only see if the spacing is correct with actual star images. You examine the corner stars in a test image to see if they are nice and round and not distorted into elongated stars (or little seagulls sometimes). The further you are from the centre of the image the worse the distortion becomes, which is why large sensors show it more, and make the spacing distance more critical. The 55mm backfocus distance is a standard figure for DSLRs. It's confusing that backfocus has a different meaning depending on what's being discussed. For a lens, the backfocus is the distance from the centre of the rear lens element(s) to the image focal plane (the camera sensor). As this is not easy to measure in practice, a figure from the rear of the lens casing is quoted instead, which is easier to measure in use. This is the 67.7mm distance quoted on the WO diagram, (if the adjustable section is set to zero). The 69.2mm figure is I believe from an internal M54 thread which is accessed by removing the adjustable section of the flattener which ends in the M42 thread. Using the M54 thread there is no adjustable feature on the flattener. For a camera, the backfocus is the distance from the front lens attachment point of the camera to the image sensor. For a DSLR this is usually 55mm. For your 533 it's only 7.5mm, which is why you need extra spacers to make up the distance to achieve the total FF backfocus ( FF spacing), when using astro cameras instead of DSLRs. Yes. 😀 Alan

Hi KEJ, Yes, your drawing is correct with the updated increase on the flattener adjustment from 11.2 to around 12.9mm to account for the extra glass in the way. The front glass and the filter are 2mm thick I believe, so adding 1.3mm for the total glass would in theory be correct making a setting of 12.5mm on the FF the more theoretically correct figure. However, the sensor size on the 533 is not large, so FF spacing is not so critical, and I doubt whether 0.4mm would make any actual difference to the image results. It's a coincidence the spacers you've used actually make your 533 setup almost the same as a DSLR. 🙂 In practice, with large sensors, you almost always have to make slight fine adjustments to the FF spacing to get the optimum results, as some of the figures quoted for camera back focus etc. may be slightly different from the published figure. Alan

As geeklee says re the cooling. I use SGP and set it to cool down or up to specified temp in 10 mins but that's just habit. Concerning the FF spacing remember to add extra distance to the 67.7mm specified due to the filter and protective glass in the light path as refraction through them moves the actual focus point back by around 1/3 the thickness of the glass. So you FF spacing should be nearer 69mm. As your sensor is not large though, the spacing shouldn't be that critical in your case. Alan

No, it wouldn't matter. As long as there is a portion of background sky in your image, you can hover the mouse over it and get an average background ADU reading from your capture program preview display etc. Also, as long as the total area of background sky is greater than the total area covered by star trails then the median reading of your image statistics readout should still be the sky background ADU. As long as you're not pointing at the Milky Way you should be fine. 🙂 Alan

Thanks Phil. Glad that it helps out others, as well as those directly asking the questions. 😀 Alan

Very impressive indeed! With the weather I get here it would probably take me years to get similar data. Alan

Excellent. I always thought it wasn't worth doing Oiii with significant moonlight, but it certainly adds a significant amount to the final image. 😀 Alan