Jump to content

548140465_Animationchallenge.jpg.32379dfa6f3bf4bba537689690df680e.jpg

rwg

Members
  • Posts

    1,059
  • Joined

  • Last visited

Posts posted by rwg

  1. Hi Neil,

    I haven't seen this particular issue before, but there have been issues with the USB2 versions of the 120MC/MM when used for long exposures and in 16 bit mode (dropped frames etc), so it kind of makes sense that the use of longer exposures would be involved in the issue. The USB 3 versions of the camera seem more stable (or at least more resistant to this sort of problem).

    As to the gain question - it depends on the imaging you are doing - for planetary/lunar where you stack 100s of frames, a high gain is good to freeze the seeing. The max gain of 100 on this camera isn't really very high compared to other cameras.

    cheers,

    Robin

    • Thanks 1
  2. Ah, that's interesting... I suspect that the underlying problem was that Windows update was trying to install updates and this was clashing with the install of the .NET framework.

    Windows Vista has a bad time with updates these days - there have been so many that the update engine can take an age to work out what it should do. I tried to bring a Windows Vista machine up to date a few months ago (from a fresh install) and left it for 48 hours and it was still trying to work out what updates to install. I gave up in the end.

    Anyway, good to hear that it worked in the end and that it was really Windows Vista that you were fighting against, not SharpCap :)

    cheers,

    Robin

  3. Ok, well check out whether the option for where to save the dark in the 'Capture Dark Frame' window was set to 'capture folder' or 'dark library' - if it was set to 'dark library' and you got no saved file in the darks folder then please send me a log if it happens again. If it was set to 'capture folder' then the dark may have been saved to your normal capture file location (but maybe the darks folder got created anyway).

    cheers,

    Robin

  4. Raw quoted throughput on USB2 is 480 megabits/s or 60 megabytes/s. As you say there are overheads to account for - normally these would stop you from getting to the rate required for 30fps, but I believe that there is a trick with using larger than normal data packets that reduces the overheads enough to get 30fps through.

    cheers,

    Robin

  5. @Stub Mandrel ToupTek cameras are only supported via the ASCOM or DirectShow drivers. There may be options inside the configuration for those that allow you to tweak the frame rate (USB speed), but I've not used those drivers so can't say for sure.

    What I do know is that ZWO have worked hard to make their cameras run as fast as possible. The downside of that is that with certain settings on some computers the cameras freeze up (turn up your Turbo USB too high on some USB chipsets...). That can obviously be an issue as to some new users it will look like a faulty camera. Other companies may take a more conservative approach of making sure the device always works, even if that means never hitting quite the same performance - maybe it allows them to get away with less after sales support that way?

    cheers,

    Robin

  6. How did you capture your darks? If you use the 'Capture Dark' button then SharpCap captures the individual frames as temporary files and then makes a single master dark from them - the individual frames get deleted. The master dark gets files in a subfolder of the 'Darks' folder - the subfolder name is based on camera, resolution, bit depth, exposure, gain and temperature - the idea being that a 'dark library' slowly builds up of darks taken with different settings and that sometimes settings will be close enough to re-use old darks.

    cheers,

    Robin

  7. Hi,

    sorry to hear that you have lost imaging data. If you have been tinkering with the filename templates then maybe you ended up taking the '{Index}' tag out of the sequence template - if you did that then every file in the sequence would get given the same name, which would lead to the outcome you experienced. The sequence template needs to have either '{Index}' or '{FrameTime}' in it to avoid this problem.

    The quickest way to get the templates back to something sensible is to untick the 'Edit Filename Templates Manually' option then make some change or other to the filename options above, which will reset the templates for you. I will look into setting up a warning in a future version if the sequence template does not have '{Index}' specified to help others avoid this issue.

    cheers,

    Robin

  8. The alignment points will probably only appear on the disk of the planet (or the edge of the disk), so the space around it will not be used. That said, a bit of space around the edge is good as it gives the guiding some room to play with - if the guiding isn't perfect you still shouldn't have the disk going out of frame.

     

    cheers,

    Robin

  9. Ah, glad someone is at least trying it out - I got so little feedback on this during the beta period (ie none) that I couldn't progress the feature in the way I would for other features.

    The theory is that you press 'Monitor' which adds markers to the image showing the features that are being tracked. Then you press 'Calibrate' which starts moving the mount to let SharpCap work out which way RA/Dec movements move the image (or Alt/Az movements for an Alt/Az mount). This can take a while and you may need to adjust the mount movement speed and initial step size to make this work nicely.  You will see some graphs of the amount of movement during calibration.

    Calibration can fail if things happen like

    * The image doesn't seem to move when the mount is moved (possibly if you have lots of backlash)

    * The image doesn't move in opposite directions for RA+ vs RA- or Dec+ vs Dec-

    * The image moves at different rates for RA+ vs RA- or Dec+ vs Dec-

    * The movement directions for RA and Dec aren't at roughly right angles to each other

    Once the calibration completes you can then press the guide button, which should keep the target roughly in the same place - note that this is not designed to keep the target absolutely stilll, but to stop it drifting slowly off center.

    cheers,

    Robin

     

  10. I just want to say thanks to @Demonperformerfor the useful feedback on SharpCap plate solving. As far as I can work out the plate solving engine used by Astrotortilla/AnSvr/ASPS etc - which SharpCap uses too - struggles to solve very high resolution images even when the star detection (sigma value) is set up correctly. Feed the engine an image at 4600x3500 and it takes several minutes to think about it and then fails to solve at the end of it all. Reduce the size of that image by 2x2 or 3x3 binning the image and it solves correctly in a few seconds. The same slower solving is observed uploading the image to astrometry.net, although the web site does solve the image in the end after several minutes.

    I have just put up a new build of SharpCap 3.1 that tries to workaround this problem by automatically asking the plate solving engine to apply binning if the image width is >2000 pixels. So far this seems to give excellent results in my testing, but I added an option to turn this behaviour off in case it causes someone problems (Settings->Plate Solving).

    I don't know for sure why the plate solving engine has difficulty with high resolutions, although I'm speculating that maybe it has some sort of internal thresold of how far out of position a star can be and still count as a match - if that threshold defaults to perhaps 1 pixel then it would be a smaller threshold for the high resolution image than for the reduced size version, which would make the plate solving harder. In particular, any optical distortion of the image might make this effect even worse if it is throwing star positions off slightly from the true position without any distortion.

    Anyway, further feedback welcome.

    cheers,

    Robin

     

    • Like 1
  11. Hi,

    it tests for the plate solving applications in the order I listed earlier and takes the first it finds. However in the log several things will have the text 'AstroTortilla' in because that was the first plate solver I supported - that text will appear even when using AnSvr or ASPS.

    cheers,

    Robin

  12. Hi,

    SharpCap is not looking for Astrotortilla.exe, but the 'solve-field' script that AstroTortilla relies on (solve-field is the solving engine, also used by astrometry.net). SharpCap will look in the following places for solve-field

    1) C:\Users\<your user name>\AppData\Local\Astrometry\bin - this is where All Sky Plate Solver installs solve-field

    2) C:\Users\<your user name>\AppData\Local\cygwin_ansvr\bin - this is where ansvr installs it

    3) AstroTortilla's location - which is found by reading from HKEY_CURRENT_USER\Software\AstroTortilla\CygwinRoot in the registry and adding 'bin' on the end. On a default install of AstroTortilla this works out to be c:\cygwin\bin

     

    If you want to enter the location manually you need to find that file (solve-field) and enter the full path to it including the name in the manual location box - ie

    C:\cygwin\bin\solve-field

    Please note that SharpCap looks for the plate solver when you open the camera, so you need to close and re-open the camera after adjusting these settings for any changes to take effect (I didn't realize that - I will fix in a future version).

    hope this helps,

    Robin

     

     

     

     

    • Like 2
    • Thanks 1
  13. If you think you are getting poor alignment with SharpCap, a useful test is to run the alignment a second time after finishing, but this time start the process in the position where the first align finished and rotate the mount back to the home position.

    If the second measurement shows you are in good alignment without needing adjustment then all is well with your polar alignment. If the second measurement is poor then the most likely cause is that your guide scope is flexing/shifting with respect to the mount as you rotate. Although SharpCap doesn't need the guide scope to be aligned with the mount accurately it does need it to stay in the same alignment during the whole procedure without moving.

    Hope this helps,

    Robin

     

    • Thanks 1
  14. 53 minutes ago, LightBucket said:

    Thanks for that, I think my small brain is getting there...

    so am I correct in thinking that if the mount is perfectly aligned with the NCP, but the scope is very slightly off that the only thing that will be out are goto’s, by the amount that the scope is off..? So the object will be off centre but it will track that object perfectly and will stay just off centre...

    Also does it mean that if my finder is not perfectly aligned with my Main scope I can still use for PA with your software..?

    Hope that makes sense :)

    Once you go through the align procedure on your handset or use the 'Sync' option on your planetarium software if you are using ASCOM it will correct for the offset from then on if your PA is accurate.

    If your PA is less than accurate then your handset/planetarium may still be able to correct for the problem if you have done a two or three star align, although having accurate PA in the first place is preferable.

    You don't need perfect alignment of the finder with the main scope or the mount axis for the SharpCap polar alignment to work - find out more here : http://www.sharpcap.co.uk/sharpcap/polar-alignment

    One thing you do need to be careful of is that if your finder moves or flexes as you rotate he mount then you will get incorrect results - people have had problems with things like pulling cables causing this.

    cheers,

    Robin

    • Thanks 1
  15. On 08/09/2017 at 15:51, LightBucket said:

    Surely that is only as good as how well your scope is aligned with the mount..?? With polemaster you are aligning the mount and not the scope...!  Depending on scope tube ring and dovetail alignment, or in the case of using a finderscope, how well that can be aligned with the mount with the fiddly 6 adjustment screws... :)

    Actually no, it doesn't matter how well aligned your scope/guider is with the mount axis (at least as long as you are not stupidly badly aligned - like 5 degrees or more off). SharpCap (and Polemaster for that matter) work by calculating the point about which the stars appear to rotate when you turn the mount in RA. That's the point in the sky that the RA axis is pointing to. It doesn't matter if the scope is pointing exactly along the RA axis or a degree or so off - the only point in the image that will appear not to move as the mount is turned is that center-of-rotation point.

    You can test this yourself - sit on a swivel chair under a light. Look up a bit so you can see the light and then spin around. You'll see that the light that on your chair's 'RA axis' stays in the same place in your vision regardless of whether you are looking straight up or not quite straight up.

    cheers,

    Robin

    • Thanks 1
  16. I would suggest avoiding the non-square pixels if you are planning on polar aligning - that will likely not work as all the star detection patterns will be stretched in a way SharpCap doesn't expect due to the pixel size.

    With the IMX224 camera, focal lengths between 50mm and 250mm should be fine in theory. I would be worried though about the amount of distortion that you might get from the sort of lens you propose which is designed as a teaching aid rather than to give a sharp focus on the very small scales of the imaging sensor. I wonder if there is a way to convert the board mount camera to take a CS/C mount lens? You can get a nice 50mm C mount lens which includes an aperture ring for not too much money, possibly even longer FL if you shop around.

    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.