Jump to content

sgl_imaging_challenge_2021_annual.thumb.jpg.3fc34f695a81b16210333189a3162ac7.jpg

Recommended Posts

28 minutes ago, MarkAR said:

I wouldn't bother, ASCOM is Windows. You need to look at Astroberry or INDI.

This is not quite correct. ASCOM Alpaca does not require Windows nor does it need the original ASCOM framework to work. As a protocol I think it has a lot of potential, there is however very little support for it at present in terms of drivers and clients. Hopefully this will change...

  • Like 1
Link to post
Share on other sites

Yes, it was said that ASCOM Alpaca wouldn't be OS dependent. However, as far as I see the server module for Alpaca needs Windows + ASCOM framework to work.
ASCOM Alpaca client might work on non Windows OS, haven't tested that yet.
Looking forward for the server side also to be available on other OS.

 

@MarkAR I'll take a look into those, thanks for suggesting!

Edited by oyabuns
Spelling
  • Like 1
Link to post
Share on other sites
8 hours ago, oyabuns said:

Yes, it was said that ASCOM Alpaca wouldn't be OS dependent. However, as far as I see the server module for Alpaca needs Windows + ASCOM framework to work.

You only need the 'remote server'/'ASCOM remote' part if you want to use an existing Windows client (running on normal ASCOM) to connect to an Alpaca device driver (over the Alpaca API) or if you want an Alpaca client to connect to a regular ASCOM driver on a Windows machine. So it really only comes into play if you want to include some component running under the 'old style' ASCOM framework.

I think the arrows in the diagram are a bit misleading, you can remove the entire left hand side of the diagram and it will still work i.e. you could have an Alpaca client running on Linux connect to an Alpaca driver running on the Raspberry Pi. Not sure what the rules are on posting links to other forums but if you look on cloudy nights and search for a recent thread called 'Raspberry Pi and Alpaca' there is a guy who has just done that i.e. developed a Linux client and RPi drivers via the Alpaca API. I don't think it is released yet but it shows what can be done.

The problem at the moment of course is that there are very few (if any) Alpaca drivers and clients available at the moment. It's a bit of a chicken and egg situation and time will tell if it finds any traction... As has been said above, if you need something now (and you don't want to write your own drivers etc.) then its better to stick with the other suggestions. I also find the INDIGO framework to work quite well.

Edited by AngryDonkey
Link to post
Share on other sites

CCDCIEL allows the use of ASCOM/Alpaca and Indi connections at the same time.  CCDCIEL can and does run on Linux ,MacOS and Windows.

But as Angrydonkey says there are very very few Alpaca drivers so unless you run CCDCIEL on Linux/MacOS and use Ascom Remote on Windows to pick up any existing "Normal" Ascom driver there is not a lot you can do with it at the moment. You can also run CCDCIEL on Windows and use both Ascom locally and remote Indi server.

Link to post
Share on other sites

Indeed, alpaca is a rest web api specification that implements an interface to ascom, where the clients are typically windows ascom clients. However , if you want to write to an alpaca rest service hosted  on your Pi device, feel free, it will work seamlessly. The same if you want the client end to be on your Pi and the device interface on anything else. I have a family of alpaca compliant  devices coded at github/sky badger if you want to take a look. They are accessed from the ascom remote client running on the Windows server but also by many other non windows devices and are hosted on  esp2866 Wi-Fi devices. 

Link to post
Share on other sites

The real question should be, "Can an ASCOM server talk to an INDI server.  They are both TCP/IP XML message platforms.  Both ASCOM and INDI have provisions for distributed remote servers with one primary server.  I don't know the answer,  because I don't do Windows.  But it seems to me that if they don't do that yet, they should.  It should go both ways.  A primary INDI server should be able to talk to secondary ASCOM or INDI servers and likewise a primary ASCOM server should be able to talk to secondary INDI or ASCOM servers.  TCP/IP XML is common between both platforms.

The only reasons it may not be are that 1) Nobody thought of it yet, or 2) The XML specifications for the drivers have become too differentiated, or 3) The port for the two server types is different.  None of which are particularly difficult problems to solve with a bit of code   Even if things are completely mismatched, a simple socket program with a conversion between driver specifications could make it happen.

Since I don't see it happening, and since it makes sense to have a Pi on a telescope running an INDI server with perhaps a primary ASCOM server connecting to the human-interfacing programs, there has to be a catch I'm not seeing.  There was a project called wINDI that was reported to be an ASCOM->INDI bridge, but I don't know the status of it now.

 

Edited by JonCarleton
Link to post
Share on other sites
15 hours ago, JonCarleton said:

The real question should be, "Can an ASCOM server talk to an INDI server.

To me, the questions are, "Do Alpaca drivers work with ASCOM on Windows machines, and are vendors going to provide universal Alpaca drivers rather than ASCOM-specific drivers going forward?" If separate ASCOM and Alpaca drivers are required for Windows vs. non-Windows platforms, I don't foresee many manufacturers putting money into development of the latter.

I watched a YouTube presentation about Alpaca given by Bob Denny a few months ago. It looks interesting, but it wasn't clear to me if Alpaca drivers work in the Windows environment. If not, I doubt that there's much future for it -- hardware suppliers will continue to cater to the ASCOM market and for those of us who don't live in Windows land, there's no obvious benefit over INDI.

Link to post
Share on other sites

I got this working with Alpaca Server on my RPi4b running Raspbian (set up initially with AstroPi3) so I could use the Pi on my scope and connect to it from Windows i.e. my laptop, using APT, PHD2. I managed to get it working but it proved a bit flakey so I've gone back to running the scope and capture on the RPi  and VNC into it. The trouble with using INDI or ALPACA servers is you then have two points of failure, the server and the client. I prefer it all to run on the same machine, whether laptop or RPi so if it doesn't work I have can simply replace with a laptop or the pi and continue imaging. 

Link to post
Share on other sites
16 hours ago, JonCarleton said:

Can an ASCOM server talk to an INDI server.

Although the comms protocols might be similar, the fundamental philosophies behind each framework are quite different which will reduce compatibility e.g. ASCOM implements a fairly strict interface whereas INDI is a lot more free form. Also the way messages flow push/poll is different. I'm sure it could be done somehow (the now retired wIndi server did expose ASCOM devices to INDI I believe) but I'm not sure the benefits would outweigh the potential issues of working across two frameworks.

1 hour ago, MCinAZ said:

"Do Alpaca drivers work with ASCOM on Windows machines, and are vendors going to provide universal Alpaca drivers rather than ASCOM-specific drivers going forward?"

Drivers need to be written for a specific system (Windows/Linux) so the Vendor will still need to write two drivers if targeting both Windows and Linux. For Windows however the 'normal' ASCOM driver can be exposed over Alpaca so it doesn't need a separate 'Windows Alpaca' driver. Not sure if Vendors will buy into this but there is certainly a market for RPi based devices at the scope end.

Link to post
Share on other sites

I need to look into Alpaca.  I really am not familiar enough with the project to speak with any authority on it.  Then too, I'm perfectly happy with INDI, and "I don't do Windows."

Data conversion for dissimilar enterprise systems was my area before I retired, so I know it could be done.  The real question is then, should it?  The notion of an additional point of potential failure is certainly valid.  I do see the value of running a Windows desktop with a Pi running the scope, especially when there is any real distance between the two.  In my case, I am basically doing the same thing under Linux....Linux desktop, Pi/Linux at the scope, so the conversion issue does not come into play.

 

Link to post
Share on other sites

I'm potentially interested in ALPACA but still trying to understand what components are needed to make this work on a completely Windows-free setup.

Let's say I want to control a filterwheel. I write a client program, look up the JSON semantics for this device, and send the necessary JSON to an ALPACA server. So far so good. But then what?

In the Windows case it is pretty clear that it converts the JSON into something ASCOM-compliant and sends the request to the device. End of story. I can see how this would work easily enough, and I can see that controlling ASCOM-compliant devices hooked up to a Windows box from any other device is pretty trivial. And it is trivial because all the drivers already exist, as does the ALPACA-ASCOM server. 

But this isn't my case. As I see it, for a non-Windows setup much of what is needed to get this to work (ALPACA server + drivers) isn't currently available and I'm not even clear whether it is being developed. It would be wonderful to have a truly OS-independent way to access devices, but is it going to happen?

Am I missing something?

Martin

Edited by Martin Meredith
Link to post
Share on other sites

People might find this YouTube video of Bob Denny (one of the Ascom/Alpaca driving forces) useful - especially if you know nothing about Ascom or Alpaca.

https://www.youtube.com/watch?v=Qd1ZsJ_Q1XY

Its a while since I watched it, but I think the essence is that Alpaca is not really there yet... And whether it ever will be is moot - it may get somewhere, but will never have complete cross platform support.

At the moment I think INDI is the only complete cross platform that actually works. INDIGO is good if you want to use Cloudmakers apps, and it also falls back to INDI too but there's not much in the the way of third party clients.

Callum

 

Edited by callump
Link to post
Share on other sites
1 minute ago, callump said:

INDI is the only complete cross platform that actually works.

Indi (and we are really talking Indilib here) is NOT a cross platform - there is no Indiserver running on Windows. The one created by Indigo authors is not supported any more. The only mainstream program that runs on any platform (Windows/Linux/Apple) is CDC and CCDCIEL but they are NOT Indiserver (i.e. a server) just have the client capabilities to talk to Ascom (via Ascom remote when not on Windows),Native Alpaca or Indi and sometimes both at the same time when run from Windows.

Indi and Ascom are just a standards for messages formats, message handling  and standardised driver functionality.

You could (but would you really even bother) write an Indi/Ascom two way converter - not forgetting the overhead.

Robert Brown showed the way for Ascom ,IMHO, with his Focuser that has a TCP/IP interface in his Ascom driver. So too Sky watcher - there App/Ascom Driver enables you to run the App/Ascom Driver on another Windows "box" (with Ascom loaded of course).

For ALL Ascom drivers that use "COM" you have been able to have a Ascom remote device on any OS using "COM" to Network modules such as SER2NET (LINUX) and the Virtual Com emulators / Com port redirectors (some free some not). Using this method ASCOM is totally unaware and the "only" problem is that of timing.

I guess ,unlike Indi, Ascom is stuck with waiting for hardware manufacturer's  producing native drivers for Alpaca on other O/S . Thats where Indi is strongest but still has its limitations as stated - lack of "true" Indiserver on Windows.

Thats my take -  no doubt others will have there POV's

 

Link to post
Share on other sites
2 hours ago, stash_old said:

Indi (and we are really talking Indilib here) is NOT a cross platform - there is no Indiserver running on Windows.

Sorry, yes you are right (though I am sure when I last looked for one there was - but that may be several years ago).

I guess more accurate to say client neutral.

I expect  most INDI users use some sort of appliance on the telescope, and whatever client platform of preference. 
Alpaca will no doubt provide a practical similar solution some time in the future...

Callum

  • Like 1
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 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 skybadger
      Hi all 
      I'm prepping to write my own ascom safety driver , principally driven by weather conditions with some dome signals included. It's generally used to interrupt a dome observing session and close up if necessary, say due to some device failing or it starting to rain. Anyone done this already ? I'm interested in your logic approach and what you thought was important. 
      I'll be using node red to host the driver in alpaca , that bit is already done actually. So I just need to work out a robust approach to combining the inputs to make a sensible output. 
      My inputs consist of weather sensors like a Sqm, all sky camera, sky temp sensor, rain and wind sensor, device connection  probes, power sensors etc and there is clearly a dependency on day/night, automated operation or manned and what is advisory and what you might consider mandatory. 
      The output is a single binary isSafe = yes or no. 
      What are your thoughts ? 
       
       
       
    • By pete_81
      Hi all, just getting straight to the point.
      Just got a Rasp Pi 400 (equivalent to Pi4-4GB), and looking to get into guiding through this as it's obviously a popular (and successful) technique.
      Plan is to have the RPi as mini computer at home, running it with RaspPiOS (supplied on µSD with the full kit), then use it with a SECOND micro SD card for astro - I figure having another SD to run Astroberry (as on SGL) may ignore any issues with the family using the pi for other stuff in the house, giving a stand-alone 'computer' as the OS and files would be available on different SD's.
      From this point, I'd setup as follows:
      Connect the RPi directly via USB to the mount (it's the newer SW-AZ-EQ6Pro with the USB-B port on the mount)
      Guidescope (240mm f/4) with T7C (equivalent to ZWO Mini) again USB-B direct to RPi
      Nikon DSLR (either on telescope or using camera lenses) connected to RPi via Nikon USB (using the 3 USB points on the RPi-400) to control capture and later using this for plate-solving (but that's not for just right now!)
      I don't spy any flaws in the plan, it's just going to be a matter of testing and setting things up hoping to follow the guide for Astroberry as linked to SGL below...
      Or is there an alternative OS? From brief reading, Astroberry includes KStars & PHD2 which is what I've got for use on the macbook (although not used in earnest as it doesn't appear to like the cold too much!)
      What about guiding software - I know KStars comes with it's own, and can run PHD2 from within, with PHD2 being the industry standard (and simplest?) to use?
      Control will then be sitting in the warm via OS-X, which seems to be again a common technique as I've had posts on my other questions about this!
      Thoughts???
    • By stargamed
      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!
    • By autonm
      I made a new video - which walks through the downloading, installing and setup of AstroBerry (astronomy software running on Raspberry Pi) - and then I connect to an HEQ5 and DSLR camera. Nothing to complicated - but its the basics covered.
      There are a lot of videos out there on using AstroBerry, but not too may walkthroughs on the actual setup. Although Rp and Ab should be simple theres a lot of questions out there just on the setup.
      Hopefully the video gives people confidence on the first steps and is enough to get them going.
      https://youtu.be/Bgn3KioAAJ0
      Many Thanks - clear skies & if the video is helpful please subscribe.
×
×
  • 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.