Jump to content

1564402927_Comet2021Banner.jpg.a8d9e102cd65f969b635e8061096d211.jpg

rwg

Members
  • Posts

    1,059
  • Joined

  • Last visited

Everything posted by rwg

  1. The meteor lens is much to wide angle (too short a focal length). Recommended focal length for a GPCAM or equivalent sensor size is 200mm (finder guider) - this gives a 1.2 degree FOV. 100m should work (~2.5 degree FOV). 50mm has a chance of working (~5 degree FOV) but is untested as far as I know. If you don't want to go down the finder-guider route, it might be worth looking into cheap 2nd hand manual focus zoom lenses for SLR cameras (say a 70-210 zoom) and an appropriate adapter to attach to a C/CS mount. I have a Pentax 70-210/4 zoom that I use for camera testing and 3d printed a GPCAM adapter for it (https://www.thingiverse.com/thing:1838091) cheers, Robin
  2. @ChrisLX200 The RGB thing turned out to be a bug with the test camera code that I use when I haven't a real camera to hand - it was getting RGB24 and RGB32 all mixed up - wouldn't happen with real cameras, so a red herring. Just tested 2.9.2965 (latest version for download from http://www.sharpcap.co.uk/sharpcap/downloads) - seems fine with the closest I can come to your camera (an Altair mono GPCAM in MONO8 mode). Made a new master dark over 10 frames and subtracting it definitely clears the hot pixels and drags the histogram right down removing the 'warm' pixels too. Dark frame with no dark subtracted Dark frame with dark subtracted Might be worth having a look at the master darks that are being saved and comparing them with a single dark frame to see if anything jumps out as wrong - you could send me one of each (single dark frame, master dark) if you wanted. cheers, Robin
  3. @ChrisLX200 Looks like an issue with RGB colour space I think (probably RGB24 *and* RGB32). Seems ok in RAW and Mono. Looking into the reason now. @cfpendock I haven't deliberately made version 2.9 not support Win XP, but I don't test it either. I wonder if it is something to do with the installer which also installs a pre-requisite for supporting Celestron cameras. One thing you can try if you want is to clear out your temp folder, then run the installer until the error appears. If you then go have a fish around in your temp folder you will probably find the actual SharpCap install .msi file somewhere in the temp folder or a sub folder - if you can find that, try running it and maybe you will get a good install. cheers, Robin
  4. Hi Sara, right now the answer on the time in the filename is no, but I have to look into a couple more issues with file naming, so I will see what I can do. The best you can do right now is look at the file properties to see what it's timestamp is (right click, choose properties in Windows Explorer). I must admit that I rarely stay up until midnight (odd for an astronomer maybe, but not so much when you have to get up at 6am), so I'd never noticed the midnight issue... Not sure how easy that would be, but will have a think... cheers, Robin
  5. If you have the same exposure time, then check out the gain - roughly equivalent to varying the ISO on a DSLR. If you have been capturing at ISO100 then set a minimum gain, ISO800 set a mid range gain and ISO3200 set a high gain. I still wonder if you are only seeing the brightest inner part of the pattern for some reason? cheers, Robin
  6. Sadly the amp glow doesn't respond much to cooling on these sensors Robin
  7. Now that's interesting... QHY have had an amp glow control option on their Sony CMOS sensor models for a while now and it is definitely effective (In SharpCap you can turn it off manually and see the difference it makes). As someone pointed out the 174 is bad for this, the 178 has much less of a problem. Anyway, maybe ZWO have also worked out what QHY have done to reduce the amp glow? cheers, Robin
  8. Peter, definitely make sure that you are using similar exposure lengths if you want to compare like-for-like with another camera - for instance if you were using a longer exposure (say 1s) with the DLSR then with the short exposure on the ASI290 you will be seeing a much dimmer version of the pattern and picking up on all the fluctuations in seeing that the longer exposure is hiding from you. cheers, Robin
  9. Yep, I've never had success using a Bahtinov on the planet itself - you need to use it on a nearby bright star. The other problem is that at longer focal lengths the pattern can be smaller and less distinct, so it may not be as easy to use as it is for shorter focal length deep sky work. cheers, Robin
  10. I have been trying to work out what the problem is with adjusting before moving on (both in practice and theoretically), and I think I have finally worked it out... If you start adjusting before you move on to the last phase then you notice that as you adjust, the position marked in the frame for the RA axis starts to move. This is wrong... The position of the RA axis within the frame is determined only by the alignment of the scope and camera you are using to the mount RA axis. Moving where the RA axis points in the sky should have no effect on the position of the RA axis within the frame. So, basically, by adjusting before the final stage you are confusing SharpCap's calculation of where the RA axis currently is, which in turn throws the alignment off. cheers, Robin
  11. No, the field of view is going to be too wide with that lens. You might be able to find a 40-50mm CS lens on ebay that would might get you (just) to a small enough field of view. The 2.1mm meteor lens is just too wide angle. cheers, Robin
  12. It will be at maximum aperture - lenses only stop down to the desired aperture during exposures, the rest of the time (while the camera is idle or off) they are at maximum aperture. cheers, Robin
  13. @Demonperformer Sorry, no control over the aperture of a camera lens - that requires either a manual lever being moved by the camera body or an electrical supply to the lens via the comms pins and correctly coded signals (depending on lens design). The hardware of the ASI1600->Canon converter doesn't support either of these (the electrical contacts are just dummy). cheers, Robin
  14. Don, so I have been back and re-checked and there are only 2 changes to the polar alignment between 2936 and 2953 1) The new message telling you to press the Next button and no arrow until you do 2) Duplicate frames are ignored - that is if the camera sends identical frames twice or more in a row, SharpCap will only calculate for the first one to avoid using all CPU time on some cameras. Change 2 should only really apply to LX modified webcams - even with integrating cameras and frame grabbers, sequential frames will be different due to noise in the A->D conversion, so that leaves 1) as the only possible cause of any change in behaviour. I'm going to try to put out a test version later for another user who has a different bug - I will send the link to you as well and re-enable the alignment adjustment in stage 2, so you will be able to test the 2 ways in the same version to see if they really do make a difference. cheers, Robin
  15. @deepview I'm pretty sure that the field of view with a 102/f5 refractor and a webcam is going to be too small. There's a field of view calculator in the tools section of this site I think and you could put your focal length and sensor size in to work out what FOV you will get. For that focal length you will need a larger sensor, or to use the webcam then you will need a shorter FL. Hope that you get cold soon and get a chance to test @DonBoy The way the process is designed I hadn't envisaged the adjustments being made until you'd gone to the last step by pressing next. I wasn't at all convinced that the right alignment would be achieved by adjusting during stage 2 and I'd had some reports of alignment issues from people who were doing it that way. That's why I have forced the 'press next' in the latest 2.9. But... I just tested this morning (I have a printout of the polar sky and point a camera with a 4mm lens at it - works a treat) and actually adjusting in stage 2 does seem to work. *BUT* it only works if the plate solver continues to work on each frame as you adjust, since the target point tends to move away from the moving star a bit if you adjust in stage 2. If you adjust in stage 3 then the target point doesn't move, so you get correct alignment even if the plate solving doesn't solve every frame. I think the upshot is that I will keep the warning to move on before adjusting as that is the most robust way of working, but I will put the arrow back in stage 2 for those who prefer to work that way. cheers, Robin
  16. @Horwig glad to hear it is working for you. The early versions (2.8) had some problems with large fields of view and too many stars as well as with too few stars. That's fixed in 2.9, so you will only get problems if the FOV is too small and there are not enough stars that SharpCap recognises in the field of view. cheers, Robin
  17. Looks like you have been capturing in RAW mode, which then needs debayering to give you a colour image. PIPP is a good tool for this - on the "Input Options" page check the 'Debayer Monochrome Frames' option and then play around with the settings below to get the right pattern option. An even better option may be to capture a video into SER format, since SharpCap puts the bayer pattern information into the SER file, so when you play it back in SER Player, Registax, AS!2 etc, the debayer should happen automatically. cheers, Robin
  18. Either way will work fine - take your pick. cheers, Robin
  19. @JemC, no, that's it - once you have the star in the box and the green and red crosses lined up you are done. If you look at the bottom of the screen you can see that your remaining polar error is estimated to be 6 *seconds* of arc... Normally anything less than 2 minutes is considered good and anything less than one minute is excellent. I guess the reason that there is no 'you're done' stage is that everyone has their own idea of how close is close enough. cheers, Robin
  20. @DavM Either way is fine - you can use the handset/EQMOD to program a 90 degree turn in RA or just loosen the clutch and spin the axis. Robin
  21. Yeah, 1 minute is where it starts to make a big difference, 30s or less is marginal, 15s or less is probably not worth it. Have you found a wide angle lens that will illuminate the whole sensor - that must be more of a challenge with the bigger sensor on the 178... cheers, Robin
  22. Hi Gina, what length exposures are you planning? Unless you are pushing up beyond 1 minute I'm not sure that cooling will gain you much with the 178 sensor. This is the dark frame histogram of my QHY178C at 50% gain level, 30s exposure, room temperature There are some pixels up through all the different values (see the plot below with logarithmic vertical scale), but not really a significant number out of a 6 megapixel sensor. Also this would be lower at outside temperatures. The Sony sensors (178, 224, 174, etc) do have an amp-glow like issue which *is not* helped by cooling. QHY have a tweak for this that I haven't seen from any other manufacturer. They won't say exactly what it is they are doing, but in my experience it does seem to be effective. cheers, Robin
  23. This is a good question and one I don't yet fully understand. The plate solving to find the position of the pole is accurate - just tested with a star field from Stellarium with the equatorial grid still in place and you can see how well it does - SharpCap ignores the blue equatorial grid from stellarium easily and puts its own NCP (green) spot on in the right place. If you test when you have finished polar aligning in SharpCap by turning the mount on the RA axis, you should see the stars in view rotate around the point marked as NCP - this confirms that you are correctly polar aligned as the center of rotation is matching the NCP. So... what does that leave? The only thing I can think of is physical flexing of the tripod/mount/pier as the load moves from the 'home' position with scope up and weights down to whatever position you run a drift align from. To be honest, I'd have thought that this shouldn't happen if you are have properly balanced the mount payload, but I'm not 100% sure. If this is the problem then you'd expect to see less change with a lighter load on the mount. Any further thoughts on this welcome! cheers, Robin
  24. The peltier gets very hot on the hot side and the sensor kicks heat. As soon as the peltier gets turned off the combination of the heat leaking back through from the hot side of the peltier and the generated heat warm things up pretty quickly. I think you might see the same if you were to shut down SharpCap and then re-open it again to see the temperature. cheers, Robin
  25. SharpCap actually doesn't do anything smart with the cooler power - that's all down to the camera driver. SharpCap just tells it the target temperature and the driver gets on with it. I believe that the driver uses a PID algorithm (https://en.wikipedia.org/wiki/PID_controller ) to set the power percentage and ensure that the final temperature is stable. The soft start may just be a byproduct of this algorithm. cheers, Robin
×
×
  • 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.