Oddsocks

Hi Gordon. Good to hear from you, hope you have recovered well from your health scare... Your plan sounds good to me. Only suggestion I have to make is to use a can of compressed air to blow away the dust from the outside of the camera, particularly around the cooling fins and fan aperture, and then wipe over the outside of the camera with an anti-static cloth (type used for vinyl records, CD's etc) before you place it in the gloved bag. I do wonder if these SONY IMX sensors can be damaged by running at extremely low temperatures, the published SONY specification sheets available to the public are worthless in this respect as they have nothing to say about the acceptable operational temperature range. Here at home I built a camera service and purging station from a second-hand acrylic fish tank, £2.50 from one of the SCOPE charity shops, round holes cut in the sides and nitrile-rubber gauntlet length gloves clamped into the holes using clamping rings made on a 3D printer, a rubber gasket glued to the top of the tank and another flat sheet of clear acrylic used as a lid. The whole thing cost less than £25. "One day" I'll get around to fitting a Dyson type HEPA filter at one end of the tank and a suction fan, or vacuum cleaner hose adaptor at the other, at the moment I just vacuum clean the tank before I need to use it and get the camera inside quickly before more dust can blow inside. At the Portuguese remote observatory we bought a second-hand laboratory clean-box for this purpose, about the size of a baby incubator. With a couple of dozen cameras and users out there that box is used frequently but being so large we do get through a 130 litre full-size bottle of welding Argon quite quickly, and at a couple of hundred Euros per bottle that adds quite a bit to our shared operating costs. William.

I mis-read your reply above and took that to mean you had only cleaned the camera window, not the sensor cover glass. The sensor cover glass is hermetically sealed during fabrication, you can't remove that and the sensor would be damaged if you tried. Just to clarify, did you wet clean or dry clean the sensor? A way to answer that definitively is to try the following method. Find a container just large enough to hold the camera upright and with about ten centimetres clearance above, such as a goldfish bowl, deep saucepan, cookie jar, etc. The container needs to be only just big enough for the task, not too much empty space around the camera. Cut three fingers of thin, but stiff, plastic, ca. 1cm x 5cm, from an old credit-card, or a supermarket plastic food tray and punch a hole close to one end in each of the pieces. Use a couple of fresh in-car desiccant pouches, such as linked below, as bean-bags to support the camera, facing upwards, in the container. https://www.amazon.co.uk/FiNeWaY-REUSABLE-DEHUMIDIFIER-MOISTURE-ABSORBER/dp/B077K8BJW4/ Add a few additional non-desiccant bean-bags, or similar, to support the camera firmly so that it can't tip over in the container. Install new/regenerated desiccant tablets in the camera but leave the camera face-plate slightly loose and insert the three plastic fingers spaced equally around the flange area to keep open a slight gap, the punched holes in the plastic fingers should be outermost, do not pinch the face-plate screws tightly, you need to be able to slide the plastic fingers out of the gap easily. Cover the container with clingfilm leaving a little slack, but otherwise sealed, and place the container/camera somewhere warm for 48hrs. *see optional step for Argon purging below* After 48hrs in a warm place carefully punch and push a thin-bladed screwdriver through the clingfilm cover over the container and using the holes you punched in the plastic fingers slide the fingers out of the flange area and then tighten down the flange while the clingfilm is still covering the container. Remove the camera from the container and after fully tightening the flange screws immediately test the camera. If the artefacts are still present after following the above steps then something else is going on with your camera, it can't be due to moisture. If the artefacts were not present after the above steps but return after a few days/weeks then there is a leaky seal somewhere in the sensor chamber. *Optional step: Argon purge* If you want to Argon purge the camera you can do so by lifting a small piece of one corner of the cling-film cover slightly and inserting the thin feed pipe from a MIG/TIG Argon regulator and a disposable bottle of welding Argon, pushed down to the bottom of the container, and gently trickle in a stream of Argon at a very low rate for ten minutes. The heavier-than-air Argon will slowly displace the damp air in the container through the lifted gap in clingfilm cover, leaving the container filled with almost pure and dry Argon. Then extract the Argon feed pipe, seal down the clingfilm and leave the container somewhere warm for twenty-four hours to allow any damp air trapped in the sensor cavity to be replaced with the heavier Argon and any remaining moisture to be absorbed by the desiccant pouches. After twenty-four hours have elapsed follow the same procedure to seal down the sensor chamber as described above. This method is not nearly as efficient as Argon low/hi pressure purging in a sealed environmental enclosure but it is almost as effective, and, comparatively inexpensive and easy to carry out a home.

Cleaning the sensor (cover) glass is nothing to be concerned about, the official ZWO cleaning document that @LandyJon linked to describes the steps clearly. The steps required are really not that different to those that owners of DSLR's who regularly change lenses have to do many times a year, the only practical difference is that with a DSLR you only need to remove the lens, open the shutter and lock-up the mirror to reach the sensor, with your camera you have to unscrew the chamber cover to reach the sensor, and, with a DSLR there is a comparatively soft and easily damaged antialiasing and IR filter array directly over the sensor cover glass, in your ZWO camera those additional filters are not installed and the harder quartz-glass sensor window is exposed. Alan, @symmetal, describes the minimal effect on dark current of running at temperatures above 0c and while it is true that the difference to linear dark current is very small with increasing sensor temperature of these CMOS cameras you might see slightly more "pixel speckle" in the resulting images due to the non-linear response to increasing sensor temperature of warm pixels. That effect can be mitigated though with dithering and a sigma reject algorithm used when combining the stacked images. The only concern with leaving the sensor with moisture "seed" traces on the sensor cover glass and running just above 0c is that you risk moisture building up on the backside of the sensor where the cold finger from the TEC cooler abuts the sensor back plate, this area will be a few degrees below freezing while the sensor itself will be at 0c and if the moisture on that interface lingers it can spread over time and corrode the tracks on the PCB. If you run a cooled camera at 0c to avoid the appearance of ice on the front of the sensor glass you'll never know how damp the sensor chamber is becoming. The sudden appearance of ice crystals on the front of the sensor when running just below 0c is a useful, albeit a nuisance, indicator of the humidity levels inside the sensor chamber. William.

I may have misinterpreted your opening topic but I think that you have two separate questions here. 1. Can I reach inside the SeeStar, or it's output .fits image, and grab the individual frames that SeeStar stacked internally so that I can build an image using more advanced techniques? 2. What I can I do with the standard output .fits image from the SeeStar to give more pleasing image than is possible with the SeeStar's basic .jpeg output image? I do apologise if I've got that wrong and if so you can ignore my response below.... ------------- The SeeStar's jpeg format export option is a compressed image format and depending on its bit depth you could enhance that image using various filters and tools in many "Photoshop-type" general-purpose image processing applications. The limiting factor of that approach will be the compressed bit-depth of colour jpeg images, there is only so much you can do before the image starts to look "pixelated" and noisy. The .fits format image is uncompressed raw data and although for the SeeStar we don't know whether ZWO apply any kind of automatic dark current and bias subtraction to the output image nevertheless you can extract more information and produce a more pleasing image (I think) by post-processing the image in an application that is specialised (or optimised) for handling .fits images. The output .fits image from the SeeStar is already multiple frames stacked internally, as others have already explained above, and AFAIK you can't disassemble that image any further. I'm not aware of any methods that allow you to reach inside the SeeStar itself to extract the individual frames that it used/uses to build its stacked output image. You mention above that you have previous experience with Deep Sky Stacker. For a single (internally stacked) output .fits image from the SeeStar then Deep Sky Stacker has no useful purpose, but if you were to collect multiple (internally stacked) SeeStar .fits images of the same target then you can register and stack those together in DSS to reduce noise further and allow you to stretch the resulting image more to reveal fainter detail. With a .fits image, either a single frame that was internally-stacked in the SeeStar, or an externally registered and stacked combined image (DSS etc), created from multiple SeeStar internally stacked images, then you can do much more in post processing. I've attached two images below using your raw .fits file, one of which was very quickly (less than five minutes) post-processed in PixInsight, colour calibrated, BlurXterminator and NoiseXterminator applied then stretched and colour saturation increased, finally Histogram transformation applied. I've only applied a very basic process to your image, there are multiple tools available to you once you get to work on .fits images, it just depends how much time you want to invest in post processing and how much time you are willing to allocate to gathering as much raw data on a single target as possible. The second image shows the raw .fits image straight from the SeeStar with the same level of stretch applied. I hope that gives you some idea of what is possible in post processing the .fits image, and, as described above if you had multiple internally-stacked .fits images you could stack those together which would allow you go further in post processing. HTH William. Processed .fits in Pixinsight. Raw .fits from SeeStar.

There are some common issues that crop up time and time again with the MKS5000 USB port. The first is that the surface mount mini-USB socket breaks away completely from the MKS5000 PCB when you physically plug-in the USB cable, or one of the joints fractures, leading to intermittent loss of USB connection to the mount. As expected, this appears to affect mostly those users who are setting up and tearing down their mounts with each session but a few have also experienced this problem with permanent setups and may just be be the result of having a heavy USB cable dangling off the mount. This problem may have begun when the USA moved to prohibit the use of tin-lead solder in PCB construction, the replacement non-lead solders are physically weaker and require a different design of USB surface mount socket with a larger solder-pad contact area to maintain the adhesion strength, or a mechanical way of securing the socket to the board that does not rely on just the solder joints. Software Bisque’s answer to that issue is to mechanically strap a short, 6” (150mm) male-female USB-Mini pig-tail extender lead to the front of the mount using a self-adhesive tie-wrap base, or similar, so that the weight of the main USB cable is not pulling on the PCB socket continually and users are plugging-in to the pig-tail extender lead rather than directly to the mount each session. As you state that unplugging and replugging the USB cable appeared to fix the problem temporarily, while a re-boot did not, then your current problem may just be that the one of the solder pads on the USB socket has fractured, if this is the case then that can be repaired locally very easily. In your earlier reply you said that the mount powers up and displays lights but nothing else? If this is the case then ask local tech support to double-tap the hand controller joystick button, if the MKS5000 is at least partially functional then the mount should home and then be controllable from the joystick even if the USB connection is damaged, which will help you further isolate the problem. A second issue that is reported occasionally is that a current surge, caused by a stalling drive for example, can also knock out the USB comms temporarily (over-current error detected) and both the mount and the computer have to be rebooted before USB comms can be restored but if your computer is of a type that keeps it’s USB ports permanently powered up even when the computer is shut down then you have to physically unplug-replug the USB cable before the port will reset. A stalling drive, caused by a lack of grease on the worms (annual maintenance), a build up of abrasive dust in the grease (desert areas etc) or incorrect adjustment of the worm spring-plungers, can occur at particular mount projection angles or temperatures, and, because of the USB disconnect caused by the stall it’s not possible to always see the problem when operating the mount remotely, you have to be physically present, or have a webcam trained on the mount’s facia panel, to see if either of the RA/DEC drive status LED’s are indicating a stall condition and whether the audible stall alarm is sounding? Lastly, the MKS5000 has a built-in four-port USB hub. When you plug-in the USB cable to the MKS5000 you are connecting first to the internal hub (on-board chip). On the output side of the hub, port#4 feeds into the rest of the MKS5000 electronics to control the mount while ports#1&2 feed up on the internal wiring harness to the Versa-Plate sockets just below the OTA and port#3 is unused although the socket for that is on the PCB (marked Aux USB). As a result of this hub topography a problem with devices using the two USB hub ports on the mount’s Versa-Plate, or problems with the internal wiring loom between the MKS5000 and the Versa-Plate sockets, may knock out communications with the mount and make it appear that the mount is in error while really the problem was caused by peripheral devices using the mount’s internal USB hub. When I had my MX Classic the internal USB cables between the MKS5000 and the Versa-Plate USB sockets broke and had to replaced twice, if I had anything plugged into those Versa-Plate sockets when the damaged USB cable flexed then the current surge/voltage spikes would break communication between the mount and computer - error 213, but the real cause of that communication error was nothing to do with the USB electronics on MKS5000 itself. After I began using a USB isolator between Paramount and computer there were no more error 213’s following a stalled drive and I stopped using the Versa-Plate USB sockets after the problems with the internal USB cables and moved originally to a StarTech USB2 industrial hub up on the OTA with an external USB cable from computer to the hub, and more recently I replaced the StarTech hub with a Pegasus power box after exchanging the USB2 camera for a USB3 camera and not being able to find a reliable USB3 hub that was compatible with the observatory computers hardware. IIRC, to aid fault finding with the current MKS5000, if you do have a peripheral device plugged into one of the Versa-Plate sockets, such as a camera, filter-wheel, memory-stick, etc, and you can still reach those, but not the mount itself, then you know that the internal USB hub on the MK5000 board is functional and the USB2 Mini input socket on the PCB is ok, and the problem with no comms to the mount is after the input socket/on-board USB hub. If the on-board hub is dead or the input USB socket physically broken then you wont see anything plugged into the Versa-Plate sockets, or the mount. The new Software Bisque MKS6000 upgrade board has a USBC input socket, which will hopefully be a stronger affair, and I understand that they have moved away from having an internal USB hub on the PCB so that the Versa-Plate USB sockets are now merely pass-through-the-mount cables, which will isolate the mount electronics from problems with the peripherals that cause the USB comms to be disrupted. HTH William.

As a recent, and now ex Paramount MX owner, I can confirm that this has been an issue ever since the MKS5000 board was first released and SB have never tried to revise the design of the USB interface. In my case my MX mount only operated for a few months before the USB interface chip on the board failed, possibly due to a nearby lightning storm, although that was never proven. The USB interface chip that is on the MKS5000 PCB is totally unprotected against over-voltage spikes or ground loops. At that time Baader Planetarium were the European distributors for Software Bisque products and they sent me a replacement board, I didn't have to go through Software Bisque at all. Baader Planetarium are no longer agents for Software Bisque and spares can be ordered through FLO, amongst others. But, the situation with the MKS5000 boards has been difficult for several years, even before the pandemic it was not unusual for owners of Paramounts to have to wait many months for a replacement board to become available, and as snowy911 mentions the cost of all SB spares have recently seen a huge uplift, and this was one of the reasons that when I decided it was time to replace my 12 year old MX I went with another manufacturer. While it won't help solve snowy911's immediate problem I would strongly advise that he installs a high-speed bi-directional USB isolator on whatever new control board he ends up with for the Paramount. After my MKS5000 was replaced I have always used a USB isolator for the Paramount, originally only a full-speed isolator as high-speed isolators were just not economically viable ten+ years ago, while for the last five-six years I've been using an INTONA high-speed USB 2 isolator, and even though we have seen worse and more prolonged thunderstorms since, that have damaged other equipment in my home TV, Phone, BB Router etc, the MKS5000 has never been damaged again. (Full speed USB isolators are inexpensive but won't support any other devices added to the Paramount's VersaPlate built-in USB hub sockets, the bandwidth is too small, only a high-speed USB isolator is capable of running the mount and additional USB devices that are using the mounts built-in USB hub sockets). If you are interested, the INTONA isolator I used is this one, and it should be placed as close as possible to the mount's MKS5000 USB input, using as short a USB cable between the mount and isolator as possible, the input cable between the INTONA isolator and the PC can be as long as necessary, provided the max length for USB cables overall is not exceeded. https://intona.eu/en/products/7054 As Tomato states above, it is worth seeing if the board can be repaired locally, the USB interface chip is replaceable although only at a surface-mount PCB workstation, it's not really an easy repair to do with just a soldering iron on the multi-layer MKS5000 PCB. The above does all assume that the USB interface chip on snowy911's MKS5000 has failed, the MKS5000 is a very complex board and it's just as likely that some other component failure after the USB interface chip is responsible.... William.

Hi Kenneth. I won't comment on the legal side of the issue, the previous respondents have covered that. I'm not a visual observer so much these days, retinal damage and severe astigmatism have put paid to that aspect of the hobby, but going back to the nineteen seventies when I had a table-top Mak I remember the re-focussing issue when swapping eyepieces very well as that Mak had something like fifty turns of the focuser end-to-end, but the solution to that problem costs nothing. If you add par-focaling rings to your eyepiece barrels then you can interchange eyepieces whenever you want to and only need tiny adjustments to the focus setting. This was something I had to do as I had a wide assortment of eyepieces from different manufacturers and none of them were par-focal natively. Par-focal rings are simply spacer rings that are slid over the barrel of the eyepiece so that it can't slide all the way into the diagonal stop. A par-focal ring adapts each individual eyepiece focal position so that they all match roughly and then you just need a slight adjustment of the main focuser to fine tune any remaining de-focus. You can buy ready made adjustable distance or fixed distance par-focal rings for 1-1/4" and 2" eyepieces or just make your own, I used to make mine by cutting rings from plastic milk bottles and stacking enough on each eyepiece barrel to make the correct par-focal distance. The only problem with par-focal rings was that a few of the eyepieces were so far away from each other in focal position that they were barely held by the diagonal clamp once the par-focal rings were fitted, but most of the eyepieces were fine. Whatever the eventual outcome of your issue with the Mak and whatever you end up with as a repair or replacement have a look at making your own par-focal rings for your eyepiece collection to minimise the time you need to refocus after swapping eyepieces. HTH William.

Hi Ian A late P.S. Browsing the forum again this morning I noticed your desktop screenshot has shortcut icons for Borland C++, a development IDE that I last saw used in Windows over twenty years ago, didn’t know it was still around. Since MaxIm and it’s installer were (possibly) written using C++ and your Borland C++ install may have overwritten the shared C/C++ runtime libraries that all applications written with C or C++ will use I would suggest that before doing anything else you manually install the Windows 10/11 compatible C/C++ redistributable runtime components. This is easy to do, just download and run both these C/C++ redistributable installers from the official Microsoft distribution server, you need to install both the 32bit (x86) and 64bit (x64) installers on a 64bit Windows O.S. If you are running a 32bit version of Windows you just install the 32bit (x86) redistributable: https://aka.ms/vs/17/release/vc_redist.x86.exe https://aka.ms/vs/17/release/vc_redist.x64.exe If you want to read the Microsoft overview for the linked files you can find that here: https://learn.microsoft.com/en-GB/cpp/windows/latest-supported-vc-redist?view=msvc-170 After you run both the redistributable installers you must reboot Windows to make the updated C++ libraries active and after that you can run the Microsoft troubleshooter that I posted in my previous reply before attempting to reinstall MaxIm. If you need to write C or C++ scripts I would use an IDE that was compatible with Windows 10/11 and get rid of Borland, AFAIK it’s long been unsupported and incompatible with Windows 10/11. My own preference for C++ script development is either Visual Studio or Visual Studio Code, both of which are free and fully compatible with current Windows platforms. HTH. William.

Hi Ian. Support for MaxIm DL has no expiry date, you just need to register on the Diffraction Limited support forum and follow the steps to confirm your serial number as described here: https://forum.diffractionlimited.com/pages/TechSupportHowTo/ Once you have completed steps one and two as described in the linked webpage you will be able to request help from the developers via the MaxIm DL specific forum, under the Cyanogen Software sub-forum. Technical support is open-ended and always available to you, it’s only access to software updates and upgrades that has an expiry date and you can purchase extensions for that if you have a need for a later version for some reason. —————————— The pop-up message you are seeing is a Windows error rather than a bug specific to MaxIm DL and I could only find a couple of references to it when I checked the MaxIm forum today. The pop-up message occurs when the program installer failed to register the program correctly in the Windows Registry. Uninstalling - reinstalling MaxIm won’t fix the problem because uninstalling normally doesn’t clear the bad registry entries. With MaxIm already installed try downloading and running the stand-alone Microsoft “Program Install and Uninstall Troubleshooter” which will attempt to fully uninstall MaxIm DL and clear any Windows Registry entries that the normal uninstall process leaves behind, then try to reinstall Maxim again: https://support.microsoft.com/en-gb/topic/fix-problems-that-block-programs-from-being-installed-or-removed-cca7d1b6-65a9-3d98-426b-e9f927e1eb4d If that doesn’t help then register on the MaxIm support forum as described above and ask for help from their support staff. William.

Couple of ideas. I’m not convinced that rapid drying of desiccant tablets in a microwave oven is that effective for large solid tablets, there isn’t sufficient time for the absorbed water in a bulky tablet to migrate to the surface and boil off, it’s a different situation with desiccant beads where the bulk is much smaller, plus some microwave ovens go into a no-load protection mode if the oven detects there is nothing in the oven absorbing microwaves. Try conventional oven drying of the tablets and get them back into the camera as soon as they are cool. The artefact still looks like ice and in shape it appears to be a fingerprint, perhaps that’s just a coincidence but there have been similar fingerprint shaped artefacts reported with ZWO cameras before and these were cured by cleaning the sensor with one-wipe (single use) double-ended sensor swabs and sensor cleaning fluid (Amazon etc). When the cameras are hand assembled on the production line they should be wearing breathable protective gloves but you can imagine the gloves may get a bit grubby and salty after a few hours of wear and the chance of leaving a salty, greasy glove-print on the sensor must be fairly high. Try wet cleaning the sensor using two or three one-wipe (single-use) double-ended swabs from a DSLR sensor cleaning kit and bake the desiccant tablets in an old-tech convection oven for at least an hour. (Make sure to select the right sized swab kit for your sensor, a swab that is too narrow for the width of the sensor will leave a residue trail across one edge, the swab used must be the right size to cover the full width of the sensor in a single swipe) If the problem remains after that then I have no idea what the cause could be and maybe the camera manufacturer tech support would have seen this problem before and have more appropriate advice for you than can be offered here? HTH

“One thing that puzzles me it that if it is dampness inside the camera, why does the noisy area always appear in the same area of the image? I would have thought that the moisture would move around and the crystals, whatever they are, would form on different parts of the sensor?” ——————- When ice crystals form for the first time on the sensor they are usually impure, made of a mixture of water gas and other contaminants, electrostatically bonded to the airborne water molecules before they coalesced and froze on the surface of the sensor glass. Some of those contaminants will be sub-micron sized crystalline dust particles, too small to be seen visually except with an electron microscope, and not visible in the images that the camera produces. When the sensor warms slowly after the cooler is switched off the ice crystals may sublimate directly back into water gas carrying the tiny dust particles with them, or, if the dust carries a strong enough residual static charge it may stick to the sensor glass until it loses that charge and drifts off somewhere else, many days/weeks/months later. If the ice crystals are large enough they may undergo a phase change and will turn to liquid water droplets on the surface of the sensor glass, before slowly evaporating back into a gas, and in doing that any microscopic contaminants that were mixed into the water droplets are left behind, stuck firmly in place by electrostatic charge, or bonded to traces of other organic and inorganic gaseous materials that were present in the sensor chamber and attracted to the water molecules as they coalesced to form ice crystals. The next time that the sensor is cooled those microscopic dust particles left stuck to the sensor glass will act as “seeds” that allow water in gas form to clump together and form ice crystals again. And so, once ice has formed on the sensor one time the tiny traces left behind after it has evaporated make it much more likely that ice will form in exactly the same place again, over multiple cycles, ad-infinitum, and until the sensor glass is physically decontaminated or the water gas is removed from the chamber. The initial shape of the ice field that appeared on the sensor glass the first time that water gas froze into ice crystals is defined by the distribution of heat transfer across the back of the sensor where the Peltier element is not in complete contact across the full width/height of the sensor and a temperature gradient exists as the sensor cooled down to sub-zero temperature, plus the initial “cleanliness” of the sensor cover glass where any pre-existing microscopic contaminants, fingerprint residue or manufacturing polishing flaws will provide the “seeding” sites for ice to coalesce. HTH.

Hi Paul. Before rushing off to replace the mount controller at least test the RS232 serial interface using the loop-back test because you don't know which end of the RS232 link is drifting, it could be the mount controller but it could equally be the computer's RS232 card or USB-RS232 adaptor, if that is what you use. Next time you are at the observatory run the mount until comms is lost, disconnect the mount in the computer astro app and leave the computer running, unplug the RS232 DB9 plug at the computer end first and then disconnect the DB9 plug at the mount controller end of the serial cable and use a piece of stripped wire or a small, straightened, paper-clip to connect (bridge) female pins 2 and 3 at the DB9 plug of the disconnected RS232 serial cable at the mount end, then re-connect the RS232 cable at the computer end only and fire up a terminal emulator app such as HyperTerminal or PuTTY, connect to the same port number in the terminal app that the mount was using and run the loop-back test. If the loop back test is successful then you can assume the RS232 interface chip in the mount controller has become weakened through ageing and the RS232 interface chip in the computer's RS232 card, or the USB-RS232 adaptor is ok. If the loop-back test fails then you can assume that the problem lies with the computer's RS232 interface card or USB-RS232 adaptor. You will need to download a copy of a terminal app such as PuTTY or HyperTerminal in advance and have the wire loop ready to bridge pins 2 and 3 of the DB9 plug at the mount controller end so that you run the test before the RS232 interface components have a chance to recover after disconnecting from the mount. You can find a copy of PuTTY at putty.org: https://www.putty.org When you have a telnet session opened in PuTTY and connected to the serial com port with the bridged pins 2-3 of the DB9 RS232 serial plug then anything you type on the keyboard will appear in the message window and the loop-back test has passed (the letters you type leave the computer on the RS232 DB9 plug TX pin, loop-back via the bridge you made between pins 2 and 3 on the disconnected plug and arrive back in the computer on the RX pin and are displayed on-screen in the Telnet app), signifying that the computer end of the RS232 link is ok, if nothing appears as you type then the loop-back test has failed and the problem is more likely at the computer end of the serial link. You will find plenty of YouTube videos and web documents explaining how to carry out this basic level of fault diagnosis on RS232 serial comms. HTH William.

Hi Jeremy. At that time I was told that the Ursa Minor “should” work ok with the G41, although you had to set the gear ratios and motor currents in the config setup yourself rather than the pre-programmed values, from memory the gear ratios are different between the G41 and G42 and I think the motors were larger in the G42 also. Unfortunately since the passing of András Dán the Gemini website has become defunct and the manuals and specification docs for the original G41 and Pulsar I controller are no longer available to download for comparison with the G42/Pulsar II. As far as the mount protocols go the G41 and G42 are just dumb mounts with no controllers or advanced features so you could use a third party controller using Meade protocols and control it as if it were a LX/Autostar mount or use a controller based on EQASCOM that uses the Synta/Synscan protocols. When I replaced my failed Pulsar 1 controller with a Pulsar II one of the deciding factors over the FS-2 and Boxdörfer DynoStar controllers was the lack of Gemini G41 specific PPEC support, which I recall Ian King saying at the time that it really didn’t matter that much, but I was used to that feature helping with reduced guiding demands and bought a Pulsar II (which was about double the cost of the FS-2!). William.

Hi Paul Was looking for an alternative to the FS-2 myself a few years ago for use with a Gemini G41 mount. Have a look at the Ursa-Minor MC3 MKII: https://www.365astronomy.com/MC3-Mk-II-Motor-Controller-for-Telescope-Mounts?search=ursa No personal experience of these MC3's though, at that time I bought a replacement Pulsar II controller for the Gemini as it was easier to stick with a system I knew. Alternatively, maybe OnStep? although you would need to build that yourself: https://onstep.groups.io/g/main/wiki/3860 Regarding RoHS rules, with very few exceptions, the same rules that allegedly prohibited the selling of the FS-2 in the UK/EU still apply to the UK after we left the EU. https://www.gov.uk/guidance/rohs-compliance-and-guidance#full-publication-update-history I had the impression at the time that the FS-2 was removed from sale in the EU that the issue was more to do with the legally demanding admin side and open-ended EOL manufacturer disposal liabilities rather than the materials and components used in construction, which could have easily been switched to RoHS compliant. HTH William.

Hi Paul. I saw your parallel thread over on the ASCOM forum but that forum is really for problems with the ASCOM platform itself, not device drivers. They will help if they can but with no access to the device hardware, and in many cases the device drivers, there is little support that the ASCOM Platform authors can offer other than refer you back to the device manufacturers / software providers. I have no knowledge of ASA Systeme Gmbh AutoSlew software but I do run a Pulsar Dome myself. The ASCOM diagnostics Device Connection Tester report for the dome doesn't help much in this case because the driver author doesn't write the full DriverVersion ID in the driver header and so the ASCOM diagnostics report for Device Type only shows the first two digits for the driver, in this case = version 6.3. The full ASCOM diagnostics report will show you the actual version ID for the Pulsar DLL, although not in an end-user friendly way. A typical extract from the full ASCOM diagnostics report for the latest Pulsar Dome driver: 10:47:55.921 FileDetails C:\Program Files (x86)\Common Files\ASCOM\Dome\ASCOM.Pulsar_Observatories_Dome.Dome.dll 10:47:56.014 FileDetails Assembly Version: ASCOM.Pulsar_Observatories_Dome.Dome, Version=6.3.9.0, Culture=neutral, PublicKeyToken=5a596dde3293c610 10:47:56.014 FileDetails Assembly Framework: v4.0.30319 10:47:56.014 FileDetails File Version: 6.3.9.0 10:47:56.014 FileDetails Product Version: 6.3.9.0 10:47:56.014 FileDetails Description: ASCOM.Pulsar_Observatories_Dome.Dome You'll find this information repeated multiple times in the full ASCOM diagnostics report wherever a connection between drivers exists but to find it you would need to search the full report using "Pulsar" as the search term and then wade through hundreds of "hits". ------------------- The last Pulsar driver I had at the end of 2022 from Mathew Player at ElecSoft Solutions, who's company produce the dome drive controllers and software for Pulsar Observatories, was version ID 6.3.9.0, and this was de-bugged with Mathew to accommodate the new 64 bit version of TheSkyX. The Pulsar v6.3.9.0 driver passed all ASCOM Conform U tests in both 32 and 64 bit modes and should work with any 32bit or 64bit ASCOM compliant application. I have placed a copy on GoogleDrive if you want to give this a try but be aware that this driver package does update the shutter module firmware automatically (via the Bluetooth link) on first connection and once installed you can't roll back without help from Mathew to back-rev the shutter firmware. I have been using the v6.3.9.0. Pulsar driver with ACP, MaxIm DL and TheSky64/32 with no issues since November 2022: https://drive.google.com/file/d/1Gd2HnT4-YsP9KqGYYtG36XJaNJN5DUgF/view?usp=share_link Other than the above Pulsar driver, another approach you can try is to use the ASCOM Device Hub as a pass-through to allow your 32/64 bit application to cross communicate with a 32/64 bit driver. ASCOM Device Hub will translate ASCOM commands across 32/64 bit interfaces and the Device Hub does that without any additional configuration other than telling your ASA AutoSlew software that ASCOM Device Hub Dome is the dome driver to connect to and in ASCOM Device Hub itself you configure the dome to be your Pulsar Observatories dome driver. The rest of the Device Hub dome geometry settings can be ignored as you will just be using Device Hub as a pass-through conversion but you can if you want to configure Device Hub as a dome controller in it's own right and configure your control application to connect to Device Hub telescope and Device Hub dome then to connect to Pulsar Dome and the telescope in Device Hub, add in the dome/mount geometry settings to the Device Hub configuration and allow Device Hub to manage dome sync and shutter control. You'll find ASCOM Device Hub is installed automatically with the current ASCOM Platform v6.6 SP1: https://ascom-standards.org Can't really suggest anything else except to contact ASA and Pulsar directly as they are responsible for their own drivers and resolving issues for their customers. HTH William.

Hi Nihal You can order replacement O-rings direct from Bresser DE (in Germany), you need two rings for the LS60 Tha pressure tuner but be aware that during production of the THa series Lunt changed the size of the barrel and depending on the version you have you may need the O-ring with size; Internal diameter 32mm, external diameter 40mm: https://www.bresser.de/en/Astronomy/Solar-Astronomy/Accessories/LUNT-O-ring-32mm-for-Pressure-Tuner-at-MT-THa-solar-telescopes.html Or, Internal diameter 34mm, external diameter 42mm: https://www.bresser.de/en/Astronomy/Spare-parts/LUNT-O-ring-34mm-for-Pressure-Tuner-at-MT-THa-solar-telescopes.html You will also need to clean the old grease from the barrel and piston and replace with fresh Lithium-Teflon grease: https://www.bresser.de/en/By-Manufacturer/Lunt-Solarsystems/LUNT-Grease-for-Pressure-Tuner-at-MT-THa-solar-telescopes.html Here is the instruction document explaining how to exchange the rings and the different sized rings and their Bresser part numbers: https://www.bresser.de/out/media/4bdcac812d37f790b5f779b21fd0fa76.pdf HTH William. P.S. If you find that the Bresser DE website won't accept your order for shipping to the UK, as many European businesses are refusing to register as unpaid UK VAT collectors and are unwilling to ship direct to UK customers, then contact FLO to see if they will order them for you.

There are two issue with your dark frame: The dark current looks normal, assuming as DaveS point out above the temperature discrepancy in the image FITS header, where the set temperature is recorded as -26 deg C. but the actual CCD temperature reported is ambient, +17.7 deg C. It appears that the CCD cooler is not switched on in N.I.N.A, or the camera cooler is not running for some reason (low supply voltage auto switch-off protection for example, or something else?), and this is reflected in the dark current values. The other issue is that the image size is incorrect, according to Moravian the active sensor size should be 4524x3624 for the g3-16200: https://www.gxccd.com/art?id=366&lang=409 This is different from the active sensor size as detailed in the OnSemi data sheet for the KAF-16200 sensor = 4500x3600 (see linked data sheet below) https://www.onsemi.com/download/data-sheet/pdf/kaf-16200-d.pdf It appears that Moravian by default include a little of the unused sensor overscan dark region in their camera specification as well as the normally unused blue-only bayer filter at the edge of the bayer array in the colour sensor version KAF-16200C. Your dark frame however is showing a sensor size of 4630x3694 and is displaying the normally hidden overscan, test and buffer regions at the top, bottom and side edges of the sensor (see page 3 of the linked OnSemi data-sheet above). Overscan regions may be switched on-off in the camera driver and may also be accessible directly from the capture application (N.I.N.A.?). Except for special imaging techniques the overscan regions of the sensor should not be captured and should normally be deselected in the camera driver or the capture application where these are user selectable. I don't use N.I.N.A. and can't advise how that capture application deals with the overscan regions. Is this a mono or colour camera?, not that it makes any difference to the sensor array size and overscan regions, which are identical for the mono and colour versions of the KAF-16200 sensor. The FITS header is reporting a colour bayer array present and is a colour camera. HTH William.

Hello Erik. This morning I installed MaxIm Dl 5 (v5.24) on a virgin copy of a Windows 11 PRO VM and as as expected it installed and registered correctly. There is no reason that it should not install and register on your Windows 10 Pro machine. If my advice to use copy and paste from your original license email (or a .pdf or .txt copy of that email) into the registration applet does not work even though you have confirmed that your number and date format, regional language options and keyboard mapping is correct for your new Windows 10 machine then you will need to contact Diffraction Limited via the support forum for specialist help: https://forum.diffractionlimited.com/ It's possible that when you were trying to register while running MaxIm under "As Administrator" elevation that it has saved some corrupted keys in the Windows registry, you will need the help of Diffraction Limited support staff to tell you which keys in the registry need to be manually deleted so that you can begin again. HTH William.

Hi Erik. Can you try copy and paste from your original v5 license email into the registration fields instead of typing in manually? Unfortunately the only machine I can try my own old copy of MaxIm DL5 on is a Windows 11 Pro virtual machine running on a Mac, I can try that tomorrow and see if it will register there and update the thread later. If you can register v5 on your Win 10 Home machine ok it doesn’t make much sense that it won’t register on the Win 10 Pro machine also, and in the few cases when this has been reported on the MaxIm forum it was due to the date and number format on the target machine being incorrect so that the registration applet was not recognising the license expiry date as valid and I recall one reported problem caused by an incorrect keyboard map that was inserting a hidden character in the user name and email address line, if you can use copy and paste from the original license email instead of typing in the registration details then a keyboard mapping issue can be ruled out. I’ll try installing v5 on my Win 11 VM and let you know how that works out tomorrow. William.

Hi Erik AFAIK MaxIm DL5 is compatible with Windows 10/11 Pro, at least, I have it had it running with ASCOM device simulators on both Windows 10 and 11 virtual machines in a Mac environment. When starting up MDL5 for the installation and registration it should not be run “As Administrator” until the installation is complete and the registration is successful, you must start up MaxIm “As administrator” one-time-only after the installation and registration is completed so that MaxIm’s scripting and automation interface is registered with Windows scripting host but that has no effect on the licence registration process. I would start by making sure that Windows .NET 3.5 is enabled in Windows Features and Options and that your regional date and number format options are set correctly in Windows. You also should have installed the ASCOM platform prior to installing MaxIm. Beside the above, manually install the latest Windows C++ redistributable packages for both x86 and x64 architecture (you need both x86 and x64 redistributable runtime packages installed on a 64bit Windows machine to run 32bit applications written in the C and C++ language). You can find the x86/x64 C++ redistributable installation packages on this Microsoft webpage under the section heading ”Visual Studio 2015, 2017, 2019 and 2022”: https://learn.microsoft.com/en-GB/cpp/windows/latest-supported-vc-redist?view=msvc-170 If none of the above is of help then post your question on the Diffraction Limited forum for access to the developers: https://forum.diffractionlimited.com HTH William.

Hi Joe. Others have already replied to the part of your post regarding the dust shadows and judging from experience those in your sample image are most likely caused by dust on the filters. Your photo of the lens cell does not have sufficient resolution to be certain but it does appear to show signs of lens fungus, which needs to be treated otherwise it will spread across the surface of the lens and etch the glass. If you examine the lens closely and can see what looks like strands of fine cotton-wool, grouped in clumps or “fingers”, then you probably have some fungus growth and that will already have begun etching the glass. Fungus on the outermost sides of a lens element can be killed by exposure to strong UV-C light and fungus residue removed using regular lens cleaner but any etching damage to the lens is permanent. There are no engineered radiation sources available to the general public that are strong enough to penetrate more than a few mm of glass and fungus growing on the rear side of lens elements in a cell can only be killed by disassembly of the cell so that the inner surfaces can be accessed. Glass fungus thrives in dark, warm and humid conditions so if you are in the habit of capping the lens when the observatory is closed for long periods, or if the observatory itself is warm and humid, then you have ideal conditions for the airborne fungus spores to grow on the lens. Regular exposure to sunlight and fresh air is said to help kill the fungus. Hopefully, the suspected appearance of lens fungus in your lens-cell photo is just an artefact, if not, then this reply might help you avoid further lens damage now, or in the future. William.

Looks like a missing system file error. Report that to Colin Dawson though his Discord web page and he will help you with that. I can see from your screen shot that you have "Trace on" enabled in the driver set-up dialogue so you should have an error log for the driver stored on your computer that you can forward on to him, that will be more helpful to him than the screen shot. You will find the log(s) in your user Documents folder > ASCOM folder > Logs There is a short video here showing how to enable/disable the Meade driver log and where to find it:

Hi Tim. Long experience with astro software and computers in general has shown me how totally unreliable they can be, at some time or other they will fail and the roof will close with the OTA in the way. For unattended observatory automation with a collision risk it is absolutely essential to have a back-up system on the mount to prevent the roof closing if the OTA is not parked. Simple tilt switches on the OTA and a relay circuit to break power to the roof actuator when the mount is not parked are all that is needed, the cabling to the switches doesn’t need to be that intrusive or untidy. Good to hear that Colin Dawson’s Meade ASCOM driver is working for you, don’t hesitate to contact him via the Discord site if you run into any bugs and he will work with you to fix those ASAP. William.

Hi Tim. If your LX850 has the AutoStar II / AutoStar #497 controller you might find that the cjdSkunkWorks AutoStar #497 ASCOM driver will work, if not, the author, Colin Dawson, will work with you to iron out any bugs: https://bitbucket.org/cjdskunkworks/meadeautostar497/wiki/Home The AutoStar #497 ASCOM driver is in the downloads folder on the linked page. In the absence of any interest from Meade to develop ASCOM drivers he is developing his own “Universal” Meade driver that can work with all Meade telescopes. He can be contacted through his Discord page under the support section of the website linked above. Other than the above, you might find that employing the ASCOM Device Hub as a go-between to connect your observatory control program to your current Meade ASCOM driver will work as Device Hub can translate and forward 64-bit observatory control applications commands and messages to 32-bit telescope drivers, and vice-versa. ASCOM Device Hub is built-in to the current ASCOM platform 6.6SP1, update to this platform version if you have not already done so, (link to the ASCOM page below), then start ASCOM Device Hub from the main ASCOM application folder and configure your Meade ASCOM driver as the telescope in Device Hub’s tools menu and “connect” to the telescope in the main window of Device Hub. Provided that the connection is successful then In your observatory control program set the Telescope type to ASCOM - Device Hub Telescope and “connect”. You can ignore the Dome configuration section of the ASCOM Device Hub, it has no function unless you want to add full dome automation into Device Hub’s control capability. If you need it, there is a concise help document built-in to Device Hub, accessible from the main Device Hub menu. https://ascom-standards.org Can’t think of anything else to suggest, hopefully someone else will have some personal experience with the LX850 ASCOM drivers and can offer a more specific solution. William.

Agree with Francis on this aspect, not only the issue of maintenance but also you need to think about where the rain water run-off will go. Over the years I’ve had to deal with too many rotten shed base rails and lower rear walls where the previous owners had placed timber sheds and garages right up to the boundary fence leaving no room for guttering to take roof run-off water to a soak-away or water butt. All the rainwater run-off ends up being dumped on a few inches of ground behind the shed where there is no air movement to dry things out and a result the timber rots really quickly. For my own installed sheds and garden buildings I’ve always left at least 300mm between fence and building to allow access for annual preservative treatment (applied with a long-reach garden fruit tree sprayer) and to allow for guttering along the rear wall without overhanging the fence. William.