Search the Community

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 drivers loaded. 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!

Hello, Last year I developed an 'all sky' imaging application to run my Starlight Xpress Oculus camera (for Oculus owners you can find out more here: https://groups.yahoo.com/neo/groups/allskeye/info). I have recently added 'experimental' ASCOM support for it but don't have any other cameras to really test in on. If anyone is looking for this kind of software and would be happy to carry out some beta testing please let me know. Please bear in mind: The software is really designed for traditional astronomical cameras using longer exposure lengths i.e. not video astronomy and am not sure how well it will work with faster CMOS cameras The software is mono only, no colour images can be processed (although it might be possible to use a colour camera to produce mono images - something I would like to test) It has been running for a while so is reasonably stable but please bear in mind that this will be a beta test so do expect problems! :-) Oh and sorry but it will only work on Windows computers from Vista onwards (no XP) Thanks, Mike

Hello fellow astronomers, I have come to the forums as I have depleted all other options. I own an NEQ5 GoTo with a Skywatcher 72ED. I have connected the mount to my computer using an EQDIRECT cable. I am trying to use stellarium with ascom and eqmod to slew the mount to a desired object. I have configured my scope using the “telescope control” plugin in stellarium. In the past I had successfully achieved slewing through stellarium. The problem is that now, one month later, when opening stellarium and trying to slew the telescope to a selected object (using either the “slew telescope to” panel or the shortcut (control + 1)) the mount moves for a fraction of a second and then stops, stellarium freezes and then the scope indicator in stellarium slides quickly to the horizon, and EQMOD control panel displays “horizon limit horizon limit” error. (Let’s call this the “main failure mode”.) Note that : I can use EQMOD and slew the scope manually without problem. If using it in tandem with stellarium, when I do so the scope indicator in stellarium moves without issue. I have used the “resync encoders” button on EQMOD to establish the home position, but this does not affect the behavior. I can use ascom device hub to slew the scope manually without a problem as well. The main failure mode described above happens most of the time. However, I sometimes get other erratic behavior in stellarium: Sometimes, when trying to slew the scope in stellarium, the mount moves for a second then stops (as described above), yet the scope indicator in stellarium moves to the selected object not the horizon, then the mount starts to track (even though it has not yet slewed). Or, rarely, when trying to slew the scope in stellarium, the mount physically moves (seemingly to the object) and starts tracking, the scope indicator moves to the selected object -- appearing to work normally. But then, when trying to slew the scope a second time to a different object, it fails again as described in the main failure mode above. I have tried opening stellarium as administrator but I still get one of the three outcomes when trying to slew. Does anyone have any insight on this ?

Sooo...I'm getting quote frustrated here. This spring I tested my HEQ5 with guiding. The synscan controller was connected to the computer trough the USB plug on the hand controller. This worked like a charm in my living room. On the new controllers you dont need the rs cable. But when I tried the whole thing with guide cameara for some live shooting, it just did not work. I get something wrong with the com port in decice manager, driver not working. I have tried 3 different drivers. The whole thing responded, connected and was guiding when i did a dummy test before the summer. So setup is pc-synscan via usb for pulse guiding. Can it be a problem with windows 10? What t h.... just happened? Where can I find a driver that works? And believe me it worked 5 months ago, argh. Thanks for any respons and support

Hi So I use Windows 7 EQMOM ASCOM 6SP2 Cartes du Ciel and for Guiding im using PHD So I set up and align with EQMOD with no issues and then slew to target and image away, PHD does the guiding independently of EQMOD and all is well. If I then try to move to a new target I get the message that EQMOD is not responding so I have to kill Cartes du Ciel and restart. This behaviour is consistent, I have no way of knowing when EQMOD stops responding but it does. So is there any logging within EQMOD that may help track down the issue ? Regards John Berman

Has anyone had any experience installing ASCOM driver onto the EQM 35 pros SynScan hand controller for using with PHD2? I'm watching a tutorial using PHD2 and the chap is using ASCOM for connecting his computer to his guide camera instead of using a cable. So the computer becomes the middle man instead of the mount. Thanks, Mark

Read more and download: http://www.lightvortexastronomy.com/tweet-remote-control.html Tweet Remote Control is a Windows program written in Visual C# 2015, embedding the Tweetinvi and ASCOM references. It is meant to act as an inconspicuous safety backup, particularly useful to those with remote hosting for their astrophotography equipment. The original motivation behind Tweet Remote Control is for when you lose remote control of the remote computer. This can happen due to various reasons, including TeamViewer failing or their server encountering connectivity problems. It is sometimes necessary to restart the computer, or TeamViewer alone, for example, in order to recover remote control. When all else fails, parking your mount and closing your roof may become necessary measures to protect the equipment against possible collisions and from the elements. It is here that Tweet Remote Control can assist, provided the remote computer has an active Internet connection, of course. This stops you needing to have someone to immediately attend to the equipment physically. Put simply, Tweet Remote Control starts with Windows and runs in the background. It connects to a Twitter account of choice and therefore responds to specific commands, effectively sent by tweeting them via the connected Twitter account. The program monitors this connected Twitter account and reads new tweets made. If a tweet made matches a command written into the program, it deletes the tweet, executes the command received and tweets on your behalf (to update you on what is happening). Since all the program requires to function is a connection to a Twitter account, it need only be running on the remote computer with an active Internet connection - the rest is up to your tweet commands! Many features are supported, including control of ASCOM roofs, mounts and power relay switches (as well as Lunatico Astronomia's Seletek Dragonfly). Tweet Remote Control ensures it always starts automatically with Windows (once you connect a Twitter account, that is), and re-authenticates with Twitter automatically every two minutes. This ensures the program is always active with minimum delay, even if the remote computer's Internet connection drops for a period of time. When Tweet Remote Control starts, if it is connected to a Twitter account, it does so minimised to your Windows system tray as a small, black and white icon labelled TRC. Here, the program will remain with no user input required and with no pop-ups whatsoever. The key is being always-on and always-ready without user input and without hassling the user with pop-ups or messages. Finally, Tweet Remote Control is 100% free. Please feel free to contact me for bug reports or to request new features be added! Current list of capabilities in version 1.4: 1. Restart your computer 2. Shut down your computer 3. Restart TeamViewer on your computer 4. Close an ASCOM roof 5. Open an ASCOM roof 6. Check the current status on an ASCOM roof 7. Park an ASCOM mount 8. Check the current status on an ASCOM mount 9. Open power relays (turn off) on a Dragonfly 10. Close power relays (turn on) on a Dragonfly 11. Check power relays on a Dragonfly 12. Open power relays (turn off) on an ASCOM power relay switch 13. Close power relays (turn on) on an ASCOM power relay switch 14. Check power relays on an ASCOM power relay switch

For those that may have missed this an update to ASCOM platform version 6.3 was released on 17 Jan 2017. Several components updated, new Windows 10 installer (post Anniversary edition) that fixes many Windows 10 installation issues, enhanced .NET support and updated MS Visual Studio templates. Added support for safety monitors and observing conditions interfaces, extended support for new astronomy applications and drivers that have appeared since ASCOM version 6.2 was released. http://ascom-standards.org/Downloads/Index.htm

Setting up all the software on my win10 laptop and getting things to talk to one another is a nightmare. I'm starting a new thread, so I can post all the problems I am having, one at a time, so issues don't get confused. This will also hopefully help anyone coming to similar situations later, as the problems and answers will not be interlaced. First issue: APT does not detect ZWO camera. I have got the camera (ZWO) drivers installed and sharpcap can see it and will connect to it properly. However, when I try to connect the camera in APT, the only CCD options it gives me are SBIG (which it isn't), QSI (which it isn't) and ASCOM. Now it shouldn't need to use an ascom driver, because the proper driver is installed, but I give it a go anyway, and this just offers me 2 simulators and 3 QHY cameras (I have one qhy driver installed for the guidecam .... I'll get to that later!). I have disconnected both the filterwheel and guide camera from the camera hub, so they cannot be interefering with the process. I am at a total loss ... any suggestions? Thanks.

Hi all 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 Time 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. Cost 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. The Electronics 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. Operation 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. Final disclosure. 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.

Hey, I have a question, did anyone here have luck installing ASCOM alpaca Remote Server on a Raspberry Pi 4? Or is it like I suspected as in the below image not possible, unless it's a windows machine?

I have a venerable old Meade LX200 Classic which I drive using the Meade LX200 Classic and Autostar #494, #495, and #497 (combined telescope/focuser, 5.0.4) driver on an ASCOM6.1 platform on my Windows 7 Pro 64 bit computer. Last night all was running well with Cartes du Ciel,(CdC) PHD guiding and APT camera control all connected simultaneously with no problems. CdC is used for GOTOs, PHD for guiding and ASCOM talks to the mount for plate solving and for dithering. Half way through the night I shut down APT and relaunched it, only to find that it wouldn't connect to the scope. On testing, I found that in fact this problem was not restricted to APT. What had happened is that I could connect to the scope via ASCOM with any of these pieces of software one at a time, but regardless of the order I launched the software, not two programs simulateously. (I checked that PHD was set to server mode). I have tried uninstalling the Meade drivers and ASCOM itself and installing the latest version of each but I still get the same problem. Ideas? Thanks

Good afternoon, I'm still new to astronomy in general, my setup is explained in my previous post. I am trying to get plate solving working. I can get results from Astrometry.net, and I can get All Sky Plate Solver to solve when given an image file, but I am trying to get it to work with my ZWO ASI224MC direct. When I try "Click, Solve & Sync" I get an error "Camera array data unsupported." I have my camera connected with ASCOM as ASI Camera (1). The Image Type options are Raw8, Raw16 and Y8. Raw16 is selected and seems to be the default. I have tried the others and they all produce the same error. I've tried it with and without MonoBin. Binning is set to 1 and Subframe to 100% (50% tried). Filter is blank. I can connect to the camera in SharpCap via ASCOM (although it warns that it prefers native drivers). I've also tried the SharpCap native Plate solver with the astrometrics install from ASPS, it tries to solve takes a while, but can't find a solution. I also tried AstroTortilla, that reads from the camera but just returns "No solution in 0.0s". I've tried a Google search for the ASPS error but it doesn't find anything. I have checked only one application has the ASCOM camera at once. Any suggestions would be appreciated.

I have got a problem with my QHY5L-ii. (1) It works with Sharpcap - so it cannot be the hardware or connections per se. (2) When I try to run PERecorder I get a black screen and the 'configure' button tries to configure my main ZWO camera (which is not connected). Previously it was automatically connecting to the camera in the laptop, which I have now disabled in Device Manager. (3) When I tried to run it in APT, it was not recognized. I discovered I needed an ASCOM driver so downloaded and installed both (capture and guide) from this page (V0141). Now the camera is recognized and appears to work, except that no image is captured [nothing covering front of camera!]. I have followed through the instructions on this page, and (except for the camera selection not being IC8300 - it is "QHY5LII-C-6117d81029b92212") everything goes fine until I click 'start', when it starts going through the motions (on the log screen), but nothing is produced. The preview screen is on(fit) and I have also checked the saved files (which are blank). As both APT & PERecorder are ASCOM-related, my guess is that, if I can cure either (2) or (3) above, the other will be cured as well. And I would also guess that more people are using this camera on a regular basis with APT than PERecorder. Therefore, if there is anyone who uses this camera on APT, who can offer any pointers as to where I may be going wrong, I would be most grateful. Thanks.

I have recently bought a Stepper Bee board and stepper motor to build a computer controlled autofocuser. The stepper bee software works like a trean on a PC and the clumsy assembly that I made to connect the stepper motor to the focuser also works fine. Then I started thinking it would be nice if I could find an ASCOM driver that could control the Stepper Bee. that way I could perform automatic focusing. Before I start to develop the code myself I did some search on the internet but could not find anyone who has successfully developed such code. I found a thread about dome control with stepper bee & ASCOM however, and I am thinking perhaps the codes could be similar. Does anyone knows of any code / plug-in that has already been develped? Is anyone using Stepper Bee for autofocusing? I can really use some advise. Thanks, Naeim

My first dip into guiding. I've got a DMK2104AU camera on my guidescope, and am trying to connect my EQ6 to my laptop via an RS232-USB adaptor to use PHD2 for guiding. PHD successfully connects to the camera but when I try to connect the mount (I've downloaded the ASCOM drivers for Skywatcher ASCOM), I get an issue in that it says the Port field cannot be left blank. When I go into Device Manager on Windows I can see the Serial-USB adaptor successfully assigned to COM Port 3. However in PHD this just isn't appearing in the dropdown and I can't just type it in. Any thoughts on how I can get PHD2 to recognise the COM Port required for Serial-USB adaptor? Thanks in anticipation.

Ok, after a stalled attempted a few months back, I am now determined to learn how to use SGPro for helping out with my imagining sessions. Going to be lots of questions over the next couple of weeks, and the first one is pretty basic . I am using an Atik One 6 CCD camera which has a built in filter wheel. Does anyone know what driver (ASCOM?) I need to use so that SGPro connects and controls the filter wheel properly? I am proberly doing something stupid, but none the the dropdown ones seem to work .

Hi I'm looking for an ASCOM compliant Electric Focuser which I can attach to my low profile Moonlite Focuser which is attached to my Skywatcher 250 Pointers appreciated Regards John B