Recently Browsing 0 members
No registered users viewing this page.
I'm addressing this problem with our Scopedome shutter since December 2020. The problem occurs every once in a while either during opening or closing the shutter especially approaching the full-close position wherein it creates a loud "bang" noise.
After inspecting the dome, I just found out that the gear is now not touching exactly the latch hole of the shutter. Herewith attached below are the images showing the problem.
Any tips/suggestions on how to resolve this issue, particularly on the aligning them, what to use etc., if needs replacement?
Excuse me if there are incorrect terms. I'm not that familiar with dome components.
Thank you very much. Clear skies.
As I have got older I am increasingly disinclined to stand in the cold for hours trying to obtain passable astro-photos. I am still however, willing to sit in the warm and spend hours trying to obtain passable astro-photos. I have over the past decade set up an observatory in my back garden using mostly second hand equipment. I now have a Celestron C8 with Fastar that I bought second hand in 1999, a WO Zenithstar 66mm Apo that I purchased new in the US some ten years ago and a TS6 achromatic refractor that I purchased second hand last year. The Zenithstar is piggybacked on the C8 and is used with a second hand Starlight Xpress SXV-M7 for guiding with PHD2. I have an original QHY8, again purchased second hand, that I use with the TS6 or the Fastar and Nebulosity. The mount is a second hand Losmandy G11 with a late Gemini I system attached that I purchased from California some 15 years ago . The observatory is from Alexander Observatories.
My aim is to be able to control the mount and equipment from my study in the house. As I work away, it would also be nice to be able to have the capacity for truly remote operation, but one step at a time. It seemed to me that the minumum requirements for remote operation from the comfort of the house were (a) the ability to reliably control the mount and cameras using a remote computer, (b) the ability to reliably see the equipment in the observatory whilst using it remotely and (c) the ability, ultimately, to remotely control the observatory roof, which control would have to have built in safety features to prevent weather and impact damage to the equipment.
For remote control of the mount and equipment, I decided to use Windows 10 Pro Remote Desktop to communicate between a computer in the observatory and a computer in my study. Whilst I was attracted to a Windows based system that could be piggybacked on the scopes, I was not willing to pay the high price of bespoke systems like the Primaluce Eagle 3. The solution I arrived at was a HNSUN industrial mini-computer purchased from Amazon for £290. It has a 128G solid state drive, 8G of RAM and has Windows 10 Pro pre-installed. It is also small enough to mount on the TS6 notwithstanding that it has four serial ports, four USB3 ports and four USB2 ports, as well as two LAN ports. Its only drawback is that it does not have the power ports for astro-equipment that solutions like the Eagle 3 Pro give. But it is over £1000 cheaper! Using a wooden backboard, I mounted the mini-PC on top of the TS6's scope rings. On the mini-pc is installed the software for controlling the mount and the cameras via ASCOM and Gemini.net scripts.
At present, the computer in my study and the mini-pc on the scope communicate wirelessly over our household broadband, which reaches the observatory by virtue of a wi-fi range extender. Remote Desktop replicates the mini-pc's desktop on the computer in my study, allowing me to control the mount and the cameras. I hope shortly to introduce digital focusing. It is becoming clear however, that this wireless link is not the most reliable. In particular, when others are using up bandwidth the link drops out relatively regularly. As such, I have decided to install a hardwire LAN link between the two computers by running a Cat 7 LAN cable from my study to the observatory. This will involve drilling a hole through the outside wall and running the cable out from the house to the observatory.
To view the equipment as it being used, I have installed a Reolink wireless CCTV camera in the observatory, which can be viewed wirelessly on the computer in the study. This allows me to keep an eye on things and to make sure the mount is doing what the programmes on the remote desktop are telling me it is doing. It will also in due course permit me to check that the scopes are parked before the roof shuts and that the roof has closed at the end of the session. The wireless link to the CCTV camera seems to be a lot more stable than that to the mini-pc, perhaps due to using less bandwidth.
As to the roof, I am now investigating options for automating the roof. I think the Talon systems looks to be the gold standard but, again, the price for such a bespoke unit is commensurate with its specialist / dedicated nature. Any cheaper ideas would be very gratefully received.
The challenge now is to point the scope, centre the target and take the pictures without leaving the house. Wish me luck!
After automating the dome on my Pulsar Obsy which has been a revelation, I have spent a considerable time researching how I could automate on what is a very basic manual shutter. The existing shutter slides on the aperture side of the dome and supported by two curved aluminium rods at the rear. What I will require is to create a runner system to allow the shutter to open & close smoothly, be aligned & contained to enable attaching a motor and drive system, thus allowing software automation.
The rollers are 30 mm dia nylon roller bearings, four per side of the shutter opening. This will allow the shutter to slide smoothly over the open aperture.
The rear side of the dome needed to be built up so I could affix tracks to enable the shutter to slide smoothly to the rear of the dome. This was relatively tricky as I had to build rear track support blocks to line up with the existing shutter. I plumped for wooden supports as I had to mount the on a sloping curved dome and as they had to be mounted vertically, creating some rather complex compound angles and curves. These were bonded in place and further secured with stainless screws from within the dome. Then having formed the arc in which the shutter will run I attached UPVC strips to complete the assembly. The sides will be cladded with UPVC.
The calculations had to be quite precise as I didn't have much breathing space
To be continued...........
I need some help from the automation gurus here to understand what I need to do to link observatory control with weather conditions.
Having got my first observatory up and running, I immediately started to think about improvements (sigh!).
I had not been thinking much about automation as I actively enjoy being out under the sky. So while running an astrophotography sequnce, I will often be using my Dob or binoculars to just look around in wonder. However, whilst this is great for the first four or five hours it palls if you go on too long. I had a nearly 8 hour session over the New Year that was satisfying, but exhausting. I know I can't do that too often.
But here in North Wales the weather changes suddenly and forecast or not, I can't trust that I won't get a sudden shower hitting my lovely, sensitive kit. Clearly, at a minimum I need cloud/rain sensors and a way to park up the scope and close the observatory.
My confusion is that I can't get my head round which bit of software/electronics does what when.
Relays can provide the switching signals to open and close the observatory. Rain and cloud sensors can detect changing conditions to trigger action. But how do I link them together?
My current arrangement has a mini-PC on the mount running NINA for control and acquisition and PHD2 for guiding. It works well.
NINA has a Switch facility that I think can send signals to make things happen and detect conditions (also has a weather hub), but these seem to work through ascom. So although USB relay boards are widely and cheaply available, it doesn't look like they have ascom drivers. Do I need to run a set of relays via an RPi or Arduino to make it ascom compatible?
I have read a number of references to client and server architectures so that one computer is monitoring the weather and controlling the obsy mechanics, and another is managing the imaging rig, but I don't understand how they talk to each other. People say INDI is the answer, but I can't visualise the layout and the relationship between the various bits.
I read with interest (and with hope) the thread started by @steppenwolf on unattended observatories, but I could not follow it completely. It seems to be exactly what I was looking for, with the option to restart if the weather improves. But I don't understand how it was done.
Specialised astro-control computers like the Eagle 3 might be the answer, but the price is steep.
Can anyone point me to a resource that shows how these automation systems operate and what kind of kit beyond a mini-pc I might need?
I am not wedded to NINA if Voyager or SGP will do a better job. I have no problem setting up and coding (within reason) a RPi or Arduino, and I am reasonable comfortable with scripting. I just have a mental block about how it all works. Once I have a thought model that works for me I am sure I can sort it out, but right now I am confused.
I have a steel pier for sale. This was purchased along with a pulsar dome and believe it is an older Pulsar model. The pier sat in a yard, exposed to the elements for a few years before I purchased it so there is some surface rust and flaking paint but will clean up nicely. £250 and buyer will need to collect from Suffolk.