Jump to content



  • Posts

  • Joined

  • Last visited

Everything posted by OzDave

  1. I've been using an IS DMK31 firewire guide camera for quite a while now. Meanwhile the computing industry has moved on and firewire is getting more and more difficult to support. It's time for me to switch to a USB guide camera so I had a look around at came up with two potential candidates: ZWO ASI120MM QHY5L-II These cameras are not too expensive, yet appear to have pretty decent performance. I believe they are based on the same sensor, so there is little to choose between them. I saw another thread on this forum comparing the two cameras, with the ASI coming out on top. I'm interested in using the camera on MacOS with PHD2. I note that the ASI is directly supported, and I wondered if that would mean the QHY would also work since they are based on the same sensor. Has anyone tried this to confirm whether the QHY would also work with PHD2 on MacOS? I'm also considering moving my imaging setup to a Linux-based small computer, such as a Raspberry Pi or ODROID C2. Therefore, linux-compatility would also be desirable. The QHY appears to have a Linux SDK, but I did not find anything for the ASI in a quick search. So I guess I'd like to hear from those of you who own either of these cameras and are using them on MacOS or Linux. If you dabble in software development, then I'd also like to hear about your experiences with these cameras and what software you use with them. Happy New Year! David
  2. Great, glad that you got it working. You will find that the slews will be off target until you perform a Star Alignment (with EQMac, not the handset). Just like if you use the handset by itself. As for why it stopped short of your target that time, I guess that's maybe a bug of some sort somewhere. If it repeats itself, let me know and I can try to track it down some time. To do a star alignment, you slew to a star, centre it accurately in your eyepiece, then you tell EQMac to Sync. There is a Star Alignment window in EQMac that will show you all the stars you have synced so far. It is important to execute the Sync from the same place that you issued the Slew. So if you slewed using Sky Safari, you should also use Sky Safari to send the Sync command. On the other hand, if you used the built-in mini-map in EQMac to slew, there is a Sync button there you can use once you are centered. I tend to use this latter method myself and I generally Sync one star near my intended target since I only really do astrophotography and not visual stuff. You can however, Sync multiple stars all over the sky and EQMac will use those to move accurately to your slew targets. Or at least that is the theory.... I'll be interested to hear if that works for you. Regards, David
  3. Yes, LX200 Classic should be fine. The type of mount should still be set to German Equatorial though. Basically what we are doing is this: EQMac controls the actual mount directly via the shoestring cable using the native Skywatcher serial protocol. EQMac presents an LX200 protocol emulation layer via the TCP/WIFI interface so that other software (such as Sky Safari) can connect and learn positioning or exert control. It listens on TCP port 4030 for incoming connections. As an aside, this is totally separate from the Stellarium support, which uses a different set of ports. However, I don't recommend anyone use the Stellarium integration, as frankly it's a bit rubbish. The Stellarium protocol just isn't very good, unlike the actual Stellarium product itself which is pretty nice. I prefer Sky Safari myself though. So....by telling Sky Safari to connect to port 4030, and that it has to control a German EQ LX200, Sky Safari will send LX200 protocol commands via the network to EQMac. EQMac will receive those in its emulation layer, and translate them into native commands. If you go down the route of telling Sky Safari that its an Alt-Az mount, it's going to get horribly confused because positioning an Alt-Az mount is mathematically different than positioning an EQ mount. Not to mention that EQMac will be expecting Equatorial coordinates for positioning. Anyway, I hope that clarifies what this setup is doing and why it should work. Looking forward to hearing your results. David
  4. Looks like I'm somewhat late to this party. Hope I can help. Reading history I think you've been trying things the wrong way round. There is a path you can take to get this to work though. First put Eqmac in serial port port and have it connect to the mount. Make sure this works. I think you had this working ok. This is how Eqmac was intended to operate. Next you need to configure sky safari to connect to Eqmac via tcp/wifi. Tell sky safari it is an LX200 mount. Use IP and port 4030. Sky safari should connect and if you configure the other telescope settings, should display the mount location and track it. Furthermore you should be able to control things through sky safari and point and click on stars to slew to them. Give this setup a shot and let me know how you go. This setup works for me and I think maybe is described in the Eqmac site in documentation. Been a while since I looked though so I could be mistaken. Regards David
  5. Over the past few years I've not been able to make much progress on EQMac for various reasons and it seems a shame to see the project stagnate when a fair few people seem to find it useful for their astronomy needs. Therefore, I am considering releasing the code as open source in a similar way as was done with PHD Guiding. I have not officially decided to do this yet, but I thought I would post here and see if there are any people who think this is a good idea and would actually be willing to contribute to the project. Of course, if I did make it open source, people could do what they liked, but I would hope that people would want to contribute code back to the project and that I would continue to administer new releases and so forth. The problem I have is really the amount of time I can spend writing and testing code. Therefore, maybe it is time to let others help and move to a more administrative role. What do people think? FYI - it's currently an Objective-C project although I am thinking of moving it to Swift sometime. Regards, David
  6. This is a quick note to say that I've posted a new version of EQMac on the site for download. There are more details on the site, but the main feature is now the ability to connect via WiFi if you happen to have a device such as a Nexus-S or similar. Of course, wired serial connections are still possible and a new Simulator mode is available too. It is a beta release because there are likely still some bugs, but it seems to work well enough for general use now. Please let me know if you try it and have success and especially if something goes wrong. The best way to get me is via the Contact Form on the EQMac website.
  7. Here's a quick and dirty go at M33 in LRGB. It is using 30 min subs with 12xL, 3xR, 3xG, 4xB. So total integration time of 11 hours. I don't have a lot of experience processing galaxies, so I feel this hasn't come out quite as I'd hoped. I was hoping to get it looking more spirally and more blue, but then I don't have a massive amount of RGB data. Maybe that's part of the problem. Also, processing techniques for this don't seem to have worked the same as for Nebulae. Anyway, it's not a terrible result, so perhaps I'll try this again when the target is a bit more favourably placed. As it is, a fair few Luminence frames were shot at relatively low altitude since the object was only transiting the meridian just before sunrise. Hope you like it nevertheless....
  8. I suppose it could be a gradient, but I did do Dynamic Background Removal in PixInsight, so it ought not to be. I was trying to convince myself that it was simply how the California Nebula (or part thereof) looked. It is difficult to do DBE on this image because actually most of it is nebula and there is not a whole lot of background to use as reference. I actually need to reprocess this anyway since the OIII and SII have only been calibrated with 3 darks (couldn't wait to get more). But now I have the full compliment of 15 darks done I should really go back and recalibrate. I can look for a gradient then.
  9. About a month ago I captured some Ha frames of the Pelican nebula but didn't manage to get any OIII or SII due to the moon phase and other factors. Finally this month I managed to get the remaining narrowband frames and I've worked this up into an LRGB composite. HA is the L channel, while RGB is composed from a blend of SII and Ha (Red), a blend of OIII and Ha (green), and OIII (blue). There are 11 Ha frames of 20 mins and 7 frames of 30 mins for OIII and SII. Just under 11 hours total integration time. Processed in PixInsight. Full scale image is on Astrobin (here).
  10. Thanks. Yeah, clouds would be a problem. Fortunately, from where I'm based, at this time of year I can pretty much expect clear skies right the way through July/August. I just have to hope there is no wind. Oh, and of course the pesky Moon. If I could just extinguish that for a couple of months...
  11. Here is a bit of a WIP image. It is 11x20m in Ha of the Pelican nebula. I hope to turn this into separate narrowband and HaRGB images later. Processed with PixInsight. Will redo the processing once I acquire all the other channel data. There's probably more I can do with some of the more contrasty areas at the "neck" of the pelican, but I've just given this a fairly quick process for now. For those interested, I used the following PixInsight tools: Calibration/StackingDynamic Background ExtractionTGVDenoiseHistogram TransformationACDNR with maskHDR Multiscale transformLocal Histogram EnhancementHope you like it.
  12. Hmmm, ok. I'm doing 20 minutes subs tonight in Ha. I'll try to get the Sii tomorrow night. Then I guess wait till later in the month for the Oiii. Presumably 20 minutes will be ok for Sii and Oiii ? The Ha is looking pretty nice at 20mins, but then that is obviously the predominant emission. But... if I have to wait till later for the Moon to be away anyway, should I be thinking about an RGB shoot? Still can't make up my mind on this. Maybe I'll have to get both sets of data when the Moon allows.
  13. I'm capturing a few hours worth of Ha data on the Pelican nebula tonight. This will either serve as luminance for an LRGB shoot, or will be the Ha channel in narrowband. Wondering which way to go with this. I've googled and found many different versions of this target in both RGB and narrowband. I suspect though, given the moon situation for the next few nights, that this one might be a narrowband project, though I will have opportunity later in the month to get RGB when the moon is away. What do people think though? Is this target best is narrowband or LRGB? David
  14. Are you guys sure that Mavericks is not playing havoc with the timing of things? It ruined all my astro apps doing any form of real time delays until I switched off app nap for each app. Given Nick appears not to run Mavericks yet, he probably hasn't seen the massive issues app nap can cause. And it seems the problems are related to timing in some way. So I'd try disabling app nap for the test app and repeat the tests you were doing. Nick, if app nap is the cause then you'll need to do some changes to the way timers are used in the code. I've been recoding EQMac to deal with this so have some experience if you need advice. David Sent from my iPhone using Tapatalk
  15. Yes I think I agree with Chris. To get more detail you need longer subs. I did 30 minute subs on this target in Ha last year and got some pretty amazing depth. I think I posted the result on here if you want to have a look. If you can't find it give me a shout. Sent from my iPhone using Tapatalk
  16. Does anyone happen to know how to forecast things such as cloud cover and seeing and transparency given a set of weather sensor measurements for a given area? I am wondering because I've built my own weather station, but I'd like to hook it up to something that would do the above predictions for 48 hours or even less. I've seen websites that do this, but I've no idea how they work. Does anyone know? Sent from my iPhone using Tapatalk
  17. I just gave this a shot and managed to remove all the play in the RA axis. I'm yet to put the motor back, and haven't tightened the worm carrier down yet, but the worm screw turns easily in my fingers with no play. Excellent! Now to get it all tight and run the motors to test! Thanks for this tip! I had seen a website which advised securing the worm screw before adjusting the worm spacing, because if you don't, there would be two variables at work making things difficult. However, Astro Baby recommends the opposite. Adjusting the worm retainer nut after the worm spacing is done. Moral of the story: Do not fully tighten the worm retainer nut before adjusting the worm carrier. Otherwise you'll probably end up with play in the axis.
  18. I have recently been having some odd problems with my astronomy software since upgrading to Mavericks. My capture software suddenly started throwing the camera into a fatal error mode, PHD was guiding very oddly to name a few things. I tracked it down today to be caused by the App Nap feature of Mavericks. What this does is change the behaviour of timers slowing the app down when it is not the foreground application. Since there is only one foregound app, it means all of the real time astronomy apps that you may have running during an imaging session may behave badly. Unless apps are appnap aware, we need to disable it. You can do this by rightclicking the app, choosing Get Info, and then checking the Prevent App Nap option. If you dont do this you can expect erroneous captures, pulse guiding that is way off, and other such problems. Hope this helps people on Macs. David Sent from my iPhone using Tapatalk
  19. I think the bolt I stripped might be "saveable" with a nut and washer inside the chassis as you suggest. Following my RA strip down I took the mount out to test the guiding performance. I found DEC was significantly improved but I was getting random stalls in RA although RA guiding was generally good except for regular periods where the graph would just go totally nuts with displacements of 5 pixels of so. Eventually this would correct and things would be normal again for a while. I attributed yhis to having the RA worm tweaked too tighly, so I've backed it off a bit but have yet to retest. Oddly I seem to have zero play in the DEC axis now, but maybe half millimetre or so of play on RA. Try as I might, I cant seem to get RA any better and having to back off the grub screws in RA has made things marginally worse. Have others also found things go like this? David Sent from my iPhone using Tapatalk
  20. Since Christmas/New Year was rained/clouded out here, I decided, after inspecting my mount, that it didn't rotate very easily and so a service might be in order. So I followed Astro Baby's EQ6 strip down and rebuild guide for the DEC axis. I got everything stripped down, cleaned and re-greased, and reassembled without issues. However, the final part is adjusting the worm carrier. I had done this and eliminated all play in the DEC axis and proceeded to start tightening the DEC worm carrier cap head bolts. I got 3 of them tight but not as tight as they were to undo originally. However, the 4th bolt managed to strip the female thread with almost no force at all. It didn't even get anywhere near tight, just kept turning in the hole. I took it back out and found a neat spiral of metal wrapped around the bolt. I have to conclude from this that the thread was basically ruined before I started messing about and undoing and replacing the bolt was just the final thing it needed to fail. Looking down on the DEC axis saddle, with the cap head bolts below the saddle, the bolt in question is the 3rd one counting left to right. All the others are secure enough without being overnight I believe. Should I be worried about this 3rd bolt not being tight? The DEC axis seems perfectly functional with no play, so it seems not to matter too much. However, I would like to hear what people think. Also, supposing that I want to fix it, what are my options? Can it even be fixed in some way? Presumably I'd have to replace the 3rd bolt with another one slightly larger in diameter and have a new thread cut to suit. I'm not sure what else would be required in terms of enlarging other holes. No idea how to cut the new thread either. Advice please.... Oh...and happy new year! David
  21. Patents are only of use to make lawyers richer. They do nothing to protect an individual with an invention. If you hold a patent, nothing stops large companies from copying your invention, and when they do you need a war chest of money to defend yourself. I'd spend the money for the patent on a fantastic piece of astronomy kit. Actually you could probably get several pretty fantastic bits of kit. Sent from my iPhone using Tapatalk
  22. Personally I'd slew with the keypad otherwise you'll have to reset the home position and restart synscan so it knows you are synced at home. If that isn't a big deal, just declutch and move. Sent from my iPhone using Tapatalk - now Free
  23. It's not massively important to update the firmware, but if you really want to then these are the sorts of issues that occur. I've seen that error a lot but not sure what causes it. But make sure the usb adapter drivers are providing you with a new COM port. And make sure you select that port in the upgrade tool and have it detect. I found that if you detect, then upgrade it might work...if you're lucky... Sent from my iPad using Tapatalk - now Free
  24. Google is your friend. Some tutorials are better than others. Find several, pick one that makes the most sense to you. Some of them even explain the theory in simple terms for why drift alignment works the way it does. Sent from my iPad using Tapatalk - now Free
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.