Jump to content

stargazine_ep45_banner.thumb.jpg.71f13bfceacd5e3df366d82c2b6f5f9b.jpg

Recommended Posts

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.

Link to post
Share on other sites
  • Replies 189
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

God do i detest PC's, Apple convert since i literally ran my PC tower over with my car and you tubed it years ago.

Hi, SharpCap is not looking for Astrotortilla.exe, but the 'solve-field' script that AstroTortilla relies on (solve-field is the solving engine, also used by astrometry.net). SharpCap will look i

Sorry that is not 00% correct - I use Win 10 home on my tablet and it happily runs a number of apps ,which I have written , using TCP client/ server / UDP basis. Plus you can run CDC on another PC and

Posted Images

 

1 minute ago, Rob said:

Straight off the top of my head. How about Win 10 compatibility mode? 

I have a ASI120MM running under Win10 with no issues regarding compatability mode = I'd be checking that you have installed both the native ZWO driver, *and* the ZWO ASCOM driver (they are 2 separate downloads on the ZWO site: https://astronomy-imaging-camera.com/software/). It sounds like you either haven't got the separate ASCOM driver, or it's not installed properly. 

Link to post
Share on other sites

I have both a 120mm & 1600mm running happily on a Win 10, together with mount\focuser\phd2\ansvr\filter wheel etc. all being run by either APT\SGPro etc.

As a first starting point, go to https://astronomy-imaging-camera.com/software/ and download\install the latest versions of all the drivers, also install ASICap (its useful as it will run two instances, so can have both cameras active at once)

 

Link to post
Share on other sites
46 minutes ago, Dr_Ju_ju said:

I have both a 120mm & 1600mm running happily on a Win 10, together with mount\focuser\phd2\ansvr\filter wheel etc. all being run by either APT\SGPro etc.

As a first starting point, go to https://astronomy-imaging-camera.com/software/ and download\install the latest versions of all the drivers, also install ASICap (its useful as it will run two instances, so can have both cameras active at once)

 

Thanks.

I already have the latest proper driver and will, as above, download the ascom driver when I get back to my desktop this afternoon. What do I need asicap for?

Link to post
Share on other sites

The ascom driver for ASI only drives 1 ascom ASI camera.  If you need to use 2 (ASI and ascom cameras) you need it, but if the other camera is not an ASI or a guide cam with PHD2 it's ok as it doesn't require the ascom driver.

Word from the wise, in my experience the ASI ascom driver/APT combo is pathetic, well, probably worse than pathetic, unusable - you can use SharpCap but dithering is non-trivial unless there's been recent updates, SGP very very good.

Link to post
Share on other sites

ASICap, needs no additional drivers, as long as you've installed the main driver.

 

One thought that has just struck me... Which version of Windows 10 are you using?, hopefully the Pro version, as there are gotchas with the cut-down versions.

Edited by Dr_Ju_ju
Link to post
Share on other sites
1 hour ago, John78 said:

The ascom driver for ASI only drives 1 ascom ASI camera.  If you need to use 2 (ASI and ascom cameras) you need it, but if the other camera is not an ASI or a guide cam with PHD2 it's ok as it doesn't require the ascom driver.

Word from the wise, in my experience the ASI ascom driver/APT combo is pathetic, well, probably worse than pathetic, unusable - you can use SharpCap but dithering is non-trivial unless there's been recent updates, SGP very very good.

I will only be using 1 zwo camera at a time (either 224 or 1600). My guide cam is a qhy & I have installed the ascom driver for that.

I would prefer to use sharpcap, but will be running the pointing program on apt and am going to try imaging with it as well. If it becomes too much hassle I will revert.

Link to post
Share on other sites
43 minutes ago, Dr_Ju_ju said:

ASICap, needs no additional drivers, as long as you've installed the main driver.

 

One thought that has just struck me... Which version of Windows 10 are you using?, hopefully the Pro version, as there are gotchas with the cut-down versions.

I'm obviously being dense. No additional drivers to do what? If I need to install the ascom driver to use the cam on apt, what is the benefit? 

Not sure which win10 it is - will check when I get home.

Link to post
Share on other sites

One of my reasons for going to apt is that I am trying to get away from AT that I always found to be temperamental at the best of times. The other 2 options require the computer that they are being installed on to connect to the Internet  (which this one isn't). I wonder if AT in sharpcap is better than AT on its own?

Link to post
Share on other sites
3 hours ago, Dr_Ju_ju said:

One thought that has just struck me... Which version of Windows 10 are you using?, hopefully the Pro version, as there are gotchas with the cut-down versions.

It's windoze 10 home.

Link to post
Share on other sites

Then you may have issues getting all the 'bits' talking to each other, as most of the software we use, acts on a client\server basis, which Home version is deliberately ham-stringed to disable such software working (its based on the user not needing to 'worry' about security, Microsoft has it covered :BangHead:). 

Link to post
Share on other sites
1 hour ago, Dr_Ju_ju said:

Then you may have issues getting all the 'bits' talking to each other, as most of the software we use, acts on a client\server basis, which Home version is deliberately ham-stringed to disable such software working (its based on the user not needing to 'worry' about security, Microsoft has it covered :BangHead:). 

Sorry that is not 00% correct - I use Win 10 home on my tablet and it happily runs a number of apps ,which I have written , using TCP client/ server / UDP basis. Plus you can run CDC on another PC and connect to it in "Client/Server" mode with ease. 

Yes I know certain features don't exist on the Home edition - RDP ,Virtualisation ,Bitlocker etc and "buffers"/resources are managed differently but disabled "client/server" working ?????

 

So could you please expand on what you mean by "deliberately ham-stringed to disable such software working" :dontknow:

P.S. APT does NOT support Native ZWO only via ASCOM ZWO drivers!

 

Edited by stash_old
  • Like 1
  • Thanks 1
Link to post
Share on other sites

Sorry if this is 'teaching grandmother to ... etc' but do your see the 'ASCOM Camera Chooser' dialogue box appear after you have clicked connect and selected CCD ASCOM Camera when the  'Selected Camera Type' dialogue box appears. (For CCD read CMOS for the 1600!) If you do get the ASCOM Chooser select ASI Camera (1) from the drop down list and that should connect the camera. (Assuming it's plugged in of course)

Link to post
Share on other sites

I have downloaded the ascom driver for these cameras from zwo site (v1.0.3.15) and will transfer it to the laptop later this morning.

I have also been thinking about the AT/Sharpcap option rather than APT.

For several reasons, I prefer using Sharpcap to APT as my capture program, so if AT works better as part of sharpcap than it did as a standalone program, it would make sense to go with that. Simple solution is to "suck it and see". So I will also install AT and transfer all the index files from my windoze 7 machine onto the new laptop and can try it. If it performs, I can remove APT completely, releasing that space for data. If it doesn't, then I still have Platesolve2 to fall back on.

I guess that, even if I remove APT, having the zwo ascom driver installed will not be a major drain on my ssd space, and may even help connectivity with some other part of the system.

Plan!

Thanks.

Link to post
Share on other sites
15 hours ago, Demonperformer said:

One of my reasons for going to apt is that I am trying to get away from AT that I always found to be temperamental at the best of times. The other 2 options require the computer that they are being installed on to connect to the Internet  (which this one isn't). I wonder if AT in sharpcap is better than AT on its own?

Nowt wrong with AT, just need the right settings binning being the first and obv the fov (and search radius).  However sharpcap can also use ASPS which is what APT uses behind the scenes iirc and both AT and ASPS run using the index files from astrometry.

The bottom line is, if you can upload your image to astrometry and it can solve it, you can also solve it offline using AT or ASPS if you prefer.

Link to post
Share on other sites

There was "nowt wrong with AT" - when it worked! Settings are, of course, important, but that does not explain why it will work on one go, but redo the same field immediately afterwards and it fails.

APT has 2 options, ASPS is one, but setting that up requires the computor on which it is being installed to be connected to the Internet. As stated above, my new laptop is not being allowed anywhere near the Internet. 

The other APT option is PS2, which allows you to download everything you need and transfer those files onto the laptop you will be using. This is the option I have provisionally put onto the laptop.

Link to post
Share on other sites

Second issue: PHD2 refuses to recognise QHY5Lii guide cam

Another setup that works on windoze 7 without any problem.

I have installed the latest ascom driver for this camera (QHY5LIIASCOMSetupV1.2.1.0).

I have tried this both with the guide cam plugged into the zwo hub (from where it will need to run) and also plugged directly into the laptop. I have tried both starting PHD2 first and then plugging in the camera and also starting PHD2 after the camera is plugged in. I have tried reinstalling the driver once the camera is already plugged in (which informs me that it is uninstalling the previous installation).

In all of these events and their various combinations, I get the message during the configuration startup, upon selecting "QHY Camera" from PHD that "No compatible QHY cameras found".

I had previously installed the wrong drivers ["QHYCCDASCOM Capture StarSenseSci V0.1.51.15" and "QHY5IIDriver 160519(Beta)"] which I have uninstalled using the "uninstall program" option. Don't see that this should be causing an issue, but mention it for the sake of complete disclosure.

Having solved issue one (see previous post), I'm confident the SGL community will be able to go "2 for 2". So, any suggestions?

Thanks.

Link to post
Share on other sites
12 hours ago, Demonperformer said:

There was "nowt wrong with AT" - when it worked! Settings are, of course, important, but that does not explain why it will work on one go, but redo the same field immediately afterwards and it fails.

APT has 2 options, ASPS is one, but setting that up requires the computor on which it is being installed to be connected to the Internet. As stated above, my new laptop is not being allowed anywhere near the Internet. 

The other APT option is PS2, which allows you to download everything you need and transfer those files onto the laptop you will be using. This is the option I have provisionally put onto the laptop.

You can also do that for asps,all you need to do is set it up on your other computer, download all the indexes that match your gear and copy it to the "no internet" notebook. 

the index files are located under  the "users\yourusername\appdata\local\astrometry\usr\share\astrometry\data" 

As for the second problem I'm trying to understand it, sure you'll find a solution in here. :)

Edited by Atreta
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By jacko61
      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. 
      Graeme.
       

       

    • By tooth_dr
      I've been trying to image a couple of galaxies per night, one pre and one post flip.  On early Saturday morning at 1:30am I changed over to M82, and acquired 63 x 3 mins subs, OSC, totalling 3 hours and 9 minutes of data. 
      Camera: ZWO 2600MC at -10 deg C, gain 100, offset 50
      Telescope: Skywatcher 250PX (blue tube), 1200mm F4.7
      Mount: Mesu e200
      Guiding: ZWO OAGv2, 290MM, PHD2
      Filters: None
      Software: APT for capture, APP and PS for processing
       
      I havent really had a chance to get much use out of this camera since I bought it in December, and I havent processed many OSC images before.  I've a bit of work to do, but still very happy with the quality of the data for just 3 hours of integration time.  I would like to add some Ha to this, but purposely didnt bother during the recent clear spell, as it was moonless nights and I gathered some broadband data on other targets instead.
       
      CC welcome.
      Adam

    • By gray
      Hi -  Am new to all this stuff so help on this DSS staking blocker would be much appreciated - done a load of googling but need to know if my hours of FITS are scrap
      Setup : ASI183MC - Sharpcap 3.2.6480 (Live Stack for lights, Capture for Darks - no bias or flats yet)- DSS 4.2.5 - Win7 64bit-USB2 - CEM25P - no guiding yet
      Problem:
      I managed to get Sharpcap into a mode where it was saving individual RAW Fits files for Darks and only the Stacked FITS for Lights.
      DSS spits these out with the message "The checked pictures are not compatible (width, height, number of colors, number of channels, only one master dark, offset and flat)."
      Investigation:
      If I check the Sharpcap CameraSettings txt file for the two (the set of dark FITS files and the single stacked FITS file) they are identical except the file for the stacked FITS has a different date/time, the number of stacked frames and the total exposure time - so no difefrence in the core FITS spec apparently - RAW, 16bit, pixels, binning
      Questions:
      Am I breaking process and so totally irrecoverable ? (i.e. Lights must be individual FITS or pay for Pro and do darks first and include on the fly when capturing Lights)
      or  are there some options to set in DSS or other stackers to use ?
      I have several nights and long hours of careful capture. My lights show weird hot pixel trails so I need the darks or I'm stuffed and have wasted my time - true ?
      Any takers ?
      Thanks


    • By skybadger
      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. 
       
       
    • By SteveBz
      Hi Guys,
      I've been guiding with a QHY5L-iim/OAG setup for the last year or so.  I can nearly always expect to find a guide star in any frame I GOTO, however there have been a few cases when that has not been true and my sequence has failed.
      Recently an unexpected storm drenched all my electronics including the QHY5L-iim, which doesn't appear to have recovered.  So I now need to replace it.
      The question is, do I chose another QHY5L-iim, and maybe increase the exposure time for some frames from 1s to 3s, for instance, or should I choose a ZWO ASI290mm-s?  It seems a bit more sensitive, although the chip seems a littler smaller.  What are your thoughts?
      Thanks
      Steve.
×
×
  • 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.