Oddsocks

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.

Richard. I noticed that your topic on the PixInsight forum seems to have fallen off the radar, not that unusual for sporadic issues such as these. To re-start your P.I. thread you will need to provide the data that is causing the problem, the P.I. authors won't reply to you without that. Upload your problem image to Dropbox or GoogleDrive and post a share link in your P.I. thread and hopefully one of the dev's will take a look at it. This kind of problem crops up sometimes due to memory exhaustion, or some kind of corruption in the data. One thing to try yourself is just take three of the best calibrated RGB frames, un-stacked, and assemble into an RGB image then run DBE and SPCC. If this succeeds then go back over your original input data and check for bad frames that might have slipped through to the combined RGB image and that are problematic for SPCC. Other than the above, when the problem occurs check how much RAM memory is available and whether P.I is shuffling data between swap folders because it has run out of usable RAM. If you have not configured a swap folder on your HD for P.I. to use as virtual memory then try that since Windows has a problem sometimes managing that for itself. Lastly, if P.I. crashes for any reason it might leave behind orphaned temporary files in the temp folder, and any swap folder that you create for yourself, so check in your C:/Users/<your user name>/AppData/Local/TEMP folder for any orphaned P.I. files and delete them, then do the same for your HD swap folders if you created those and configured P.I. to use them. William.

Phil. Don’t forget, when calculating the back-focus distance that adding filter glass in the optical path pushes the focal point (between the filter and the camera) further back by an amount roughly equal to 1/3 the filter thickness. If you use 2mm thick filters in the drawer the focal point will be ~0.66 mm further out and you would probably need to add one or more fine delrin spacers to reach focus, even with the 7mm adaptor.

It sounds as though you missed a step, from memory, last time I used Rufus and after you press the Start button there should have been a small pop-up screen with a list of options to build the boot media, one of those options was "keep user files and settings", that check box option must be selected otherwise when you build the boot media you create an installer that doesn't offer you the chance to keep your files and settings, only carry out a clean install. I had a quick scan through the video that Cornelius liked to but I don't see that step anywhere in the video, maybe the latest build of Rufus has added that final step and it was not there when the video was recorded. Try one last time, reformat the thumb drive as before and pay careful attention to any pop-up screens that appear after you press the Start button in Rufus, if you don't see a pop-up message with the list of options after pressing the Start button for the first time try moving the Rufus API window around, it could be that the pop-up message is hiding behind the main window. If Rufus starts to build the boot media without asking you whether you want to "keep user files and settings" then I don't have any other ideas as this is the way it worked last time I used Rufus.

Peter. Rufus won't see the thumb drive once it has been used to create the boot media. Start with the Windows Disk Management tool , find the thumb drive in the list of disks and delete both partitions on that drive, then create a new "simple" partition on the drive using the full disk capacity available (IOW, make no changes to the default size allocation) and format the drive "FAT32". Exit Windows Disk manager and start Rufus, it should now see the thumb drive again and allow you to continue. HTH

Peter. Just as a FYI for anyone else reading this thread, Windows 10 support is officially slated to end in Oct 2025: https://learn.microsoft.com/en-us/lifecycle/products/windows-10-home-and-pro One major drawback with the Rufus method for upgrading Windows 10 to Windows 11 on unsupported hardware is that it is likely you will need to repeat this process in the autumn of every year in order to install the latest "Feature" release of Windows 11, and, it is possible that Microsoft will move to block this method of bypassing their compatibility checks at some point. William.

Hi Peter. AFAIK there have never been UK English only Windows ISO’s, when I have used Windows ISO’s in the past for repairs or new install I’ve always used the US English option and then used the language and other locale options in Windows after it is installed to set up specific UK keyboard, date/time, number format etc. If you didn’t select US English option then maybe that’s why you were warned about the apps being deleted? William.

Hi David. While waiting to hear back from them, run the Astrohub_1-0-6_Setup.exe again and just confirm that the ASCOM driver is not a user option "checkbox" that you must select before proceeding with the install. William.

Hi David. I've never come across one of these focusers before and can't offer anything specific but in general, the starting off point should be to see if the ASCOM Driver was properly installed. Assuming that you're current with the ASCOM platform v6.6SP1 then from the Windows programs menu go to the ASCOM Platform 6 program folder and scroll down to the Profile Explorer, double click to open and in Profile Explorer, left side pane, click the "+" symbol against Focuser Drivers to show all the current ASCOM focuser drivers installed on your computer. If there isn't a listing for the 4tronix focuser then none of your astro apps will be able to find it either. If there isn't a 4tronix focuser driver installed have a browse of the supplied driver media, maybe the ASCOM installer is a standalone installer that has to be run manually. One reason that an ASCOM Driver is not installed correctly is that its installer targets the ASCOM platform version when the installer was written and if you have a later or earlier ASCOM platform installed then a badly written installer just fails silently, not installing the driver and not giving an error message. The other thing to check is your A.V. software, maybe that saw the ASCOM driver installer as a threat and has quarantined the driver. Besides those possibilities there might be an operational issue with the "bitness" of the driver, 32-bit v 64-bit, but that shouldn't stop it being installed and visible in the ASCOM Profile Explorer. Can't think of anything else A.T.M. William.

Hi Jon. Ok, the image you linked has very little signal but there was just enough to tease out the Rosette structure. The .FITS header has these keys and values for the bayer pattern, derived from the camera manufacturers driver: (Note: I read this .FITS header in PixInsight as I could not remember where the .FITS header viewer was in SiriL). The default pattern is BGGR (BAYERPAT) and the manufacturer adds the note "Try GRBG if image upside down or R/B swapped". The Bayer pattern that was used in SiriL Preferences to open the image was the default BGGR, as shown below, you will see that as expected the image is green because as explained earlier this is raw data from the camera and it has twice as many green pixels as red and blue: After running Colour Calibration, Background Neutralisation and White Balance adjustment followed by a Histogram Transformation you can just begin to see the Rosette is beginning to emerge from the background noise with the correct hue: Above the preview image are four tabs, Red, Green, Blue and RGB, if you click on the Red tab you will see only the information in the Red channel and in this image the only nebula structure that appears is in the red channel, the blue and green channels have only noise and a few stars, this is a double check that the Bayer pattern used, BGGR was the correct choice. When you import a stacked image the noise will be much reduced, the signal stronger and the colours easier to separate. For future reference, when opening a raw .FITS image from this camera in SiriL the image should appear green when "AutoStretch" is applied and before you begin with colour calibration, if the image appears magenta then the image read sequence is reversed and the Bayer pattern selected in SiriL Preferences should be GRBG. HTH William.

Hi Jon. I’m afraid it’s impossible to guess without having access to the original .FITS image, many forum members here use SiriL and could most likely quickly determine the correct deBayer and post display settings in SiriL for you, or at least have a suggestion as to where the problem originates. Image flip in SharpCap should not affect the raw data, no astrophotography capture program should ever modify the raw data in a destructive manner, if they do there’re not worth using. A green cast across the entire image (both background and objects) is not unusual after DeBayer for a colour camera since there are twice as many green pixels as red and blue and the green imbalance is normally fixed in post processing, colour calibration, but whether this is the case with your image is just conjecture at this point.

Hi Jon. @alacant needs the raw. unprocessed .FITS image straight from capture save in SharpCap to be able to offer a Debayer solution for Siril. If you can't attach a .FITS format image directly to your reply use a free file share host such as GoogleDrive, DropBox or OneDrive to host the .FITS file and post a public share link back with your reply. FWIW, I believe there is a Debayer bug in the current build 1.0.6 of Siril where if you have Siril preferences configured to use both the .FITS header Bayer mosaic pattern manually configured and also the option to use "Bayer information from FITS header if available" then Siril gets confused when the manually configured and auto detect patterns differ. For SharpCap single frame grabs using an old ZWO ASI120MC for solar Ha imaging I have the following FITS/SER Debayer preferences settings in Siril: "Bayer information from FITS header if available" = Deselected. "Bayer mosaic pattern" = GRBG (for an old ZWO ASI120MC). "Debayer interpolation" = VNG4 (for stars, solar and planetary, or select method RCD for star images) "Debayer FITS in top-down if no explicit keywords found" = Selected. Note: the Bayer mosaic pattern selected by Siril uses the specific top-down or bottom-up readout order FITS header keyword value provided by the camera driver (ZWO). If that keyword value in the FITS header is incorrect then the manual choice of Debayer pattern will need to be inverted. Remember that the preview image open in Siril is not the latest version of the Debayered image, after running the process to Debayer a file with a particular bayer pattern selected you have to go back to the file menu and open that new image that was saved by the process, otherwise you will not see any changes. HTH.

Hello Dave. Your sample flat looks ok now that you have dealt with those coupler reflections. You might want to check out this short blog, I had this bookmarked from many years ago and came across it again yesterday, you'll be particularly interested in "Figure eight" I think: https://diffractionlimited.com/flat-fields-stray-light-amateur-telescopes/ Regarding standards in amateur astronomy generally it's been my experience that "amateur" applies to both the target market and also many of the suppliers. Go back a few decades and there were quite a few suppliers who had entered astronomy equipment production from an A.T.M. background but were not formally trained or qualified in optics, or engineering generally, and have no understanding, or the desire to learn, how to implement the Japanese business model "Kaizen" or principle of "Change for the Better" or "Continuous Improvement" of which rigorous Q.A. processes are a fundamental component. It is sadly still common today in the amateur astronomy field that a small manufacturer will design and build a "widget" and then stick to that design come-what-may despite any shortcomings that may be revealed over the coming years, simply because they see it as too much trouble to change things and there's no market pressure for them to do so, there will always be new customers coming along with little experience in the field and will be influenced by the marketing hype. Sadly too, I have seen far too many gushing amateur (and paid "influencer") YouTube reviews of astronomy equipment that has just arrived on their doormats saying how wonderful the product is and then when defects are revealed after a few months or years of use there is no follow-up informing would-be purchasers that their initial assessment might have been a little too favourable. I realise I'm a little biased, coming from a medical engineering background where a small engineering oversight could lead to litigation costing millions, or possible imprisonment for negligence, it was impressed on me right from my trainee days that attention to quality, procedures, and reporting were paramount. All of the imaging components on the medical systems I worked with for over forty+ years were properly blackened inside the focal path, not an unpainted plain black anodised surface or unfinished screw-head to be seen! Good thing this astronomy lark is "only a hobby". 😂 William.

That looks much better Dave, your Cetus A image is very similar to those I get with my ODK10 and QSI683 (KAF-8300 CCD sensor). You are correct that any changes to the baffling to deal with those off-axis spider shadows would produce calibration frames incompatible with previously captured data. (I know those Orion Optics spacer knife-edge baffles very well, still got the scars) William.

Dave. The dark spider shadows in your images are the same that were seen in the RC images on the PI forum that I mentioned above and the cause was identified on that system as described, off-axis light entering the primary baffle tube and reaching the camera sensor by way of edge reflections off some black-anodised but very shiny un-baffled camera spacing tubes, just in front of the camera port. I can't remember all the details now, it was too long ago and the old PI forum was erased when they moved to new forum software back in 2020/21?, or was it earlier, memory not so wonderful these days, but I think the primary culprit was a distance spacer for the flattener on that RC system. But other than that, your calibration is plainly not working, the image with flats added is over-compensated leading to the dark centre and bright edges (reverse vignetting). Assuming these images are with the Moravian G3, you don't need Flat-Darks with these Kodak KAF 16200 CCD sensors, just a regular Master Bias, Master Dark and Master Flat. Flat-Darks are generally for CMOS cameras with unstable outputs when taking zero-time Bias exposures, the Kodak KAF16200 is very stable and produces very consistent Bias frames which makes for much easier calibration. HTH William.

Dave. In this case a written description of the artefact is not really sufficient to determine the cause, if you upload an image showing the problem that might help pin down the cause should someone else have seen the same issue. I have never seen shadows of the spider or secondary in images from my own ODK10, used with a FLI Atlas focuser and QSI683 camera, but I have come across images taken with a 10” RC that appeared to show out-of-focus “shadows” of the spider and secondary in lights and flats that also would not calibrate out. The source for those artefacts were edge lensing from un-baffled; plain-black-anodised; spacer-couplers, close to the camera. You can produce the same effect visually if you look through any reasonably smooth piece of black anodised tubing held close to your eye, an image of the central bright opening at the far end of the tube is reflected back along the walls of the tube, slightly off-axis, to form a secondary image at the focal plane. In the case of the RC the problem was solved by adding some flocking material to the inside of the spacer-couplers closest to the camera. There was a thread running describing the problem and the resolution on the PixInsight forum about four or five years ago. Any in-line reflector design with a large diameter secondary requires an equally large diameter and/or short primary baffle, which then allows off-axis “edge” focussing via any poorly baffled and blackened couplers or spacers between the forward end of the primary baffle and the camera to occur. This secondary image is off-axis light that enters the focal path directly from the front of OTA and into the primary baffle opening where it reflects off the walls of any un-baffled plain-black couplers and into the camera. The artefact created by these unwanted “edge” reflections look like fuzzy “shadows” of the spider and secondary in flats and lights, and have quite a strong gradient, darker and wider towards the outer edges of the spider arms and growing fainter and thinner towards the secondary shadow in the middle of the image. The above case on the PI forum was the only one I recall reading about, and that had images attached showing the artefact, and may be describing a problem quite different to yours. If you can show an example image maybe someone else will have seen the same and have the correct explanation and answer for you. William.

OK, it's not the scripts that need running "As Administrator" one time, it's the program that uses them, is that EQMOD? or???? Not having used EQMOD or EQASCOM I don't know how those work together.

I don't know EQASCOM at all but the error message is common when an applications scripting interface is not registered correctly with Windows. Try Mouse-Right-Click on the program shortcut for EQASCOM and select "Run as Administrator" from the pop-up context menu. Let EQASCOM launch fully then close it down again without making any changes. Now launch EQASCOM normally, without ADMIN rights this time and try to configure, does this fix the problem?