Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_through_the-_eyepiece_winners.thumb.jpg.236833c5815bb321211a43f4d5214ba8.jpg

Oddsocks

Advanced Members
  • Content Count

    1,121
  • Joined

  • Last visited

Community Reputation

688 Excellent

About Oddsocks

  • Rank
    Sub Dwarf

Profile Information

  • Gender
    Male
  • Interests
    Engineering-electronic and mechanical design, development and implementation, Software development, Astronomy, Photography, Hiking, Sailing, Literature, Music, Art, Theatre, Single malt Scotch Whiskey.
  • Location
    Dorset U.K.
  1. If the motor is binding and stalling when you increase the worm-RA gear mesh pressure then backlash can not be the cause of the slop. By jamming the worm and RA gear into mesh with enough force to stall the motor then backlash between worm and RA gear that can be felt cannot exist because the mesh pressure forces the worm and gear tightly against each other. Backlash may be present during motorised rotation of the worm under such extreme conditions but only if the worm or gear are badly worn, or poorly manufactured such that the points of the gear teeth are riding along the valley floor of the worm thread, or vice-versa, but you would not be able to feel this, only measure it with mechanical and optical testing. Normally, in a well made gear and worm the point of the gear tooth does not touch the valley floor of the worm thread, rather the mesh is along the walls of the threads leaving the gear points clear of the valley floor. Difficult to explain in words I'm afraid. I have never seen an AVX mount so the advice I can give is only generic but from your description I doubt the backlash you are seeing is anything to do with the principle RA worm-gear mesh, with the possible exception being if the worm and gear are not aligned with each other, i.e, the RA gear is sitting further up, or lower, down the RA shaft with respect to the centre of the worm long axis, which is possible if you took the gear off the shaft at some stage and did not put it back in exactly the same location, or removed or added spacers to the RA shaft bearings etc, even so, if the mesh is tightened to the point that the motor stalls then backlash between the principle RA gear and the RA worm than can be felt should be impossible. If you increase the worm-RA gear pressure to the point that the motor stalls then you run the risk of damaging the worm by bending the worm shaft or gouging the RA gear/ Worm, the mesh pressure should be no more than about 1kg maximum, as described in the last post. William.
  2. Hello Anthony Most engineers will tell you it is difficult to make an accurate assessment from video, you really need to be there with hands-on. Looking and listening to the videos I would make a guess only..... In the second video it looks as though you are not seeing worm-RA gear backlash but the spur gear on the end of the worm shaft is loose. If you look at the end of the shaft you will see a flat surface ground into the diameter of the worm-shaft, in the gear hub itself you will see one or more grub-screws, one of the grub screws should line up with the flat in the shaft and be tightened firmly, if this grub-screw is loose then the gear will rock slightly from side-to-side. I think this is what you can see in the video, not the worm shaft turning with backlash against the RA gear but the spur gear loose on the end of worm shaft. In the first video the gear mesh looks ok, adjustment has to be made so that for a full rotation of the gear the mesh pressure is constant, or as near constant as it is possible given the manufacturing tolerances. This connects with the third video, it's not clear that the mount is speeding up or slowing down, only that the noise varies during one worm rotation and being a rattling noise this is unlikely to be from the worm-to-main-RA gear since it should be well greased and thus damped against noise, but is most likely coming from the spur gears or motor reduction gear. Because it appears to be varying with the worm rotation period it seems reasonable that it might be connected to the apparent looseness of the spur gear on the worm shaft and the variation is due to a slight bend in the worm shaft itself, or slight eccentricity in the bore of the spur gear, causing the mesh pressure to vary as the worm turns. Only recommendation I could make is to check that the grub screw(s) in the spur gears of both the worm shaft and motor shaft are tight. Most likely these are Allen headed grub screws so make sure the tool you use to tighten them is the right size and standard. Being an American mount from a Chinese factory the grub screws could be either metric or imperial, if you use the wrong size and standard of Allen key you may damage the heads and be unable to tighten or remove them. Using the correct size and standard Allen key check the Allen screw(s) in both the motor shaft spur gear and worm shaft spur gear are tight, do not over-tighten, the grub screws just should be nipped up. If over-tightened they will strip the threads or fracture the heads. Apply plenty of grease to the spur gears then readjust the worm-RA gear mesh pressure and test again. Do not try to set too high a worm-RA gear mesh pressure as you will cause excessive wear and damage the worm and RA gear, the adjustment has to be just enough to remove backlash in the worm-RA gear mesh for as much of one full rotation of the worm as is possible. If too much force is applied when adjusting the worm-RA gear mesh pressure you may permanently bend the worm shaft, just a little pressure is needed, roughly equivalent to a bag of sugar (~1 kg) resting on the worm as it presses against the RA gear. If you find the grub screws keep working loose after a period of time then you can use a very low strength screw locking compound to help keep them tight, but it has to be low strength or you may never be able to release them again for maintenance. We used to use a little nail varnish painted onto the threads of grub-screws before inserting into gear hubs, while still liquid, as it is easy to remove again later once set by soaking the end of the grub screw that protrudes from the gear with acetone, which softens the nail varnish and allows the screw to be released. If you use a commercial screw thread locking compound then it has to be very low strength such as Loctite-222, and this can be softened by applying a little heat with a hot-air gun or the tip of a soldering iron against the head of the grub screw. Where are you geographically? are there no astronomy clubs near you? You can usually find at least one good mechanical engineer at most clubs that can help out. William. P.S. I'm travelling for the next three weeks so I most likely will not be able to visit SGL for a while. TBH with a mechanical problem such as this you would do better finding a local fellow astronomer through your nearest society to help out....
  3. Sorry, I probably didn't explain this too clearly. If you switch PEC off and monitor the guide window for a full worm rotation (ten minutes for the AVX?) you should see mainly positive going correction pulses for at least half a worm period and negative for the other half, unless you have been lucky enough to receive a mount-in-a-million with a 'perfect' worm that has no PE. In your posted screens shot you only show a fraction of a worm period so it's not really possible to say that the only corrections that are being made are always positive, you would need to monitor the full worm rotation to be able to state this categorically. It might be that for the section of the worm that you have monitored the PE requires corrections that are only positive as the worm period any that time is mainly negative...hope I explained that a bit better this time? A bad PEC curve will complicate your diagnosis so turn off PEC, begin guiding and monitor for a full worm rotation, you 'should' see both positive and negative corrections over the course of the ten minutes worm rotation and visibly see the sinusoidal periodic error represented by the guide pulse chart. If you do, great, make a new PEC curve, star in the south, OTA on east side of the mount, balance slightly east heavy, DEC as close to zero as possible then apply the PEC curve to the mount and activate it. Then start guiding again, same conditions as when creating the PEC curve, wait for at least ten minutes for the worm to synchronise with the PEC recording and for the mount to begin using the PEC curve and now analyse the guide pulses, do you still see wild excursions of the guide star and positive only corrections, if so, you can rule out the PEC curve as being at fault and look elsewhere. Just to repeat the above point, when PEC is applied and switched on you have to wait a minimum of ten minutes after mount power-up before guiding as it takes that long for the flag on the worm to signal the mount that the worm reference point has been activated and to sync with the PEC curve. If you try to guide anytime earlier then ten minutes after startup then the PEC curve will not be in sync and incorrect corrections will be applied making guiding rather erratic, especially if you attempt PHD calibration during that first ten minutes. Can't think of anything else at the moment but I will look back in again and see how things are going, if I think of anything else I'll post again. William.
  4. Though not a PHD user, and just based on what I know of Windows and imaging software from another discipline the following 'might' be the answer. Firstly, PHD has no idea that a sensor has degraded, it can't know unless it immediately takes a test image when the camera is connected and analyses it. To do this it would have to ask you to cover the camera port manually before taking an image, or in a camera with a shutter it would begin an exposure with shutter closed and ask you to wait for the exposure to complete, since this is not the case I think you can assume that no such test is performed and PHD is not basing its 'Bad Pixel Map Does Not Match" message on any assessment of the state of the sensor. So what does that leave?, only that PHD no longer recognises the connected camera and it is telling you this, only in a rather obscure and unhelpful manner. Most likely, and only a guess here, is it possible you are not always plugging the guide camera into the same physical USB port on the computer or hub each time you set up? The IS range of cameras have no hardware unique serial number identifier, only a USB vendor ID, which is identical for each camera in that series. As some folk might use a pair of identical cameras, one for guiding, the other for imaging then Windows (and PHD) will have to identify an individual camera by further identifying which physical port it is plugged into on the host computer otherwise there is a danger that the wrong pixel map will be applied to the wrong camera or the wrong "Start Exposure" or "Download Image" request gets sent to the wrong camera. To avoid this the camera identifier in Windows, and presented to PHD etc, will comprise the USB vendor ID and its physical USB port/socket. You will probably have noticed for many USB devices in Windows that each time you unplug a new device from a USB socket and move the plug to another socket that Windows will say "Installing Driver" again, even though the device is the same, as far as Windows is concerned the device is unique "at that location". It will repeat this until you have used all the physical sockets available on the computer and in the Windows USB device directory each single device will be recognised at 'unique' for that particular USB socket so that if you have one camera and eight USB sockets Windows will 'think' you have eight different cameras if you plugged the camera into all eight sockets at some time or other. After a longish ramble, the most likely explanation is that PHD thinks the camera is unique each time it gets moved to a different physical USB socket on the computer, or hub, and therefore the Bad Pixel Map does not match that camera, or, there has been a Windows update in-between sessions that has reordered the USB device list, or, you are using a USB hub that does not pass through a unique socket identifier to Windows and therefore Windows thinks every time you connect the camera it is new. Any of the above explanations is possible. For mobile setups with laptops and hubs etc, I always found it best to put colour stickers. or DYMO labels on the devices/cables/computer USB sockets so that every time I set up the same devices were always on the same sockets and always appeared as the same device to the software being used. Do you think this could be the answer? A question perhaps for the PHD forum is how many unique pixel maps are stored, if you have one camera and four USB sockets does PHD keep four individual bad pixel maps based on it recognising four unique cameras each time you use a different socket, if so, eventually if you use all the USB sockets on the computer you will have a bad pixel map associated with each socket and the annoying message will disappear, if this is the case however you could get caught out by regenerating a bad pixel map for the camera and on the next session plug the camera into a different socket and get an older bad pixel map associated with that 'unique' camera. My guess is that as PHD is 'just' a guiding program only a single bad pixel map is held and is only relevant to a single USB socket in which case if you plug the camera into a different USB socket on the next session it will tell you the bad pixel map does not match. I would love to test this theory but unfortunately the only IS camera I have here is an older FireWire model and a single CardBus FireWire laptop card so I can't move the camera to a different port but it should be easy enough for you to see if this is the case with your setup during the daytime just by setting up a session, create a BPM, take a few test guide camera images, close PHD and disconnect the camera then reboot the laptop, connect the camera to a different USB socket and see if the "Bad Pixel Map Does Not Match" message appears, if it does, close PHD, move the USB plug back to the original socket and open PHD a final time, has the message appeared this time? There is one final thought, there was an issue reported over on the CN forum some time ago with PHD2, a few releases back, where it became confused between the main camera and guide camera depending on in which order the two were connected to host computer and selected in PHD that led to the "Bad Pixel Map Does Not Match" message, that was a least a year ago and though I searched this morning I could not find it again. I'm guessing that was fixed, if it was a genuine fault, but maybe that is another question for the dedicated PHD forum? William.
  5. P.s. If there is no appreciable difference between PEC on and PEC off this means that the PEC correction file is empty and this is the default condition when the mount leaves the factory. Celestron do not test the mounts under the stars and program the PEC table for you before shipping, you have to do this yourself when you first set the mount up. With guide corrections disabled and no PEC you should see the smooth underlying sinusoidal RA worm error in the guiding graph. Program the PEC as described in the manual and apply PEC. Guiding alone will not give the best performance possible and with permanent PEC in your mount there is no reason not to use it. Even my Paramount has to have PEC enabled before it reaches specified RA error with or without guiding....
  6. In that case assume the worm mesh pressure is too tight, make a small readjustment and then retest. Unfortunately there is no shortcut to tuning the mount, the only way to improve things is to make small incremental changes and retest. The good thing is that you can fiddle with getting the RA mesh setting correct when the moon is badly placed for regular imaging so your'e not wasting imaging time. Keep guide logs or screen snapshots and test under as near exactly the same conditions with the same OTA angles each time you make an adjustment so that you can assess whether the adjustments you make are having an effect. There should be measurable differences to guiding performance with changes to worm-gear mesh pressure, if you see no change then the problem lies elsewhere. You must test and adjust where the apparent motion of the star is at it highest with respect to the RA motion, pointing south and on the celestial equator, this is where a badly adjusted mount will deliver the worst performance in RA and apparent star motion will be the greatest across the camera detector, when pointing towards the north and at higher dec angles then the apparent motion of the star across the camera sensor is reduced and more difficult to evaluate. If you have not already done so then one of the tests that will help is if you run guiding with mount corrections disabled, select the guide star as normal and begin 'guiding'. With mount corrections disabled then you will see the underlying performance of the RA axis mechanicals in the guide graph but without any actual input from the guiding software. If the sudden excursions in RA are still present (possibly in the negative direction this time), then you are sure that the problem is essentially mechanical, if the wild excursions stop then there is something not quite calibrated or set correctly in the guide software. William.
  7. Continual guide corrections in one direction 'might' also be caused by the permanent PEC that the AVX mount uses being wrongly calibrated. For the AVX and any mount that uses permanent PEC you have to recalibrate the PEC file after making any adjustment to the RA worm/gear mesh or otherwise disturbing any of the mechanicals on the RA axis.
  8. Yes, absolutely, any worm gear operating against a ring gear has to have some free play otherwise the worm will bind. The problem with a lot of mass produced mounts is that QA is a little wanting and it's not unusual to find the worm or ring gear has been machined a little eccentrically and if you adjust the worm-gear too tightly in one position then it may bind as the mount rotates to another section of the gear. It's a balancing act, you have to find the sweet spot where the worm-gear does not bind at the point(s) of maximum eccentricity and does not allow too much backlash at other rotation angles of the RA axis. It is always going to be better to have a little too much free play and backlash than too little since backlash can be countered to some extent with slight east side imbalance of the mount and responsive guiding. As you describe the RA worm mesh is difficult to adjust on the AVX then drive the mount under motor control and listen for the point where you think the motor is really struggling and turn the mount off at that point, then without moving anything take of the motor covers and adjust the mesh pressure to be just lightly engaged any that point. refit the covers and retest, if ok try again with guiding. As an engineer I would actually test slightly differently and put an ammeter in-line with one of the motor wires and watching the current draw through the motor look to see where on the rotation of the RA axis the motor current peaks as that would correspond to the tightest point of the worm-gear mesh, then I would adjust the mesh pressure at that point without moving the RA axis (Note: this only works with servo motors similar to those in the AVX as the speed feedback system will constantly increase and decrease motor voltage/current to regulate speed in response to binding, it does not work with stepper motors such as those in an EQ5/6 etc). William.
  9. IMO anyone offering to ‘Hypertune’ a mount is just spouting meaningless tosh (or perhaps a ‘sales’ pitch should be a proper term?). A competent mount engineer/technician can certainly ‘tune’ a mount but ‘Hypertuning’ sounds like snake oil to me.... Anyhow, not knowing the AVX at all, and with no useful information published by Celestron, there are just some general points that should apply to a worm driven German mount. Servo motors, such as those used in the AVX should have a real-time speed control feedback loop to regulate for changing loads on the drive, the worm speed should not change significantly with variable loading and because the worm rotates very slowly any changes to worm binding will occur quite gradually so it’s unlikely that would explain the sudden excursions in the RA guiding graph unless the worm-to-gear pressure is over-tight and is literally locking the gear and worm together. The starting point for adjustment should be with the OTA and weights removed, the RA worm and motor assembly completely removed, does the RA shaft rotate freely and smoothly without a ‘gritty’ feel? If that is ok then refit the motor and worm assembly, mount the OTA and weights, with the RA worm-to-gear mesh very slightly loose and mount balance set up east side heavy, OTA near horizontal and pointing at a star as near the celestial equator as possible, test with guiding. If the RA excursions are then absent in the guiding graph gradually increase the worm-mesh pressure a little at a time to reduce backlash until the excursions reappear, then back off a little from that point. If the OTA saddle can be rocked from side-to-side in RA as you describe, even when a high worm-to-gear mesh pressure is applied then the problem lies somewhere else. Check the pre-load end-float on the RA worm shaft, perhaps your ‘Hypertuner’ set this incorrectly. When rocking the OTA side-to-side in RA and observing either end of the RA worm shaft you should see, and resting your finger on the shaft end, feel, no movement. If end-float is seen or felt then adjustments to the worm shaft pre-load is required. With a high worm-gear pressure and no worm shaft end-float seen or felt and if the OTA saddle can still be rocked in RA then check that the RA gear is properly secured and locked to the RA shaft and that the OTA saddle is also tightly secured and locked to the RA shaft. Last thing I can think of at the moment is if all mechanical checks reveal no issues then follow the procedure for resetting the mounts permanent PEC as described in the manual under the Astro Imaging section. If the mount was stripped for so-called ‘Hypertuning’ then the mounts built-in PEC correction curve should have been reprogrammed as a matter of course. (I think you can probably guess I dont think much of that term....) If you do a Google search for ‘Celestron AVX strip down guide’ you will find several links to web documents. A recurring theme seems to be issues with the RA bearings and rubbing of the plastic washers used as spacers between the RA housing and bearings but never having worked on an AVX mount I can’t really say if this is an accurate assesment of a design problem or an unproven theory, in any case, compared to the humble EQ5/6 the AVX mount looks to be quite complex mechanically and I wouldn’t recommend you strip the mount unless you are absolutely confident in your abilities and have the necessary tools etc. With the EQ5/6 there are so many in use that there is a large user base to assist with problems but I have the feeling that the AVX has not achieved a great market share and user experience is harder to come by. William.
  10. This is a puzzle and at first and I originally wrote a reply solely based on possible camera problems until I realised that some of your post processing is with .jpg's. So this is a revised and heavily edited post. The small scale concentric ring artefacts in your opening post .jpg stacks, are possibly caused by the data compression routines that create reduced size .jpg files. For astronomy images you should be acquiring and post processing only with raw .CR2's or uncompressed 16/32 bit .tif's or .fit’s etc, never 8 bit .tif’s or .jpg’s as compression artefacts will appear. The small scale and large scale ring artefacts in your raw .CR2 files are more of a mystery. In your opening post you say that the rings appear even with no lens fitted to the camera and with the camera pointed towards the ground. When operated in this way vignetting should virtually disappear (except in cameras with full frame sensors that occupy most of the camera sensor well). With the APS sized sensors such as that found in your camera being quite small in relation to the diameter of the sensor well, the illuminated field, with no lens or telescope fitted, should only show linear gradients with virtually no vignetting present and therefore few if any rings visible when you stretch the image. A simple test you can do that may help to eliminate camera issues is to take an image pointing the camera at a plain white painted ceiling with the standard lens fitted and another with no lens then stretch as before, if the ring pattern, spacing, size and shape are identical in both images then possibly a sensor fault is present, if the ring pattern, spacing size and shape is different in both images then something is else is the cause. If the ring artefact pattern is identical in the with-lens, without-lens images and I had to take a guess I would say that as your EOS1300D had been astro modified it might be that the anti-aliasing filter has been put back incorrectly, or is missing altogether, or there has been some dampness on the sensor at one time that has resulted in the antialiasing filter or far IR filter sticking to the sensor surface. Was this a full astro mod to the camera or just the first stage mod with only the near IR filter removed? For daytime terrestrial imaging try to avoid .jpg's and keep to raws, or at least configure the camera to capture both simultaneously, if you absolutely have a need for only compressed .jpg images, such as to save space on the SD card etc then always use the highest quality .jpg compression algorithm that the camera supports, see the in-camera setting menu, but never use .jpg's for astro imaging. I looked at your two linked .CR2 files, light and flat, in PixInsight and there are no ring artefacts visible at even quite high stretch, attached screen shot below, which makes me wonder if something else is going on with the post processing, is it possible your post processing application is working with a mixture of 8 bit and 16 or 32 bit images instead of all 16 or 32 bit? For astro imaging capture and post process in raw .CR2, .fit’s or minimum 16 bit .tif etc. Jpg's for astro image processing are only fit for the trash can! As Michael points out, stepped vignetting ring artefacts are to be expected when you stretch an image very hard so that across the whole image the intensity only varies by a few ADU counts and quantisation steps then become apparent. If your Barnard 33 / IC434 image is very faint, as it seems is the case in your posted images then it’s possible the stepped ring artefacts are a normal consequence of over-stretching to pull out data that is not really there in the first place. Do you see this pattern in all your astro images or just very faint, primarily Ha imges like this one, are the artefacts seen in normal daytime images? Can’t think of anything else at the moment. William. P.s. noticed in the .CR2 file header that you have auto-rotate enabled in the camera settings (landscape/portrait automatic sensing), this should be temporarily disabled when used for astrophotography.
  11. Hi Michael. If you are just enquiring about the CloudWatcher, it is accurate about 80% of the time, it's most common failure is to detect clear skies during temperature inversion periods, i.e, when ground proximity air temperatures are colder than the clear skies above. It is necessary to tweak the sky temperature thresholds that are derived from the IR thermopile at least four times during the year as the seasons change but it is not infallible in our climate of rapidly oscillating weather patterns. It has never left the dome shutter open in rain though and that was my primary concern. The Hydreon RG11 rain sensor is a good backup but this too is not infallible, if you have ever driven a car with automatic rain sensing you will know that it often fails to wipe when a very light spray or mist is collecting on the windscreen and the same is true with the Hydreon RG11. The system works by detecting rapidly changing reflections in IR light from droplets falling on the sensor dome and if these don't change fast enough the system continually adapts to the tiny static droplets on the sensor and ignores them. This is not a deal breaker as such and the occurrences of these fine wet mists does depend where you live, down here on the Dorset coast we see them quite often as the sea breeze wafts them inland but when I used to live nearer London I rarely saw these wet mists. The combination of CloudWatcher and the Hydreon RG11 have provided just about as reliable a system as I can afford and with any system the more complex you make it the more likely it is to fail. If you are asking about the automated observatory as a whole, the amount of data I have to process has risen at least ten fold. Before automation and with our fickle weather I would often give up on a session because of cloud only to find that it had cleared up at 3am and left beautifully clear skies until dawn, with automation under ACP control as soon as the CloudWatcher reports clear skies for at least thirty minutes the observatory will start up and ACP will choose the best placed object from my target list and start acquiring images, if it clouds over ACP will close the shutter and wait till dawn to see if it clears up again and then return to imaging, if that original target has now set ACP will continue with the next best placed target, and so on, night after night, until all the specified subs for each of my targets is complete. I have to point out though that I don't do normal 'picture' imaging any longer, the LP here along this part of the Dorset coast is just too severe so my imaging is confined to photometry and spectroscopy, which I find much more interesting and productive. William.
  12. I keep thinking that an 'All Sky Camera' coupled to a full sky plate solver could take snap shots of the sky every few minutes, identify the brightest stars that should be present across the full image and flag any stars that gradually disappear to be likely obscured by cloud, track the passage of the missing stars in almost real time and predict whether the clouds are coming towards you or away, and close the observatory if appropriate, its got to be a simpler method than messing around with sky temperatures and LUT's etc. Now if only I had the advanced programming skills......
  13. The Bayer pattern used to deBayer full spectrum colour or narrow-band filtered raw data from an OSC or DSLR camera is the same for either mode, there is no need, or advantage to change it. When imaging with a OSC/DSLR and a narrow-band filter, such as SII or Ha only one set of the Bayered pixels are receiving photons. In the case of Ha or SII, only the red pixels will collect photons while the green and blue pixels receive virtually no photons as these are blocked by the additional Ha or SII filter in front of the camera colour sensor and therefore only contribute noise to the image. After normal deBayering the resulting three channel RGB image will have the “red cast” that you quote and very evident noise. Really, an Ha or SII filtered image is a monochrome image, not full colour, and for Ha or SII from an OSC or DSLR it would be best if you separate the red pixel data from the blue and green pixels before deBayering and I would generally use a post processing application such as MaxIm DL to extract only the data from the red pixels, not bother with deBayering interpolation and then proceed to use that extracted red pixel data as a 'black-and-white' monochrome image only. You could add false red colour later in Photoshop for example if you wanted to recreate the Ha image as a 'red' image but normally I would not bother with this and I would use the extracted red pixel data to add to the red channel of a full colour image taken without the Ha filter. I would not attempt to use a full spectrum debayered OSC with-Ha-filter image as a 'normal' stand-alone colour image, because of the noise from the empty green and blue channels and false colour that results. The answer really depends on which post processing programs you are using to handle the data. If stacking your data in DSS for example you could try the 'Super Pixel' option in the RAW/FITS Digital Development Process Settings, Bayer Matrix Transformation, image attached below, this will combine the three colour bayer pixel group into a mono image, though still RGB, with all three colour channels containing the same data, half the physical size of the original, and which you can choose to to convert to single channel mono in Photoshop or PixInsight etc for ease of processing or keep as an RGB three channel image which is a bit more difficult to use when stretching in post processing. The downside is that the 'Super Pixel' process combines the noise from the empty green and blue pixels with the red channel so you end up with a slightly noisier image overall, but give it a try if you use DSS, it should make your post processing much easier. For PixInsight, MaxIm DL, Photoshop, Gimp etc, there are other methods that can be used to extract just the red pixel information from the raw data which you then handle as a single channel monochrome image. Some techniques such as the Extract Bayer pane tool in MaxIm DL produce a monochrome image from the red pixels only and leave the noisy green and blue channels behind while others such as Convert to Mono in Photoshop include the green and blue channel noise in the final monochrome image. In Photoshop using layers you can use specific blend modes to add just the red pixel data to the red channel of a pre existing full colour image while leaving noise of the green and blue channels behind. Rather than explaining lots of different techniques that are specific to individual post processing applications it would be helpful for you to specify which software you are using for post processing and then someone with experience of that application could better suggest a way forward for your data. HTH. William.
  14. As my observatory is fully automatic and opens and closes all by itself, much of the time when I'm either in the land of nod or miles away from home, I need to rely on a proper cloud sensor which measures the temperature of the night sky and compares it to local ambient, it does this with an IR sensor looking at the sky and a regular temperature sensor for the local ambient, the device I use, the AAG CloudWatcher, also has a regular rain contact sensor for the frequent occasions when rain falls from an otherwise 'clear' sky during thundery weather. AAG cloud watcher: http://www.lunatico.es/ourproducts/aag-cloud-watcher.html As I'm remote I also need to know what the windspeed is and have the anemometer attachment: https://tienda.lunatico.es/epages/lunatico.sf/en_GB/?ObjectPath=/Shops/1010001/Products/BCWANE And because I have local light pollution from a nearby building I needed to move the CloudWatcher up high, not near enough to the observatory for a direct connection to the observatory computer so I have the CloudWatcher SOLO to make the CloudWatcher data available on the local network, the actual CloudWatcher detector is mounted up behind one of the house chimney stacks (disused so no heat plumes to worry about). https://tienda.lunatico.es/epages/lunatico.sf/en_GB/?ObjectPath=/Shops/1010001/Products/BCW00S But wait, it gets more complicated....also had to install a remote operated high pressure 'headlamp' washer on the same chimney stack mounting for the CloudWatcher detector head to clean off the pigeon poo from the various sensors....the days of climbing a twenty foot ladder with a bucket of water every few months are a bit behind me.! Then... what do you do if the network goes down every time the local minicab pulls up alongside the house and uses a two-way radio with illegal 100W RF amp that locks up the network router until it does a self reset, only after it starts raining of course...so I needed the assurance of a second rain sensor on the observatory roof directly coupled to the dome controller, any drop falling on that triggers an immediate closure of the shutter and for that I use the Hydreon RG11, as mentioned by others above. http://rainsensors.com/how-it-works/ This business gets awfully complicated and I do look back wistfully at the time when I just used to 'pop outside' for half an hour or so with a Meade ETX90 and a Canon A1 35mm film camera piggy backed on the top
  15. When adding night vision webcams to monitor the inside of an observatory be aware that many use a built-in automatic IR light source that floods the dome with IR as natural light levels fall. While modern LRGB and LP filters are very good at blocking IR they may not be 100% efficient and there is always the possibilty that some stray IR may leak into the imaging camera light path while your guide camera may have no IR blocking at all leading to a poor guide star S/N ratio when the webcam is active. Should you pursue photometry with Johnson & Cousins UV, V, B, Rc, Ic filters note that the Rc and Ic filters specifically pass IR and your photometry data would be erroneous if contaminated with IR from the webcam. Bottom line: Any webcam used for observatory monitoring should have remote switchable IR night vision illumination, not automatic, or, no built-in IR source at all and use a separate switchable IR source that can be turned off when imaging is in progress.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.