Recently Browsing 0 members
No registered users viewing this page.
After some trial and error I'm getting some very good guiding results with PHD2 now. 60mm guidescope and ASI290MM mini camera. The M42 image taken late March was 12 x 15 second exposures taken manually with my dslr / C8 and a stopwatch. Stacked in DSS and played with a bit in GIMP. On the night I couldn't get APT to register the camera - turned out to be the mini USB cable (although later trials point to the socket in the camera being a bit loose too).
Bought an iOPTRON iPOLAR that arrived on Friday and had a play with that which has resulted in near perfect polar alignment. 2 star alignment and an additional 2 calibration stars on my Advanced GT mount means I'm getting very accurate GOTOs now and PHD2 (through the ST4 port on the ASI camera) seems to be guiding very well. Last night after more cable faffing I managed to get everything working together to the point where I felt confident enough to leave it running by itself for an hour and a half (45 minutes of 180 second exposures plus 3 minutes each exposure to save the file - I've since found out I shouldn't have noise reduction switched on in the camera - DOH!) so M51 is 15 x 180 second @ ISO 800 lights and 5 x 180 second darks. A little manipulation in GIMP and I think it's come out very well. Obviously still have a lot to learn and I'm going to have to start taking much longer exposures but I'm quite pleased with these 2 pictures.
I had promised myself to write this up but then NigeB beat me to it - so thanks NigeB for the prompt!
For most, the problem is how to justify the cost of a purchased system compared to a home-built system. For me it was slightly easier - I have a 2.7m dome that isnt a standard manufacturer or for which an Off the Shelf system is available. So the only approach is to build my own.
I'd previously built a timing belt dome rotation solution for the first dome I had, about 10 years ago now. This used wiper motors and glued belting and timing pulleys to drive against the belt. But havent motorised a shutter before.
The reason to do this is typically to automate the dome for unattended operation. For some systems, there is a cost in added noise of the solution using clanking chain, for example.
The dome rotation is already automated using motors and an encoder into an ASCOM driver.
The Dome layout
The dome is a 2.7m wholly fibreglass dome, the shutter is in two parts - an upper sliding section and a lower sliding section which tucks under the upper section as it moves up the dome and is pulled out as it comes down. Below right is the rear section showing the power electronics, charge controller, fuse box, remote switch, environment sensors and flat field panel. Below left is the front section, showing the two-part shutter, retaining elastic spring and below-shutter recess for controls.
The bottom of the lower section has a plunger with a mushroom head which I used for locking it using an electronic latch driven by a solenoid.
The shutter rides on PTFE glides up and down the slot sides - the glides support the shutter on the edge of the slot and preserve its spacing and alignment to the edge of the slot.
One of the key problems I wanted to address in automating this shutter was to prevent the upper shutter running away once it had crested the balance point at the top and sliding to a slamming crunch on the far side of the dome against the stops in the middle of the night.
I had tried several solutions including elastic rope used as springs to keep the two shutter parts engaged but the last solution only survived 6 months of weather.
The other problems were to minimise the intrusion into the slot gap of the drive system, to keep operating noise at a minimum, to provide manual and automatic modes in case of systems failure and to fully integrate into the observatory control system.
As I hope to show later, I have written a lot of ASCOM drivers in ASCOM ALPACA as embedded hardware devices using the ESP8266 chipset. These have native wifi built in and are quite powerful little beasts.
I also have a Node-red server with MQTT messaging, openweather api and web dashboard available for integrating. So using that as a asis for driving any solution was an obvious choice for me.
I'd spent time lo0king at pulley systems like Steppenwolf and Hugh's and chain systems like the Pulsar before coming to something I wanted to try.
The solution I devised took a lot of testing of drive systems, motors and electronics.
To minimise the visual intrusion into the slot space I adopted 1.6mm diameter steel wire rope to pull the shutter up and down, attached to a lower corner in an 'endless-rope' model.
The steel wire does the actual pulling; as it pulls the shutter up it rides over the side pulleys on the way up and back through wire guides for the returning wire.
The problem of the collapsing shutter and its changing length could be ignored since I was only interested in driving the lower edge to carry the entire load.
The wire rope needed to be carried over a few home-made rollers since it also needed to be picked up by the rollers on the way down again.
They were turned from PTFE and attached to a turned alloy block which was then body-filler glued to the slot edge at just the height to pickj up the wire while allowing the sutter to tide cleanly over.
In the picture you can see the alloy block, the nylon pulley wheel and the transiting wire guide below. There are 4 of these in total from top to bottom. The white object is one of the PTFE glides.
At the top of the run, the motor and its winch bobbin takes a few ( 5 or 6) turns for its winch action and then return the wire through wire guides back to the bottom, around an idler pulley at the bottom of the slot and back to the bottom edge of the shutter.
The drive motor itself is the ubiquitous 12v electric geared motor, effectively a wiper motor but purpose bought for the 20Nm torque requirement that I measured by experiment, trying various motors and destroying a few, to lift a 20Kg weight off the garage floor.
The drive comprises this gearmotor and a turned bobbin, acting like a ships winch on coils of wire wrapped around it. The infeed and outfeed of the wire rope is separated across the winch and displaced by 10mm or so, so by laying a few turns of wire around the bobbin, the bobbin behaves just like a sailing winch.
For this to work, the wire has to be kept under a certain tension and the wire has to play through evenly otherwise it lays over itself and jams.
You can see the bike wire tensioners from brake parts, the winch bobbin, and the large motor below. It bolts directly to the bulkhead using an alloy L bracket.
The motor started off located at the bottom of the shutter opening where it was accessible but there wasn't much space there and when I needed to get a bigger motor it would no longer fit the small cubby hole so I had to change to a top mounting for the motor, above the telescope.
Interestingly, a very small DC motor with a 500:1 gearbox on was also successfully tried but the key probem there with the torque was getting the pulley not to slip on the small gear axle. It takes more than a 4mm screw on a flat to hold that pulley .
The motor controller also went through a few iterations. While using small motors, small controllers could be used. Starting with small PWM current drivers and ending up at a 40Amp controller which could easily provide the up to 20A stall current of the final motor.
In early use, the fastening point at the lower edge of the shutter just captured the ends of the wire rope under a screw on an aluminium fixing bolted through the shutter. Thats not very kind to the rope or your fingers when the rope starts to part and presents nasty sharp wires to the fingers trying to feed it back into a small hole for fastening.
also, the rope stretches a bit after a few operations so needs re-tensioning to take the slack out, otherwise the bobbin doesn't take on the friction necessary to drive the cable without slipping.
In later use, I redid the fastening point as per the picture below - spring tensioners on both upper and lower runs, with cable tensioner for easy take up, proper wire clamps to form wire end loops nicely and small v-groove bearings to take the wire round the corners into the up and down runs.
The spring fastening points are the bolts used to mount the mushroom headed bolt used for the dome latch.
In the picture, the handle provides the inner shutter guide with the wheels which prevent the shutter blowing out and off. To the right is one of the limit switches. The wire guide goes to the slot lower surface , turns the wire around the pulley wheel underneath and comes back to the wire tensioner rig that can be seen on the lower shutter below the handle.
Industrial switches are used for the two range sensors - one represents a closed signal - ie at the bottom, the other is the fully open signal, ie when the shutter is fully at the top.
anywhere in between is also regarded as open - there will be a an inclinometer fitted as part of the controller to register its actual position to allow the shutter to be controlled to a part open position
The switches are glued on to the dome using hot melt glue. This is OK if care is taken cleaning the surface before gluing and the surface isn't in full sun. If it gets too warm, the glue fails. At some point, both of the fixings will be replaced with body filler used as adhesive.
Power is provided by a 100W flexible solar panel on the outside of the dome section the shutter runs over, so while the shutter is open the panel is not charging.
Two batteries are used to collect this power - totalling 21 Ah at 12v. A MPTT charge controller, an automotive 6A 12v regulator and a fused distribution point completes the power system.
The local devices attached to this mobile power include the shutter controller, the shutter motor, the dome environment internal sensors, the flat field light tile and two IP cameras currently under test. The last device is an ASCOM ALPACA switch device which controls 4 relays remotely over wifi to the node-red web dashboard.
The shutter controller provides a manual and automatic mode of operation. A switch flicks between the two modes. A second switch then operates the dome direction by providing the right signals to the high current driver stage. The driver can take PWM signals for soft speed control. I haven't included that yet...
In automatic mode, the controller monitors for web calls from the Dome controller and moves the shutter to the tasked position using the switches to detect travel limits.
When opening, the latch is operated automatically to release the shutter for a short period until clear of the lock. Nothing needs to be done but close to lock it in the other direction
This project has taken a lot of elapsed time but maybe a month or so of duration - ie time I actually spent on the project. Over about 4 years.
I had to work out whether the winch model would work, and what bobbin profile was required, where I could source a winch from or whether to make my own , test some motors for torque and size, turn the bracketry and wheels and finally fitted the spring tensioning system.
The system cost was relatively low.
£180 for the motor from rapid electronics
Wire rope is £5 for 10m from various stockists.
Wire rope clamps are a few pounds each.
Aluminium bracketry from the scraps box.
Pulley wheels turned from material again in the scraps box.
Wire guides bought in 5m lengths for about £15. The sort used for bicycle brake and gear wire guides.
A few bicycle brake and gear end nipples and trension adjusters from the scrap bikes bin
The ESP8266 controllers are £2 ea. I use an esp8266-01, a PCF8574 i2c 8-bit expander and a BTS7960 driver at £20 for 2 off the web.
If I replaced the driver I would use a Cytronics i2C motor controller for direct control rather than requiring bit bashed signals. These are also cheap and have 30A of current.
Risks and issues
The motor is sufficiently powerful to probably pull itself from the mountings if the batteries lasted and the shutter ran up to the hard stops for long enough. To try to prevent this It is individually fused to 10A and the regulator limits that further to 6A.
The motor in stall mode also drains the batteries very quickly. They are not really meant for this type of load. The way to manage this for me is to provide a way to remotely charge the battery at night. This so far , has taken the form of a charging coil capable of 140W through 10mm of free air from AliExpress. In the case of the batteries going flat, I can rotate the dome to align the charging coils and recharge that way. Sadly my charging coil is currently not functioning yet. I think I blew it up while testing.
As mentioned, the controller is an ESP8266-01 wifi module which is programmable using Arduino tools. Its a 3.3v device so the device bottom left in the picture is the 5 to 3v3 regulator along with another 12 to 5 regulator to manage the power drop from the supply.
The ESP is the red/blue led device with the visible wiggly wifi aerial. It is tiny.
To the middle is the i2c expander. this turns a 2-bit serial control signal into an 8-bit parallel set of signals.
One bit flashes at a 1 second interval to indicate life.
Another provides the control to the MOSFET transistor buffered through a 2N2222a NPN transistor that powers the solenoid lock.
Top right provides the switch signal inputs and the signals from the manual switches that are then fed to the motor driver unit through the 6-pin connector.
The code is available if interested at
http://www.github.com/skybadger . As mentioned it supports ALPACA, supports remote debug over telnet and remote update of the firmware.
The dome power is enabled by script (Voyager) or manually through the web dashboard. That means turning on the mount remote switch power feeds and then turning on the shutter control.
The shutter control is then turned on through the dome remote switch and integrates into the ASCOM dome controller and operated directly from voyager.
as discussed elsewhere, Voyager then opens and closes the dome based on observing conditions inputs from external sources. My external sources are the openweather api forecast for my location and my weather centre (itself a rebuild using an ESP of an old maplins weather station to wifi enable and integrate it into MQTT).
The weather and conditions get reported to an ASCOM observing conditions hub which Voyager queries for Safety events.
While all the drivers (observing conditions, safety, dome controller ) are all built and operating with Voyager, I'm in the final stages of debugging the shutter control logic for full automatic operation while all the manual switching works like a dream...
What I find most satisfying is the way the spring tensioners move in and out like pistons as the winch drives the shutter up and down. And that its a whole lot quieter than the manual process before.
Hi all PHD2 seems to be playing up again and Iost a clear night again 🤬 Everything appeared to be fine and after polar aligning (separate camera to guide scope) I set up a new sequence. That started up and focused, plate solved and then guiding started but after a few seconds of perfect looking guiding the RA and Dec went off the scale massively ending up with a PHD error along the lines of "PHD2 is unable to make sufficient corrections in RA, check for cable snags, redo calibration...." Images obviously come out trailed. I have an RDP connection to the laptop at the mount so after happening a few times I went to check for snags etc but it all seemed fine. I set up the sequence again at the mount and the same thing happened. Restarting the apps, power cycling the kit and choosing different targets all resulted in the same issue so I packed it all away. It was also the same if I used PHD2 via NINA or if I just started PHD2 on its own and tried guiding separately.
I'm using an AZ-EQ6 with a WO guide scope and 120mm if it's relevant.
I checked everything was tight and have not looked at any logs yet but does anyone have any bright ideas what might be happening please?
Thanks in advance...
As I remember it was painful for me at the beginning to find complex list of the software that needs to be installed on your PC to control your rig remotely so I have decided to tie all things together and share.
I will try to explain it simplest I can. As whole idea is quite complex I am not going to be too detailed. You can treat it as quick catch up for novices and beginners only. I have tested it all on Windows 10.
I am a beginner as well but true is that I have struggled a lot to find those information all together (what actually you need to install) so it could make some confusion for novices I think. That’s why I want to tight things a bit together and reveal the tip of the iceberg. But at least COMPLETE tip. It should be suitable for most of equatorial mounts with guider.
First why I am not using SynScan hand controller? Answer is simple. Controlling rig through PC is way more accurate and more convenient. So in general I have USB hub attached to one of tripod legs.
To this hub I have connected:
HEQ5 Pro mount through EQDIR USB cable (it is plugged on mount into hand controller port) ZWO ASI 120MM-S guide camera which is attached to my guide scope Canon 6D camera 2 x dew heater straps (for scope and guide scope). Those are attached to charging only ports on my USB HUB. Mentioned USB HUB is plugged to the laptop which is outside, close to my rig during sessions. Then I use RDP to connect to laptop from inside of my house as both, laptop and my desktop are connected to the same router.
Concept is simple as you can see but it needs whole bunch of software to be installed and configured to work properly. Again I will go through it quickly to do not mess too much and I will try to provide links for some tutorials which I have used at the beginning to understand whole concept.
ASCOM; You can understand it as a platform which will create environment for EQMOD driver (I will explain what EQMOD is in next paragraph). This, alongside with EQMOD, is core part which will communicate with your rig through USB and also will create a kind of link between all astrophotography software that you need. Please watch Dylan’s short vid who has explained it in convenient way: https://youtu.be/Se88i3Cs6M0. You can find and download ASCOM platform in here: https://ascom-standards.org/. EQMOD (EQASCOM) is a driver that provides the astronomical 'brains' of the mount control system as per: http://eq-mod.sourceforge.net/eqaindex.html. As you can see there a list of functionality is huge. You can download it from here: https://sourceforge.net/projects/eq-mod/files/EQASCOM/. FTDI Virtual COM Port Driver is another small piece of software that you need to install. In general it is driver for your EQDIR cable. To be honest I haven’t heard about it in ANY tutorial. Like everybody has forgot about it but without it nothing will work. So in general EQDIR USB cable needs to be emulated as standard COM/Serial device. You can find it in here: https://www.ftdichip.com/Drivers/VCP.htm. It will install itself as COM1, 2 or 3 device. You will need to pick same port in EQMOD with same speed. Above three apps are core and needs to be installed. If you have doubts (I am sure you do, like I had a bit more than a month ago) please just lurk YouTube and watch more related tutorials.
You will need also to install drivers for your main and guide cameras. You can find it on your manufacturers website.
Now I will describe software of my choice (of course you can pick another, as there is a few alternatives for each of it). Those software will let you auto guide your object in more accurate way, perform polar alignment without looking through polar scope, will help you to plan your session on particular objects and check FOV, will control your main camera wit GoTo functionality and many others:
PHD2. Ok in here there are no alternatives. If you have decided to control remotely you rig you need an autoguiding software and PHD2 is probably only or at least best and simplest option. In general it will connect with your mount, guider, will “stick” on one or more stars close to your object, will look on it carefully through your guide scope/guide camera and will send information to your mount how and where it should move to stay on track. You can visit again Dylan for more info: https://youtu.be/Mt0luBLaHDw. You can download PHD2 from here: https://openphdguiding.org/. This is first example of software that will communicate and control your rig through 3 core software described above. SharpCap; This is actually software of my pick. Its main purpose is planetary astrophotography but it has one very useful for me functionality. A great and cheap tool for polar alignment. You don’t even need to look through your polar scope or spent fortune on dedicated polar cameras. It will use your guide scope camera! I have used this tutorial to learn it: https://youtu.be/ivlgbgNIeTU. It is really simple and straight forward. No more kneeling in the wet grass for just 10 quids: https://www.sharpcap.co.uk/. If you struggling with standard PA process you should definitely consider to check it out. I am super happy with it. Cheers @SharpCap. Stellarium. This is planetarium software of my pick. I use it to plan my session in time, plan FOV (at what angle should the main camera be attached to the focuser to cover object in best possible way) and before I used it as GoTo tool (now I use Plate Solving GoTo). You can find more info and download it in here: http://stellarium.org/ A lot of people use app called “Cartes du Ciel” but I have never tried it.. Astro Photography Tool – APT. Next software of my pick. I use it to control my main camera, plate solving and few other minor, but still very important things. Cost is less than 20 quids per year for further updates. I think I have decided for APT because I like interface, functionality and something silly- most of experienced astrophotographers which I have watched on YT have used it. And I absolutely do not regret it. You can check demo version or buy it in here: https://www.astrophotography.app/downloads.php. You can watch Trevor’s walkthrough as well: https://youtu.be/icd9Tlrb9Jg. Lots of astrophotohraphers uses NINA which is offering similar functionality and it’s free. I haven’t tried it for longer yet as I have already get used to APT but if you want and you will like it - it could save you 20 quids. Plate Solving – is one of very cool APT and NINA functionality (based on external free software). In general it works like this: You can for example take a blind shoot of night sky and ask plate solve software to tell you where exactly you are shooting with your scope and how FOV look like for you. So if your software knows it already it can take you to any other object on the sky just like that (like GoTo). I have learned how to install and use it from this video: https://youtu.be/dpYXoYEKFpA. It is 2 apps plus databases. You can also consider to buy (or at least check out) ZWO ASIAir. In general it is micro PC which has all software similar to above installed and tied together on one simple panel which you can control through WiFi on your tablet. A lot of astrophotographers use it. I didn’t have any occasion to try it yet but it looks so complex and simple in the same time. Definitely it looks very convenient and handy as well.
At the end just few words about post processing software of my choice:
AstroPixelProcessor; why I have decided to pay 60 quids to rent (or 200 to own) software to stack images if there is free Deep Sky Stacker? Because I live in Bortle class 7/8 area so my data is not the best quality. I have found that APP is handling it much better and it has important for me, and well working functionality to remove light pollution and perform initial photo stretch. You can find more info in here: https://www.astropixelprocessor.com/. I have learned it from Tim’s tutorial: https://youtu.be/9EAKNqZ201Q. It is very simple in use as you won’t need to change most of the default settings. Someday maybe I will switch to PixInsight which offers even more cool postprocessing functionalities but like for now I am happy with APP + PS 2021. PhotoShop. I am absolutely not PS magician but I just get used to it already. You can try free GIMP if you would like to. If you have read this to the end you see that actually to control your rig remotely and PP your photos you need to install… around 15 different applications and drivers. As I have mentioned at the beginning this makes a lot of confusion for beginners because you can find detailed instructions for particular programs or drivers but you will never find complex list from A to Z (at least I haven’t found) of software that you will need. I will highlight it once again that most of the described apps are my personal choice and you can find other options (I have tried to provide a few alternatives). Another problem is that most of this software needs to be configured properly so unfortunately you will need to dig more on your own but I think this is pretty good portion of information if you have just started.
Good luck and clear skies,
I recently got an Orion StarShoot Astrophotography Camera and have had difficulty getting it
to work right. The software that comes with it AstroCap seems horrible. The start/stop mechanisms
are vague, the images won't appear. The best I've been able to do is see scan lines and some
color light or dark variations on the screen after messing with the exposure and the gain.
Popping the camera into the reflector or the refractor telescope yields nothing. I'm told
there is other software that is better supported and more current including SharpCap
and NINA. However so far neither of those recognize my StarShoot with the ASCOM
Can someone tell me precisely what drivers I need to get the Option Starshoot (the original)
to work with SharpCap NINA or some other software? A link would be much appreciated.
What I downloaded from Orion have been AllInOneDrivers.ZIP AllInOneASCOM.ZIP and
ASCOMPlatform 6.1 and later 6.5. The only software where I'm able to deliver even
a poor image to the laptop has been AstroCap. Or if there's a new and improved
AstroCap beyond 1.3.9 do tell!