Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

stargazine_ep2_banner.thumb.jpg.e37c929f88100393e885b7befec4c749.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
  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 model of all the individual blocks and the output to a scale drawing in about 1.5-2 hours per project. I did try out freecad first but found it not only more difficult to use but also limited in some of the functions when working with different file formats and i found that it crashed quite often when percfrming certain tasks. I am not sure if there is any difference in the actual program with the license you get but i just signed up for the free personal/hobbyist one and it seems like it is not limited in features. If you go to the addon site you can download and install a lot of different modules for making gears etc for free and there are also a lot of other paid addons but for general hobbyist work i think you would not need them.
  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 to process the next capture it throws the error, actual computer hardware may also cause issue if you are using a slower or older machine it may take a little longer to process the file and release the camera control. I can see at the bottom of the window that you are using 3 frames in the camera memory which looks like it is buffering to some extent possibly because your camera is higher resolution than what I am using and this would certainly explain the error you see as it would only happen when trying to capture the second “prominence” exposure.
  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 you are using the 1000 frame count then you should get 20 and 60 second video clips. I imagine running at 1000 frame count you will be eating up huge amounts of HDD space (no wonder you wanted to write to 2 separate HDD's), at my resolution that is 1.14Gb per clip for the prominence data. [DMx 41AU02.AS] Output Format=SER file (*.ser) Colour Space=MONO8 Resolution=1280x960 Frame Rate Limit=120 fps Gain=260(Auto) Exposure=0.0996(Auto) Timestamp Frames=Off Brightness=5 Banding Threshold=35 Banding Suppression=0 Apply Flat=None Subtract Dark=None #Black Point Display Black Point=0 #MidTone Point Display MidTone Point=0.5 #White Point Display White Point=1 TimeStamp=2019-10-30T16:18:28.1640653Z SharpCapVersion=3.2.6121.0 Perhaps also use SER Player to check the .ser file details, you should see something similar to this: Filename: E:\Mercury Transit 2019\2019-10-30\Surface\17_34_11.ser Filesize: 1228808178 bytes Header Details: * FileId: LUCAM-RECORDER * LuID: 4660 * ColorID: 0 (MONO) * LittleEndian: 0 * ImageWidth: 1280 * ImageHeight: 960 * PixelDepth: 8 * FrameCount: 1000 * Observer: Observer * Instrument: DMx 41AU02.AS * Telescope: telescope * DateTime: 30/10/2019 17:34:11.123999 (0x8d75d5f6011573b) * DateTime_UTC: 30/10/2019 16:34:11.123999 (0x8d75d56fe4cef3b) Timestamps: * Timestamps are all in order * Min timestamp: 30/10/2019 16:34:11.216004 UT * Max timestamp: 30/10/2019 16:37:01.349735 UT * Min to Max timestamp difference: 2 min 50.1337 s * Average frames per second: 5.87185
  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 camera the file type will be set to "auto" and ".png" i think or whatever the last output type was that you selected. The frame count setting in the script shows the number of frames that it should be capturing and when running the script you will see in the bottom of the GUI the current actions, this should show a frame count and will tell you how many frames it is capturing and when it is previewing only. What makes you think it is capturing only one frame? If it is because you are getting .jpg or .png files then it is due to the above mentioned setting.
  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 stuck in a "finishing capture" mode. It seems this can be negated by clicking "stop capture" on the GUI until you see previewing again and then stopping the script. I also made a minor edit to the code in relation to how the save location is referenced as there was a possibility it could have thrown an error depending on the filename as the path separator "\" is also an escape character in Python it seems and if followed by specific letters can give it unintended functions.
  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.Capturing : break time.sleep(0.5) #capture prominance 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 = 60 SharpCap.Settings.CaptureFolder = r'E:\Mercury Transit 2019' SharpCap.TargetName = "Prominance" #start the capture SharpCap.SelectedCamera.PrepareToCapture() SharpCap.SelectedCamera.RunCapture() while True: if not SharpCap.SelectedCamera.Capturing : break time.sleep(0.5) #wait 30 seconds before next run time.sleep(30) This assumes you have created the folders already and will throw an error message if they do not exist. Default SharpCap settings were used in relation to file naming so all files will be named as per your preferred setting put in the UI beforehand. You can use notepad to edit the file to put in your own drive locations and settings for exposure, frame count and sleep time before next run. Copy the contents of the script above and paste into the pad of the scripting tool in SharpCap, put your required settings in then save to to your hard drive, when needed from the min UI select "scripting - run script" and navigate to the saved file and the script will immediately start. From the scripting console click on the stop script button on the pad at the bottom to finish.
  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 the upper sliding part and the lower flap in which case i would use a similar timing belt/chain method combines with a small linear drive on a bracket attached to the lower flap. My hope was to keep away from being fully battery powered as i want the redundancy and i also have concerns about just how long a 12V battery would power the shutter controller along with the heaters for the electronics and motor when it gets cold. I don't mind having battery as a backup to control the shutter when out from home position such as on a weather alarm and to keep the electronics powered during an imaging session but really wonder how big of a solar panel i would need and how many Ah i would need in battery power if i did not have a mains connection.
  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 would be to use something like a Quint UPS module as the 12V battery backup that can be fed from a mains supply that would be the primary source of power (the shutter control system can take both 240V and 12V supplies) and would be fed off a main 240V UPS supplying the obs. The trouble is how i get the power up to the rotating part of the dome? What does everyone else use? Does anyone use home position contacts? What brand and what are they like? Does anyone use a slipring system? What brand and what is it like?
  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 the largest diameter my lathe chuck could handle was 138mm. There was a bit of sketchy drilling and tapping to put some threaded bar in one end and jamming a rotating center into the other end so that i could whittle it down a little and even that was a struggle as i could barely get the tool out enough for that. I did manage eventually though. The main body was bored out and a groove machined into the bast to take an o-ring seal as well as holes drilled and tapped for the bolts. A shoulder was machined all the way in where the camera would sit and bored all the way through just wide enough to take the neck of the camera. The idea was that the lens would screw in from the other side which had a stepped shoulder and would mean it would secure the camera in place without having to worry about any fancy mounting brackets or trying to thread holes inside the housing. As i decided to go with a PoE camera for simplicity i had to mount an IP68 rated fitting into the base to allow me to connect a network cable. I recessed it on the inside to allow as much space inside for the cable On the retaining collar for the dome i recessed it for the shoulder on the dome and and then used a marine grade silicone to seal the dome in place and make a watertight seal. I did consider epoxy but should i ever need to replace the dome it is much easier to remove wth a silicone based product. I then had all my parts ready for assembly The camera was put inside and secured by screwing on the lens Patch cable connected And covers all bolted on
  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. The beta version is restricted to 12 hours use before the program closes but can be immediately restarted by the user and is offered free to anyone interested in testing it out.
  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 any progress on it but at least once i am back at work i can finish my all sky camera housing. I have considered ACP but never sure it was worth the money and think i could make the system work with an integration of CCDAP and MaximDL, although i use TheSkyX for target planning as it is a really simple target list import into CCDAP. Bit of a mish mash of a build right now as i love to tinker (it keeps me entertained and out of trouble on my 2 months off work) but i enjoy putting all my own elements together. I will be using control elements from Scope Dome, with a custom built obs from Orbsey, a Davis weather station, AAG Cloudwatcher Solo, additional Firefly and Platypus controllers for peripherials, home built all sky and my own designed software all run on my home built computer system. I'm sure it will be up and running smoothly in a matter of days once i get started......... I had really hoped to put a 12" OS RiDK in there but they decided to discontinue all of their deep field instruments under 16" and have no stock materiel left for any more mirrors (i really tried to be the last one to get one built but they were adamant it was not going to happen). Not sure what i will go for now, maybe Orion ODK, Altair premium deep field or stick with a big frac like the Tak 150.
  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 a filter option which totally messed up all my network adapters as the laptop did not have a gigabit network adapter. When i did get it working however i noticed that i seemed to have a lot more options in the device properties dialog some of which i realized were of great benefit. It seems that in a driver revision the dialog for device properties has been expanded to include additional slidebars and checkbox options for brightness, contrast and gamma which are more for the live viewing of the video and do not alter raw data and present no great benefit. What had appeared however was a most helpful setting which was for a maximum auto exposure limit. Previously in auto mode the maximum exposure setting was limited by the frame rate (fps) setting but this new feature allows the user to manually bypass this yet still allow the auto exposure up to your specified limit. I had previously been wondering how to gradiate the exposure during transition between daylight and night time but this little gem sees to have solved my problem for me . This also got me thinking about another feature (there seems to be no end in sight just yet for what i am adding in) because it opened up easy possibilities for some additional auto capture and time lapse features. The main auto capture feature was designed specifically for unattended operation at night only so i decided to add in an additional feature with shorter time intervals so that the end user can now do easy time lapse of the daytime weather and the transitions from day to night as well as continuing all through the night if they wish, simply leaving the exposure in auto with the longest exposure length being dictated by the setting of the auto exposure maximum limit slider. This feature should also be great for capturing lightning storms, though it may be a while before i can see how effective that will be and will involve a lot of luck and timing: hopefully one day. I thought the weather might have been a bit better tonight but turned out really overcast in the end so there was no full night of testing worth doing but at least i have my transition working from day to night and below is a time lapse of an initial test. The daytime part is pretty smooth but as the light fades the clouds look a bit stuttery as the exposure time ramps way up and i didn't alter the frame rate in the video to compensate as it was just a quick and dirty edit. I had it set to a maximum exposure of 15 seconds on this trial run and there was a total of 1200 frames captured over a period of just under 3 1/2 hours and the video was output to 25fps.
  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

By using this site, you agree to our Terms of Use.