Oddsocks

I don’t have any first-hand experience of this particular model and maybe it’s normal, or just an artefact of the way the photo’s were taken, but I’d be a little suspicious of the (apparent) missing section of “O” ring/gasket seal surrounding the corrector plate on the right-hand side, from the letter “U” in the “Multi-Coated” text extending down almost to the bottom of the plate. There is a smaller gap in the “O” ring gasket on the left-hand side by the “mm” letters for the focal length specification, which may or may not be normal. Without being able to compare to an untouched model I’d be a little suspicious that the corrector plate had been removed for cleaning and the “O” ring/gasket had broken or crumbled away leaving some large gaps. Maybe someone here has owned one, or still has one, and can comment further?

Hi Nicolàs. Here are five sample 0.5s darks from a QHY268M all at -15c. https://www.dropbox.com/scl/fo/ju1ai9wtjm0ljwmr8za2n/h?rlkey=shytpkndpaluyqik6rq9ztgyy&dl=0 These are nothing like your test images, the hot pixels in your images being mostly a uniform ~24,844 ADU is not normal, and this is not replicated in the images from my own camera. The file headers in my samples have all the information you need for comparison and the images were captured with MaxIm DL v6.40 with only the FITS headers being sanitised for personal identifiable information in PixInsight before saving and uploading to DropBox As I only have the 2GB basic DropBox allowance I'll only host these for seven days before deleting, I don't have the storage space to keep them longer. The five frames were taken with the following settings: 0.5s, Dark, (Covered OTA wrapped with darkroom blind material and closed Flip-Flat), ExFullWell_2CMS curve, Gain:26, Offset:16, -15c, Fast Readout mode. 0.5s, Dark, (Covered OTA wrapped with darkroom blind material and closed Flip-Flat), ExFullWell_2CMS curve, Gain:26, Offset:16, -15c, Normal Readout mode. 0.5s, Dark, (Covered OTA wrapped with darkroom blind material and closed Flip-Flat), ExFullWell curve, Gain:26, Offset:16, -15c, Fast Readout mode. 0.5s, Dark, (Covered OTA wrapped with darkroom blind material and closed Flip-Flat), ExFullWell curve, Gain:26, Offset:16, -15c, Normal Readout mode. And a comparison file with the settings I normally use: 0.5s, Dark, (Covered OTA wrapped with darkroom blind material and closed Flip-Flat), PhotoDSO_2CMS-0 curve, Gain:26, Offset:10, -15c, Normal Readout mode. Before condemning the camera try acquisition with a different capture program, just on the off-chance that the capture program you used to test the camera has not correctly set the requested capture curve and gain/offset values, also be sure that the QHY Drivers/capture software is up-to-date. HTH William.

If I understand PI WBPP and DSS, the principle differences between them are that PI performs a deep analysis of each individual frame and gives it a score, or “weight” for several image parameters, as indicated by the PI tool's name Weighted Batch Pre Processing. That deep analysis is partly the reason for the higher computer processing overheads and longer time-to-complete when stacking subs in PI compared to DSS. Juan Conjero, author of PI, has stated many times that the single output combined image from a run of WBPP (and the previous non-weighted version of WBPP, BPP) is only a preliminary image and that by going back and recombining the calibrated .xisf subs with small changes to the combination parameters may yield superior results. Knowing which parameters to change is where the “learning curve” with PI starts to bite. If all your subs are of uniform high quality, with low noise levels, good star shapes etc., then I would not expect to see a huge difference between the preliminary output image after a first run through with WBPP in PI and a run through with DSS, but if the source subs were highly variable in quality, especially with regard to noise, then I would expect to see some more apparent variation between a DSS processed image and PI WBPP processed image, with the PI WBPP image having a lower background noise level in the dark, low-contrast areas of the image as the weighting process kicks in on a pixel-by-pixel basis rather than a whole-frame basis during the combination stage. lastly, with the weighting analysis scores that were calculated during the WBPP process being saved with the calibrated .xisf subs that are automatically output from a WBPP run those scores can then speed up processes used by other PI tools during post processing because the subs don’t need to be analysed a second time (if for example you are carrying out a second recombination of the calibrated .xisf subs in the Image Integration tool using modified integration parameters). Don’t know why, but writing this summary I can feel @ollypenrice peering over my shoulder, trying hard not to laugh…..🫢😅🫢. HTH. William.

I don’t know this particular application but maybe its the Visual C/C++ runtimes that you need since these aren’t distributed with Windows 11 and rely on the application’s own installer to add the redistributable support libraries if necessary. Try downloading and installing manually both the x64 and x86 Visual C/C++ redistributable libraries linked below. You need both x64 and x86 packages installed on a Windows 11 64bit O.S. since these are application bit-version specific libraries rather than O.S. bit-version specific. After running both installers you need to reboot the computer to make them available to any application that requires them, then after the reboot try installing your application again. Both download links below are direct to Microsoft’s own servers but if you want to verify the source addresses and read more you will find that on >this< Microsoft webpage. https://aka.ms/vs/17/release/vc_redist.x64.exe https://aka.ms/vs/17/release/vc_redist.x86.exe HTH. William.

The original QHY8 (square camera with unsealed sensor chamber and dedicated desiccant storage/drying case) had an unregulated two-stage TEC, on paper capable of -40 delta .C although I doubt many actually achieved that in the real world. Back in the early days of cooled astro CCD cameras, unregulated TEC cooling was not uncommon and there were two ways of dealing with the resulting changing dark current as the session progressed and the sensor reaches lower temperatures. Either, take light-dark, light-dark, light-dark repeating pairs during the session and calibrate each light with its matching dark frame before combining the calibrated frames, or, use a master bias frame and master dark frame, taken at the end of the session when the camera has reached minimum temperature, and use the Dark Frame Optimisation routine found in many post-processing applications to automatically vary the ratio of dark frame subtraction from the light frame according to a measurement of residual noise in each calibrated frame, and then combine the results. For your early QHY8 camera with an unregulated TEC the sensor should reach a reasonably stable temperature after around thirty minutes and cooling can begin at twilight while the OTA is still acclimatising, and for greatest efficiency take master dark frames and master bias frames at the session end and use Dark Frame Optimisation during calibration in preference to matching light-dark, light-dark, light-dark repeating pairs. On the camera hardware side, if your QHY8 camera has a heatsink fan (or fans) make sure it/they are still working, the electronics was rather crude on cameras of this era and a broken fan might not be monitored, which would result in the camera cooling much more slowly than normal and fail to reach maximum delta .C. Also, make sure that the heatsink fins are clean and not choked with dust, the end result is just the same as with a broken fan, poor cooling. TEC coolers do have a finite life and if a camera has a two-stage TEC it’s possible for one of the pair to fail, again, its likely that the electronics of this era would not detect a failed TEC and the result would be a greatly reduced delta .C capability, which would fit with your observation of a slowly improving image after many hours of use. Final hardware tip, the TEC cooler stack will be bonded together, and also bonded to the back of the sensor, with either a thermal transfer pad, thermal grease or thermal paste. The latter two will dry out over extended time and lead to reduced cooling efficiency. If your camera has been in use for many years and it uses thermal grease or compound it’s possible that the old thermal grease/compound needs cleaning away and renewing. If you feel that camera cooling performance has changed and is not as efficient as it once was then the above tips may point to a possible cause. Lastly, improving image quality as the session progresses might not all be attributed to a lower sensor temperature, target altitude (rising target), local light pollution levels (auto-dimming street-lights, neighbours turning out their house lights) and daytime atmospheric dust gradually falling back to the ground leaving a clearer sky can all contribute to improved image quality the longer that the session continues. William.

I also looked at all your light frames and as the previous respondents have noted, most of the frames are unusable, I only found eighteen that were even close to being usable for integration. Of the best frames, the stars in nearly all those frames were slightly out-of-focus with a clear central black disk and outer bright ring, also, there was some hint of mis-collimation of the telescope. Of the full set of lights, approximately half appeared to have a low SNR, possibly taken under deteriorating sky conditions, hazy thin cloud perhaps, or the target becoming closer to the horizon? Some practical suggestions..... As you have a heavy camera attached to the back of the Alt/Az mounted telescope try to add sufficient counterweight to the front of the OTA so that the tube is balanced, that will help reduce tracking errors. You should find it possible to make your own counterbalance weights from scrap material for virtually no cost. While imaging, resist the urge to walk around close to the tripod. The standard Celestron tripod with the 8SE is a rather flimsy affair and will react to footfall close to the tripod unless on solid concrete or hard ground. If you can keep the telescopic legs of the tripod unextended, or as short as possible, and set up with the telescope as close to the ground as you can get then that will help with stability, and, if you can add some sandbags above the spreader plate for the tripod legs that will help dampen down any tripod vibration. If you haven't already a Bahtinov mask in your toolset to aid focusing you can make one for virtually nothing, details >Here< Finally, review the collimation of the telescope and make sure the telescope is collimated at the same OTA angle that will be used for the target, or at least, point the telescope to the zenith for the collimation adjustment so that any mirror flop that pushes the collimation out of adjustment with changing OTA angle will be roughly the same either side of the meridian. William.

That should probably be ok, unfortunately Baader are rather cagey about what exactly goes into that product and they don’t publish a hazchem leaflet but they mention alcohol in their Q&A section so most likely its just a mix of Isopropyl Alcohol, deionised water and detergent, which is safe enough for cleaning lenses, mirrors and the AR cover-glass on most CCD and CMOS sensors. Sony don’t publish any useful information for consumers about how to clean their sensors and have always been rather secretive in this area however other manufacturers are more helpful and this OnSemi document gives very clear guidance on the types of chemicals that can be used and the recommended methods (see page 3/4). The most common mistake when cleaning a cooled camera sensor is to spray the cleaner fluid onto the cover glass and make it too wet, the cleaner fluid should be sprayed lightly onto the cleaning swab/spatula and if as you drag the swab/spatula across the surface of the cover glass it leaves a trail of droplets behind then you’ve used too much liquid. Not all types of contaminants can be removed with alcohol. Silicone oil that is typically used as a component of heat-sink compounds for the interface between the TEC cold-finger and the back of the sensor package is particularly difficult to clean away and if that gets on the cover-glass it requires chemical solvent cleaners that are both toxic and capable of damaging the AR coating on the cover-glass, as well as possibly dissolving the glue that bonds the cover-glass to the sensor package. If silicone oil ever does contaminate the cover-glass it’s best to have the camera professionally cleaned unless you have some experience of handling hazardous chemicals and can be sure which materials have been used in constructing the sensor package. The work you have carried out should have made some improvement and I can’t think of anything else practical to suggest beyond the contributions already made to this thread. Have you tried opening a case on the camera manufacturers support forum, or emailing the retailer you bought the camera from to see if they have any previous experience of this problem? I’ll keep watching your thread and reply back if I think of anything new but right now I’m out of fresh ideas. William.

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.