cjdawson

Welcome to SGL. Using Sharpcap Pro with an LX-90 is a great way of getting excellent PA. All that you need to do is follow the wizard on screen, which will walk you through the process. On the LX-90, the manual adjustment bolts are the Alt-Az alignment bolts. The Az bolts are the ones on the bottom part of the tripod that presses against the tab that sicks out. The Alt adjustment is the four bolts that hold the wedge at the desired angle. You should have a really long bolt that you can use to fine tune the alt, it does this by literally rocking the whole of the fort mount section. Apart from that, the rest of the instructions are exactly the same as any video tutorial that you can find on PA using Sharpcap Pro. I'd highly recommend it. Colin.

You are not limited to the number of images (known as "sub frames" or "subs" for short) that you take. However there are diminishing returns for the amount that you take. What I mean is that if you take 1 sub. Taking 2 subs will 1/2 the amount of noise in the image. Taking 4 will 1/2 it again, and so the sequence goes on, 8, 16, 32, 64, 128 at this point if you want to 1/2 the noise you'd need to take another 128 images. However the longer that you expose, the more detail you can bring out of an image. The exposure time of each sub frame is what determines the overall brightness of the image. The trick is to make sure that you capture as much light as possible without over exposing the image (same rule as daytime photography) How long you can expose for really depends on your camera and the settings. As you are talking about ISO 1600, I'm going to assume that it's a DSLR, so you would be better taking lots of short exposures, I'm talking maybe 15 seconds a sub frame, but the important thing here is to look at the histogram of your first image. It's best to make sure that the big spike of data has been lifted off the left hand side of the chart, that means that you are capturing more data. But most of all, make sure that you don't over let data get all the way to the right as that will overexpose the stars. The rule of thumb is that the more subs you take, the less noise in the final image, and the more that you can process it afterwards. It doesn't matter if you take 1 image with a 60 minute exposure , 60 images with a 1 minute exposure or 3600 images with a 1 second exposure. You'll still end up with 1 hours worth of integration time after the stacking has completed, and when you stretch the histogram of the final combined frame they should all look the same. (That's the theory, there are many caveats, but I want to keep things simple)

I don't know about 2" stuff, for my planetary camera, I use a 1.25" barlow normally my 4x barlow at that. And not much else. For my Deep Sky work, I'm using T-Thread all the way down to the SCT Thread on the scope. The Focal reducer uses SCT Threads, but after that, it goes to T-thread. It keeps things simple for me. As for whether you need to get a focal reducer. You don't "need" one, looking at your moon shot, you should have no problems imaging M42 if you want to stay up very late, (it's just about to become a northern hemisphere object. YAY) You should to able to get a great amount of detail from that. To figure out what barlow's/reducers are worth getting I use the Astronomy Tool FoV calculator https://astronomy.tools/calculators/field_of_view/ For fun, I setup all the field of views for my gear https://astronomy.tools/calculators/field_of_view/?fov[]=312||258||1|1|0&fov[]=312||258||0.63|1|0&fov[]=312||258||2|1|0&fov[]=312||258||3|1|0&fov[]=312||258||4|1|0&fov[]=312||242||4|1|0&fov[]=312||242||3|1|0&fov[]=312||242||2|1|0&fov[]=312||242||0.63|1|0&fov[]=312||242||1|1|0&messier=42 This will give you some idea. If you want to take images of something that's larger than your largest field of view, there's nothing stopping you making a mosaic, just means taking more frames to process.

That's a lovely moon shot. To answer your question, simply put to get a larger moon image, you need to change the focal length of your scope. The longer the focal length the larger the image of the moon will appear. The other choice is to change the field of view of the camera. Essentially have the light from the scope focus on a much smaller sensor. Right now, I'm sure that you are thinking that nethier option is possible, as it means switching out the scope, or the camera. The answer to that is that you can insert an extra lens known as a focal reducer, this will shorten the focal length and make the moon appear smaller. A barlow lens, will have the opposite effect of making the moon appear bigger. Typically, you'll want a focal reducer to be able to take images of most nebula and galaxies. Andromeda is twice the size of the moon for a start! And a barlow is helpful for planets and the moon. I've got 2x, 3x and 4x barlow lenses in my collection, the 4x I find most useful for use with my planetary camera

I'll have to read that article in full as well. I've had a quick scan through some of the top of the thread, but there was not much talk about atmospheric shift. Which is what the "chasing the seeing" thing is all about. I do agree that if your mount is setup perfectly and fully calibrated then it should not need to make many guide corrections. However, making a correction is in my opinion correcting for an error that has already occurred. So with that thought, you can make as many corrections as you like as it will reduce the overall error in the image, but there will be error as a correction was needed. The real question is how much error is acceptable for you? The things that they are talking about in the simulator look to me like things that are mechanical and to do with the mount or optical train. However, the seeing isn't something that we can control hence why it's better in reality to make sure that your exposures on the guide camera are long enough to make the seeing fall into the background noise of the image, rather than a motion that needs to be corrected.

One more thing that you might want to try is extending the exposure time from 1 second to 2 seconds. My experience is that longer exposures help the with guiding as well, as having too short an exposure means that you could end up "chasing the seeing" In case you don't know, that's the wobble that happens in the atmosphere caused by air turbulance. The more wobbly that the seeing is, the more that the guider would try to correct when using short exposures (1 second is about the minimum that I'd ever attempt).

I don't know which is the more accurate of the two routines, as I've not tried the PHD version. The videos that I've watched on it make it look like a very long winded process compared to the SharpCap routine. I personally use a fast I5 laptop to run my imaging, so haven't noticed any of the slow problems that you've spoken about. All I can do here really is relate my experience of SharpCaps routine and say that I've not had any problems with it going slow, or any of the issues that you mention. The results of having aligned using SharpCap for me is that once my PHD2 guiding has settled down, I get a nice looking sign wave of corrections due to the periodic error in my mount. Before I started using SharpCaps alignment routine, I never got that sign wave shape, and I had loads of issues getting 1/2 decent images.

Are you using the same usb cable? try a different cable. Also might want to try a powered usb hub. just a few thoughts.

Hi @Rick Spencer I've got one of those cameras and have a few suggestions..... 1. Even though the chimney was a distance off, it's still close in terms of telescope focussing. It's likely that you need more travel on your focusser to achieve focus, when out of focus, you will very quickly loose the ability to see the smudges of out of focus stars.... which brings me to point 2. 2. Lengthen the exposure time make it 5 seconds to start with, and see if you get anything at all. Also you might want to combine this with my next tip. 3. Change the Gain, on the ZWO ASI290's a gain value of 110 is known as unity gain, this is supposed to be some kind of magic gain that is both sensetive and low noise. It's worth setting that in the camera settings for night time work. That lot should be enough to get you to be able to see something. Hopefully you can tweak things from there. One final thought, once you have that working, it's work running some tests with a program like sharpcap. There's another value called the offset that you'll need to adjust. To do this put a cover on the lens and take a dark frame. The minium output from the camera is a pixel value of 8, so make sure that the minium value in the image is above this, and I mean, so that when you take 1 from the offset you get 8. That way you'll be getting a true reading from your camera and will be able to use dark and flat frames effectively.

This is perfect timing for me. I'm in the process of building and AllSky camera and want to use a 3B+ for it and power it using PoE. I've got a 3B+ running a development platform at moment, but it's kinda being pushed to it's limit to make it work. I'm planning on getting a PI 4 4GB - from what I read, They've severly underestimated how popular that version is going to be, hence all the out of stock messages and swap out the 3B+ from my dev platform for a PI 4. Then I'll be able to use the 3B+ for my all sky camera

The ZWO ADC is the next piece of kit on my astronomy shopping list.

Finally, after a complete sidetrack of a project as the Meade Driver for my telescope wasn't up to the task and I've now created a new open source ASCOM driver for the Meade telescopes. Known to work with the Meade LX-90 and has had a successful test on the Meade LX200-GPS. I can now announce that I've finally got the first test version of AscomGps ready to roll. Here's the link to the blog post that has the software download link. http://cjdawson.com/2019/06/22/ascom-gps/ It's still a work in progress, but I'm happy to consider this battle station fully operational. Anyone fancy making a nice Icon for it?

Sorry, I don't see that, I only see the version that you say was cropped, but that was the whole post. Yes, the root of this topic is bayer matrix vs time needed for filter wheel. Whilst it's true that the bayer matrix is mean that not every pixel is used for every wavelength, the thing is that the capture time of the pixels will be roughly the same (I know the green will have 2 pixels so will get double, that's a whole seperate subject). One of the issues with Planets is that they rotate fast enough that the time needed to capture an LRGB dataset will mean that the planet will have moved, so that the images are actually a different part of the planet surface, rather than taken in Sync. This is the balance that I'm looking at, the filter wheel and a longer workflow to capture a stack of planet images, or a colour image and the bayer matrix. For me, ultimately, I have the choice of both options. But I'm settling on the idea of using the colour camera for short exposure planetary work, and the LRGB for the deek sky work.

Yep. That's exactly the reason why I decided to switch away from a Mono planetary camera. Whilst mono might also be best used for the moon, I've decided that if I'm going to do that, I'll use my ASI1600MM-Pro, rather than the ASI290's. My ASI290MM is going to become an allsky camera.

Hi all. I've just ordered myself a ZWO ASI290MC I've done this after lots of thoughts about capturing planets and deciding that in the end it's more important to work quickly, than to work with the extended workflow needed for LRGB. My main thought here is in creating timelapses of Jupiter so that over several hours, I can create lots of image stacks, process each to make a frame, then use those frames to create the timelapse movie. Already Owning the 290MM, I did think about using this, however, I decided against it as to capture a colour image, I'd have to capture 3 (RGB) or 4 (LRGB) sub frames per frame which would mean that I would have to capture smaller stacks and there would be much more data to process. I'm going to keep the 290mm, as I'm also thinking about making an All Sky camera.

To keep everyone updated. I've been talking to Michael directly and we've solved the teething problems with the driver. Turns out that he needed to upgrade his ASCOM platform to the latest version. I've also done a few tweaks to the driver installer and the builds so that it now works with .net 4.0, and it also checks at install time if Ascom 6.4 SP 1 or higher is installed. It's also confirmed working with Windows 7 as well as Windows 10. So I can safely assume that it'll work with Windows 8 as well. Possibly even with windows XP, but that's untested.

The V0.5.0.0 version needed .net 4.7.1. Based on your issue, I've found that I can lower the .net version two 4.0 without any ill effects on the code, so I've done that. V0.6.0.0 onwards will be using .net 4.0 until such time as I need to upgrade for a good reason. This is the same version that the ASCOM Platform 6.4SP1 which is the version against which I developed the driver.

@michael8554 I've just put up a new build, version 0.6.0.0 Downgraded the .net requirement to 4.0 or higher. I've also tested it quickly with both sharpcap and phd2, and found it working without a problem. Let me know if you get the Failed to load served COM class assembly again. That was unexpected. Here's the link. https://bitbucket.org/cjdskunkworks/meadeautostar497/downloads/Meade.net.Setup.0.6.0.0.msi

eek, I know the code is targeting .net 4.7.1. Hmmm, I wonder how low I can go, so rather than using the latest framework, I'll try using an older one and see if that makes it easier for others to use. I'll try and drop it down to .net 4.0. That should be good enough for most people. Meade Generic is the name of the new driver. So, it showing up is good.

Let me know how you get on, and if there's anything that doesn't work 100%. I'm sure that I'll be able to modify the code to better support the LX200GPS, I just need to know what the actual differences are.

I have SkySafari Pro 6 which I use on with my Meade LX-90. There are two ways that you can use this software to connect to the scope. First is using a device life the SkyFi. There's three versions, wired, wifi and bluetooth. I have the Wifi one and it works great, just plug the SkyFi into the serial port of the scope and setup SkySafari and connect. The second way is to use a program like WifiScope and connect via Ascom. This depends on the driver that you are using as to whether it can deal with the commands or not.

I know that the driver that I'm creating doesn't do this. so, with that in mind, you might want to give it a try and see if it works any better for you. You can install it alongside the other driver and chose which one you want to use, so again it's low risk for you.

That's interesting. Never saw that program before. It looks good, shame that it needs a direct connection to the com port. Which in turn means that you can only have it connected to the telescope. Whereas what I'm working on is a good quality driver that will let you run several pieces of software at the same time on the scope. I'm planning on making a handbox style application just like that, but instead of connecting directly to the scope, it'll connect via ASCOM thus meaning that it can work along side any other piece of ASCOM compliant software. I've also seen that message. The reason is that the specific driver that you are referring to is old, and doesn't really work all that well. Whilst there are a few differences in the way that the commands for for the LX-90 and the LX200, most of the commands are the same and are directly compatible. The devil is in the detail of specific implementations and there may be some defects in the handboxes which could cause the wrong command to be sent to the scope. In this case, it will simply be that the scope will ignore said command or interpret the command incorrectly. For the majority of the commands it's the same. There is a document from Meade that shows details how the commands work. https://www.meade.com/support/TelescopeProtocol_2010-10.pdf The driver that I've created uses these commands to communicate with the scope. Hence why I'm saying that there's nothing to worry about. Hope that helps to put your fears to rest.

I'm hoping that the hand box uses the same control codes as the Autostar and Audiostar. I'm planning on creating a virtual handbox application for the for the #497 based. Actually, I've already put in some of the controls for it into the driver code for 0.6.0.0. hopefully I'll get that going soon enough, and have the application ready for prime time too.

StarGPS is a firmware that is uploaded to the Autostar hand box. It is not an ASCOM driver. The Ascom Drivers allow software like SharpCap, Sequence Generator Pro, Maxim, Cartes Du Ceil, Stelarium to name a few to send commands to the scope ask it to move, and get information about where the scope is pointing. The ASCOM driver is installed on a windows PC, to allow windows to connect to the handbox. goes inside the handbox. Also I'm not charging anyone anything to install and use the driver. StarGPS isn't free. You won't be risking corrupting anything. An ASCOM driver is installed in windows, it issues commands to the Handbox via the serial cable. If something goes wrong, the command simply doesn't work. The scope will be fine. I wouldn't ask anyone to risk anything. I know how much the Meade Scopes cost, espcially the LX series.