Jump to content

sgl_imaging_challenge_2021_annual.thumb.jpg.3fc34f695a81b16210333189a3162ac7.jpg

purgitoria

Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

16 Good

About purgitoria

  • Rank
    Nebula

Contact Methods

  • Website URL
    http://www.spfindlay-astronomy.com

Profile Information

  • Gender
    Male
  • Interests
    Astrophotography
    Skydiving
    Scuba Diving
    Snow Boarding
  • Location
    Scottish Borders

Recent Profile Visitors

869 profile views
  1. Those are some great images Glad you liked the script and it worked out well for you and cant wait to see the final full animation, i am sure the processing and stitching is rather tedious but will be worth the effort when you are done. Wish i had been at home with the scope myself instead of working overseas, the last transit i managed to see was a short glimpse of the Venus transit back in 2012 in the only 1 minute gap in the cloud all day just before the sun dipped behind the mountains.
  2. I would recommend Fusion 360 as well. I have recently started using it as i am doing a huge renovation job on a property i just bought and although i am not doing 3D printing(there are great addons for that) it was still great when it came to designing 3D models and creating production drawings of stonework that i wanted made by the masons and used it to model 3 fireplaces (jambs, lintels, mantles, and ashlars) as well as 3 chimneys that i am having rebuilt in sandstone instead of the ugly red brick that is currently there. I actually found it quite intuitive to use and and could knock up a 3D
  3. I am just curious on your setting of the exposure. I see you using .02 and wondered if that was intentional and if you were aware that exposure time in script is already quoted in milliseconds si there is no need to put a decimal value here. You could also be right in the sleep time as this script was tested with another camera brand and it could be that the ZWO takes longer to download the frames or may use some kind of buffer onboard the camera so until the buffer is cleared the camera is still busy dealing with the first capture and due to the script requiring the camera to not be capturing
  4. I have run the script several times capturing in both .avi and .ser and used the SER player V1.7.2 to play back the .ser files and VLC player the .avi files and both work just fine on my computer. My setup has a DMK41AU02.AS camera on the desk as this is what i use for developing and testing of my own all sky camera software. The following is the output from the automatically generated settings file that SharpCap spits out with every video clip. I am getting clips 2 seconds and 6 seconds long with my test sequence (i am using 100 as a frame count to save time and drive space while testing), if
  5. I have fully tested the script and can get it to output in any format and have samples in both .avi and .ser. When using this script the output is not explicitly set within the script as there is no need to do so and it makes it more versatile for anyone else who wants to use it for outputting to their own preferred format. You must ensure that in the GUI you explicitly set the file type before running the script in the "Capture Format and Area" section of the menu for the camera, just uncheck the auto button and select your preferred output from the drop down menu, by defaut when opening a ca
  6. It is actually not that much code as a lot of the settings come from within the GUI already such as gain, output format etc. It is really only the settings that will be changing or that cannot be set from the GUI that need to be added along with the time delay. I have noticed however that for some reason there is a bug that does not always allow the script to be stopped from the console if you select "run script" so it may be better to open it in the pad and then run it so you should always have the option to stop the running script but even then there is some bug that can leave SharpCap
  7. import time while True: #capture surface detail import clr clr.AddReference("SharpCap") from SharpCap.UI import CaptureLimitType SharpCap.SelectedCamera.CaptureConfig.CaptureLimitType = CaptureLimitType.FrameLimited SharpCap.SelectedCamera.CaptureConfig.CaptureLimitCount =1000 SharpCap.SelectedCamera.Controls.Exposure.Value = 20 SharpCap.Settings.CaptureFolder = r'E:\Mercury Transit 2019' SharpCap.TargetName = "Surface" #start the capture SharpCap.SelectedCamera.PrepareToCapture() SharpCap.SelectedCamera.RunCapture() while True: if not SharpCap.SelectedCamera.Captur
  8. My concern i not so much the powering of the motor as i know a battery will be more than capable of holding the charge to operate the shutter for a couple of cycles. I am more concerned about the powering of the electronics for long periods with the constant wireless broadcasting and also for all the heaters for the electronics and the motor, heaters always use quite a bit of power and it gets pretty cold in Scotland over the winter.
  9. My intention is to use a timing belt and pulley wheel system such as the open ended belts here http://www.davall.co.uk/dsg-power-transmission/catalogue/toothed-belts/ Effectively wheel would be fixed at the top of the dome and the other would be on the drive motor at the bottom with one of the clamping plates attached to a bracket on the shutter and a series of guide rollers to align and tension the belt (this is much the same way as the Rigel system works with it's chain drive). The only problem i would see is if it were one of the older pulsar domes that had the dual shutter consisting of th
  10. So, i'm currently working on my new observatory design and am basing it on a Pulsar 2.7m. It will not use however the Rigel automation system but a version of the ScopeDome automation. I will also not be using the rubber support and guide rollers but am having a custom curvilinear rail system made to support the dome as i wish to make the dome fully robotic and unattended (i work overseas a lot and it would be great to be able to use it securely when not at home). This presents me with several issues when it comes to redundancy and reliability for powering the shutter. My optimal solution woul
  11. So i promised to update on the physical build of my camera and now i am back at work i managed to complete the machining and have the finished product ready for some weather testing. First of all it was machining down the big block of delrin i had into ll the individual parts i needed.These consisted of the main body, a base cover and a retaining ring for the dome. Not the worlds largest or best lathe but it did the job. The hardest part was getting the block down to a manageable diameter as i had ordered a 135mm diameter block but what i received was a 170mm diameter block and th
  12. I now have a website associated with my software for anyone that is interested. http://sky-cam-astro.uk There is an up to date overview of the software on there as well as a few images of the current layout. If anyone is interested in trying out the software, especially anyone with a colour camera as i do not currently own one to test it on myself, then please get in touch via my website and i will send a link and download instructions for a beta version. The help file needs some updating as i have made quite a few changes in the past week and the latest help file will be in my next revision.
  13. Great thread on the robotic obs there Steve, i'm going down the same route myself and at present am only being held back by my observatory builder who is several weeks behind schedule. I work overseas for 6 months of the year and normally when the imaging conditions are at their best so always find it frustrating, in the past year i have done virtually nothing and am starting to forget how to process images properly. Now i will be heading back to work for a couple of months overseas again with my obs due to arrive a week or 2 after i have left so now it will be November before i really make an
  14. Well i guess it is my own fault for not checking my drivers, lesson learned but not that it is a disadvantage for me with the effect it has had. I was having issues getting the software running on a different computer and never noticed that the driver i had installed was a much more up to date one than what i had installed on the computer i was using to develop my software. Not that it was my software causing the issue but actually an option during the driver install as it was an older laptop i was trying to test out the software on and as i am using a GigE camera i should not have installed
  15. I'm just waiting to get back to work myself so i can get back on the lathe and finish off my camera housing i started a while back but got stuck while waiting on the dome and imaging sensor to get delivered 2 months late.
×
×
  • 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.