Jump to content

sgl_imaging_challenge_2021_annual.thumb.jpg.3fc34f695a81b16210333189a3162ac7.jpg

Script to make Stellarium easier to use with EQMOD


Recommended Posts

I have worked up a script to make it easier to use Stellarium with EQMOD. At the moment, issuing a commands to EQMOD from Stellarium requires one to press the CTRL key and a number key, specifically CTRL-1 to slew to the selected target, CTRL-3 to Sync to the current target and CTRL-5 to cancel the slew. I find this rather inconvenient when working in the dark, on a small notebook keypad and with gloves on.

It is believed that in forthcoming versions of Stellarium (e.g. v0.12.x) it will be possible to re-map the telescope control keys. Even so, I'd prefer to use my wireless game pad for the job, as it has chunky buttons, is portable and already works with EQMOD to control scope pointing and other functions. About a year ago I read somewhere that a free utility called AutoHotkey can be used to assist with this, so I bookmarked the download page, but never took it any further (and can't find the original source of the info amongst my many bookmarks).

Finally I got round to working on the issue, and here is my solution:

You will need the following:

- A working installation of EQMOD, StellariumScope and Stellarium.

- A compatible gamepad, joystick or similar controller. Test this in EQMOD first under the game pad configuration screen.

- Download and install a copy of AutoHotkey from http://www.autohotkey.com/ .

The AutoHotkey installation is pretty simple, just follow the instructions. Now you need to create your Stellarium AutoHotkey script. To do this:

1. Open NotePad.

2. Cut and paste the script below in to NotePad.

3. Save the file somewhere convenient (e.g. the desktop). Make sure you give the file name the extension .ahk and not the default .txt that NotePad suggests. This will ensure that the script launches AutoHotkey when you double click it, and it also adds an 'edit script' option to the Windows right-click context menu which makes life a bit easier when debugging.

4. Plug in or switch on your game pad/controller. The script will auto-detect the first joystick/controller and use that one, or pop up an error and quit if it can't find a controller. (See below in configuration for help if this happens).

5. Double click the script file and AutoHotkey should launch and put a small 'H' icon in the system tray at the bottom right of the screen to show this script is running. You can right-click the system tray icon to pause or stop the script, or to re-load it from the file if you have edited it during testing.

6. If you get any errors at this point, make sure you have pasted the script exactly as shown below!

All the configurable values are in the CONFIGURATION section of the script. Here are the things you may want to change:

- StellariumWindow holds the window title of Stellarium. The default setting should match any version, but if the window title changes in future, just edit this value. You can either use the whole window title or just some text from the start. Make sure the text doesn't match multiple windows (e.g. StellariumScope might clash if you only used the first few letters).

- JoystickNumber is set to 0 by default, which means "search all controllers and use the first one you find". If you have several controllers connected, you can set this value to the specific controller number (between 1 and 16) and the script will use that one.

- SlewButton / SyncButton / CancelButton hold the button names to activate each of the three functions. These will be in the format of Joy<n> where <n> is a number between 1 and 32. To find out which button is which on your controller, download the joystick test script here (http://www.autohotke...oystickTest.htm) and run it, but make sure you exit the Stellarium script first. A tool-tip will appear and update as you press the various keys on your controller so you can see which button is which. Again make sure you quit the joystick test script when done to avoid conflicts with the Stellarium AutoHotkey script.

IMPORTANT: Make sure you DO NOT use the SlewButton and SyncButton in the EQMOD game pad configuration screen. If you do, you may find EQMOD ends up doing two things at once, since (for controller keys), AutoHotkey activates its script AND passes the controller button press through to any other application that is waiting for it. Conversely, you may wish to map your chosen CancelButton to 'Emergency Stop' in EQMOD. This will ensure that the mount stops (and parks in the current position) even if your script, AutoHotkey or Stellarium/StellariumScope fails for some reason. Safety first.

See below for an example of how I have configured the EQMOD game pad screen for my XBox wireless controller:

post-18840-0-04114100-1362932023_thumb.p

I'd also recommend turning on 'Append on Sync' in EQMOD to add alignment points to the pointing model as you go.

- SlewKeys / SyncKeys / CancelKeys hold the keystrokes to sent to Stellarium when you press the appropriate controller button. These are set to the current CTRL-1, CTRL-3, CTRL-5 defaults. If you change these defaults once key mapping becomes available in Stellarium, you'll need to change these values. Read the AutoHotkey documentation online for details of how to send keystrokes.

The default script is set up for an XBox wireless controller, and uses the Blue ( X ) key to initiate a slew, the Yellow ( Y ) key to do a sync and the Red ( B ) key for cancel in Stellarium AND ALSO emergency stop in EQMOD. Change these to suit your own needs.


; Stellarium AutoHotkey script for Windows
; V1.0b 2012-03-09 - Ian Lauwerys.
; Joystick detection code taken from the AHK joystick test script.
;
; Go to http://www.autohotkey.com/ to download AutoHotkey.
; Create a text file containing this script (using notepad).
; Save it with the .ahk file extension (not .txt).
; Double click script to launch AutoHotkey and activate script.
;
; You will also need the following software (but I assume you knew that anyway!):
;
; EQMOD - http://eq-mod.sourceforge.net/
; Stellariumscope - http://www.welshdragoncomputing.ca/index.php?option=com_content&view=category&layout=blog&id=31&Itemid=39
; Stellarium - http://www.stellarium.org/
;
; This script assumes you are using the default key mappings in Stellarium/StellariumScope.
; As of V12.0 of Stellarium ; it is possible to remap keys so if you change the Slew,
; Sync or Cancel key mappings you need to update the configuration section below.

; ------------------ CONFIGURATION SECTION -------------------

; ** Configure the title of the Stellarium window. **
; ** Needs the trailing space to avoid matching StellariumScope **
StellariumWindow := "Stellarium "

; ** To autodetect and use the first joystick, set to 0 . **
; ** To use a specific joystick, set to a value between 1 - 16 . **
JoystickNumber := 0

; ** Configure joystick buttons (Joy1 through Joy32) to perform the required actions. **
; ** Download and run http://www.autohotkey.com/docs/scripts/JoystickTest.htm **
; ** to identify the key numbers for your joystick or contoller. **

; Joy3 (XBox Blue/X) for Slew.
; It is recommended that you do not map this button to anything in EQMOD.
SlewButton = Joy3

; Joy4 (XBox Yellow/Y) for Sync.
; It is recommended that you do not map this button to anything in EQMOD.
SyncButton = Joy4

; Joy 2 (XBox Red/B) for Cancel.
; It is recommeded that you map this button to 'Emergency Stop' in EQMOD for safety
; as AutoHotkey will pass controller buttons through.
CancelButton = Joy2

; ** Configure the keystrokes to send to Stellarium. **
; ** Change these if you remap keys in Stellarium V12.0 or later. **

; Send ctrl-1 to Stellarium (Slew).
SlewKeys = ^1

; Send ctrl-3 to Stellarium (Sync).
SyncKeys = ^3

; Send ctrl-5 to Stellarium (Cancel).
CancelKeys = ^5

; -------------- END OF CONFIGURATION SECTION ----------------

; ------------------ INITIALISATION SECTION ------------------

; Set hotkey variables.
If JoystickNumber = 0
{
JoystickNumber := DetectJoystick()
}

SlewHK = %JoystickNumber%%SlewButton%
SyncHK = %JoystickNumber%%SyncButton%
CancelHK = %JoystickNumber%%CancelButton%

; Set to match WinTitle "starting with string".
SetTitleMatchMode, 1

; Define hotkeys based on variables, will goto specified labels when pressed.
Hotkey, %SlewHK%, Slew
Hotkey, %SyncHK%, Sync
Hotkey, %CancelHK%, Cancel
return

; -------------- END OF INITIALISATION SECTION ----------------

; ------------------------- FUNCTIONS -------------------------

; Auto-detect the joystick number.
DetectJoystick()
{
Loop 16 ; Query each joystick number to find out which ones exist.
{
GetKeyState, JoyName, %A_Index%JoyName
if JoyName <>
{
TempJoystickNumber = %A_Index%
break
}
}
if TempJoystickNumber <= 0
{
MsgBox The system does not appear to have any joysticks.
ExitApp
}
return TempJoystickNumber
}

; --------------------- END OF FUNCTIONS ----------------------

; ---------------------- HOTKEY ACTIONS -----------------------

; Make Stellarium issue a Slew to selected target command to EQMOD.
Slew:
IfWinExist, %StellariumWindow%
{
WinActivate
SendInput %SlewKeys%
}
return

; Make Stellarium issue a Sync to EQMOD.
Sync:
IfWinExist, %StellariumWindow%
{
WinActivate
SendInput %SyncKeys%
}
return

; Make Stellarium issue a Cancel to EQMOD (stop current slew).
Cancel:
IfWinExist, %StellariumWindow%
{
WinActivate
SendInput %CancelKeys%
}
return

; ----------------- END OF HOTKEY ACTIONS ---------------------
Edited by IanL
Link to post
Share on other sites

You don't really need the script to handle stop and sync as you can already assign gamepad buttons within EQMOD to those functions (the sync requires a double tap to prevent accidental syncs). Neat way to trigger the slew though!

Chris.

Link to post
Share on other sites

You don't really need the script to handle stop and sync as you can already assign gamepad buttons within EQMOD to those functions (the sync requires a double tap to prevent accidental syncs). Neat way to trigger the slew though!

Chris,

I've not dived in to the innards of ASCOM other than a few of the pulse guide commands when I made my hombrew autoguider for the LX10 mount a while ago:

- If emergency stop is hit in EQMOD, I assume from what you say that Stellarium will know the mount has stopped and not end up confused. It just seemed neater to my mind to have the software that originated the slew command also initiate the cancel, but looks unnecessary if using a controller to do the job.

- Ditto with the sync; again if sync is triggered in EQMOD is that the same as doing it in Stellarium? What does the Sync process do anyway? I guessed that the mount driver would calculate the current RA and Dec based on the encoder values, (or maye hold Alt/Az which it could transform to/from RA/Dec based on time/site info). When an application does a sync it tells the mount driver that it is actually pointing at some different RA and Dec, causing the mount driver to adjust the encoder to pointing position transformation (and in EQMOD also the pointing model if append on sync is selected). So that led me to assume that the application has to initiate the sync, not the mount driver. I mean what happens if you have two applications connected to the mount driver (say Stellarium and AstroTortilla)? They may have different ideas about where the scope is really pointing, which is fine if the application is sending the sync data since you the user has to decide which application is right. If the mount driver initiates the sync process, how does it decide which application should respond, or if they all respond, how does it mediate between different values being sent by different applications? Lot's of assumptions based on no information, kind of my job description in real life to be honest!

Anyway I digress. You can amend the script easily enough to remove the mapping of unwanted commands. Also, in response to your original plea about ctrl-1, etc. you could just use AutoHotkey to replace these with more useful key cominations. Again this may not be needed in the V0.12.x of Stelarium if native keymapping works and we move beyond beta support in StellariumScope, but in the meantime here is an (UNTESTED) example using the F1, F2, F3 keys (slightly more verbose than it needs to be, but I am keeping the separation between configuration and code for ease of comparison):


; Stellarium AutoHotkey script for Windows
; V1.1b 2012-03-11 - Ian Lauwerys.
;
; Go to http://www.autohotkey.com/ to download AutoHotkey.
; Create a text file containing this script (using notepad).
; Save it with the .ahk file extension (not .txt).
; Double click script to launch AutoHotkey and activate script.
;
; You will also need the following software (but I assume you knew that anyway!):
;
; EQMOD - http://eq-mod.sourceforge.net/
; Stellariumscope - http://www.welshdragoncomputing.ca/index.php?option=com_content&view=category&layout=blog&id=31&Itemid=39
; Stellarium - http://www.stellarium.org/
;
; This script assumes you are using the default key mappings in Stellarium/StellariumScope.
; As of V12.0 of Stellarium ; it is possible to remap keys so if you change the Slew,
; Sync or Cancel key mappings you need to update the configuration section below.

; ------------------ CONFIGURATION SECTION -------------------

; ** Configure the title of the Stellarium window. **
; ** Needs the trailing space to avoid matching StellariumScope **
StellariumWindow := "Stellarium "

; ** Configure keys to perform the required actions. **
; ** Got to http://www.autohotkey.com/docs/KeyList.htm for a list of key codes. **

; F1 for Slew.
SlewButton = F1

; F2 for Sync.
SyncButton = F2

; F3 for Cancel.
CancelButton = F3

; ** Configure the keystrokes to send to Stellarium. **
; ** Change these if you remap keys in Stellarium V12.0 or later. **

; Send ctrl-1 to Stellarium (Slew).
SlewKeys = ^1

; Send ctrl-3 to Stellarium (Sync).
SyncKeys = ^3

; Send ctrl-5 to Stellarium (Cancel).
CancelKeys = ^5

; -------------- END OF CONFIGURATION SECTION ----------------

; ------------------ INITIALISATION SECTION ------------------
SlewHK = %SlewButton%
SyncHK = %SyncButton%
CancelHK = %CancelButton%

; Set to match WinTitle "starting with string".
SetTitleMatchMode, 1

; Define hotkeys based on variables, will goto specified labels when pressed.
Hotkey, %SlewHK%, Slew
Hotkey, %SyncHK%, Sync
Hotkey, %CancelHK%, Cancel
return

; -------------- END OF INITIALISATION SECTION ----------------

; ---------------------- HOTKEY ACTIONS -----------------------

; Make Stellarium issue a Slew to selected target command to EQMOD.
Slew:
IfWinExist, %StellariumWindow%
{
WinActivate
SendInput %SlewKeys%
}
return

; Make Stellarium issue a Sync to EQMOD.
Sync:
IfWinExist, %StellariumWindow%
{
WinActivate
SendInput %SyncKeys%
}
return

; Make Stellarium issue a Cancel to EQMOD (stop current slew).
Cancel:
IfWinExist, %StellariumWindow%
{
WinActivate
SendInput %CancelKeys%
}
return

; ----------------- END OF HOTKEY ACTIONS ---------------------
Edited by IanL
Link to post
Share on other sites

- If emergency stop is hit in EQMOD, I assume from what you say that Stellarium will know the mount has stopped and not end up confused. It just seemed neater to my mind to have the software that originated the slew command also initiate the cancel, but looks unnecessary if using a controller to do the job.

Stellarium doesn't really know much of what is going on with the mount - it just polls out for the mounts current RA/DEC coords. So if the mount stops because some one hits the emergecy stop button on EQMOD, or a gamepad or indeed if any other ASCOM client software then the telescope reticule in stellarium will remain at th estopped position.

- Ditto with the sync; again if sync is triggered in EQMOD is that the same as doing it in Stellarium? What does the Sync process do anyway? I guessed that the mount driver would calculate the current RA and Dec based on the encoder values, (or maye hold Alt/Az which it could transform to/from RA/Dec based on time/site info). When an application does a sync it tells the mount driver that it is actually pointing at some different RA and Dec, causing the mount driver to adjust the encoder to pointing position transformation (and in EQMOD also the pointing model if append on sync is selected). So that led me to assume that the application has to initiate the sync, not the mount driver. I mean what happens if you have two applications connected to the mount driver (say Stellarium and AstroTortilla)? They may have different ideas about where the scope is really pointing, which is fine if the application is sending the sync data since you the user has to decide which application is right. If the mount driver initiates the sync process, how does it decide which application should respond, or if they all respond, how does it mediate between different values being sent by different applications? Lot's of assumptions based on no information, kind of my job description in real life to be honest!

Again stellarium is quite dumb when is comes to provding a sync - in fact it has no idea it is even doing it!. The only mount control action stellearium currently ,has is to issue gotos so when the sync ctrl key is pressed stellarium initiates a virtual telescope goto to the objects coordinate. Stellariumscope recieves this goto and issues a sync to EQASCOM using the goto coordinates as the sync point. The cancel/stop is te same, stellarium issues a goto but to another vitual scope that stellariumscope intercepts and issues the ASCOM stop.

A sync simply tells you the coordinates of where you are right now and when you think about it EQASCOM is already aware of that - the coordinates of the last received goto are the sync point!. So whenever you issue a goto EQASCOM makes a mental note of where you aked it to go - you then do what you must to centre the sync point in an eyepeice and should you hit the gamepad sync button (twice in faily rapid sucession) eqascom issues a sync to itself using the last goto coordinates.

When a sync is made, no matter who initiates it, eqascom's pointing model is modified/shifted and as a consequence the currently reported RA/DEC coords will change slightly. All connected applications will pick up this change as soon as they next poll eqascom. There is never any questions of EQASCOM serving up different data to different applications. Also catalogue positions used for sync points / goto targets should be identical across all applications provided they have bben setup to use the same epoch (which you would want to be doing anyhow).

Chris.

  • Like 2
Link to post
Share on other sites
  • 4 months later...

This is really interesting! I think I'll stop syncing with Stellarium because it is p***ing me off...

It never syncs back to the star.

But, if you sync EQMOD, who tells Stellarium?

Link to post
Share on other sites

But, if you sync EQMOD, who tells Stellarium?

A sync will act to change where EQASCOM reports the mount is. When stellarium polls to read the current mount RA/DEC coords the sync will have caused them to change and stellarium will draw the mount reticule at the mew position. In this respect Stellarium can't distinguish between a sync having occurred or a manual slew by the user - but it doesn't need to. Just keep in mind that stellarium is little more than a glorified catalog with a pretty front end - it really knows nothing of mount control.

Chris.

Link to post
Share on other sites
  • 2 months later...

Guys, I did a search for Stellearium telescope control and this was one of the threads that google threw up.  What puzzles me is most of the other software that is free (C2A, CDC etc) support the ASCOM platform and have the same sort of menu options by right clicking on a target to slew and sync.  Whilst I can understand that Stellariums developers may not have the time, internet connection speed or the other reasons for not being able to develop the application to support the ASCOM platform, given it's popularity I would of thought that this would of been added by now.  Reading some of the posts and discussions Chris has already commented how to use sockets to something, and even offered to collaborate or develop a suitable plug-in or telescope interface.  Could I suggest to the developers that they seriously consider adding ASCOM support as a priority, and if time, effort or slow PC's are the issue, then maybe Chris could assist...??

In the meantime I'll continue to use CDC until this issue with Stellarium is resolved.

Link to post
Share on other sites

Guys, I did a search for Stellearium telescope control and this was one of the threads that google threw up.  What puzzles me is most of the other software that is free (C2A, CDC etc) support the ASCOM platform and have the same sort of menu options by right clicking on a target to slew and sync.  Whilst I can understand that Stellariums developers may not have the time, internet connection speed or the other reasons for not being able to develop the application to support the ASCOM platform, given it's popularity I would of thought that this would of been added by now.  Reading some of the posts and discussions Chris has already commented how to use sockets to something, and even offered to collaborate or develop a suitable plug-in or telescope interface.  Could I suggest to the developers that they seriously consider adding ASCOM support as a priority, and if time, effort or slow PC's are the issue, then maybe Chris could assist...??

In the meantime I'll continue to use CDC until this issue with Stellarium is resolved.

I think it is worth bearing in mind a few things:

- Stellarium is a planetarium first and foremost.  The fact that it has some very basic telescope support is great, but as far as I can see it was never intended to be a telescope control application and I doubt that the current developers have the time and resource to get involved in the difficulties of trying to support advanced telescope control.  The current way it is done is very simplistic (go to coordinate command for each telescope, hence the need for StellariumScope to pretend to be three different scopes so it can do slew, sync, stop).

- It is a cross-platform development with support for Windows, Mac and Linux.  ASCOM is a Windows-only offering (necessarily so).  I would guess it would be difficult/impossible for them to build ASCOM support directly in to the product without forking it in to several versions for different platforms.  I haven't looked at the way plugins are developed and I don't know if ASCOM could be built in to a plugin or not.  I suspect not since StellariumScope is a separate application and if it was easy to build an ASCOM plugin I guess that is what would have been done instead.

- That said the combination of Stellarium and StellariumScope works flawlessly, and the only bugbear is the inability to change key mappings for scope control in Stellarium itself.  This was rumoured to be a new feature in an upcoming version, but I haven't checked to see if it is possible yet.  Using AutoHotKey is a bit of a cheat to allow this in lieu of such a feature.  Even if they do add key mapping, I doubt they will add support for GamePads, etc. as that is (again) a Windows Platform specific issue.  (By way of analogy Stellarium uses cross-plaform OpenGL for graphics rather than DirectX which is Windows-only so not going to be built in for the same reasons as above, and control of gamepads faces a similar issue in Windows).

- I think the killer point that one of the developers made when someone else was saying 'why don't you do xyx..???' was that this is an open source project.  If you have the development skills and want to contribute, jump in and help out, but they are reliant on a handful of people with limited time to contribute and all the theorising in the world about how great it would be to do x or how obviously dumb it is not to support y doesn't really help them move it on.

Personally I am grateful for such a great free piece of software, I have neither the time nor the specific skills to help (I can hack my way around in HTML and JavaScript quite well for someone from the pre-windows/pre-web era of software development, but heavyweight graphics applications are not something I could tackle).  Thus I am willing to accept what I am given; unless you've ever done serious software development it is hard to appreciate just how much time and effort it takes to build and test even simple features in a large application like this whilst ensuring a decent level of quality.  I manage two teams of developers who write far less complex software for a living and it is extremely hard to get acceptable good stuff out of the door in a timely manner, never mind a bunch of people doing it in their spare time for goodwill only and scattered across several continents.

Edited by IanL
Link to post
Share on other sites

Don't get me wrong, I think the developers are doing a grand job, and whilst the application may well of been a planetarium program in concept, which it does very well, it does seem left behind given that goto telescopes have been around for many years now and other free apps of this type integrate with a recognised control platform to provide telescope control.  I appreciate that it may be a difficult task, and if I had the knowledge to program in windows I would be first to be offering my assistance, but sadly my programming skills are somewhat limited and not in this field.

As for cross platform, well I guess that if the developers did offer an Ascom interface there would be those on Linux who would want the same under INDI, and probably Mac uses after whatever "standard" runs native on the mac OS.... maybe this is why no direct support for telescope control from within the application has been undertaken.

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 Nikolas74
      Since I live in a flat I do most of my imaging from my balcony... I purposely choose a top floor because of my astrophotography passion in order to have a decent field of view, but my balcony has walls on one side and on top. 
      So I decided to bring to Stellarium my own landscape and my FOV so I can know exactly which targets are on sight and at what time. 
      I have done some reading and watch videos but I still have a couple of questions before I begin and hopefully some people from here could help! 
      a) how should I take my photo... Me standing straight levelled with horizon or placing my camera on a tripod and place it like a telescope looking up in the sky towards North? 
      b) the famous cardinal points and the line angle_rotatez= in the ini file... Is there a secret of finding this number easy in order to match cardinal points to my photo or the only way is by trial and error....? 
      Thanks for reading
      Nikolas. 
    • By SStanford
      Hi All,
      I have a few questions regarding mount control using stellarium that I can't seem to find elsewhere. 
      I have an EQ3 pro with with Syscan (handcontrol) and a laptop with stellarium.
      The articles I've read refer either to EQMOD or ASCOM as a download requirement for Stellarium, is there any preference here for the EQ3?
      I'm also struggling to find details of the correct cable to connect the mount straight into the computer via USB (and which port recieves this in the mount).
      Thinking ahead, considering the requirement for the Guidscope and DSLR to be pugged into the computer, I will need to ensure this cable would be compatible with a "USB hub" (an area I havent done any research into yet). My computer has only 2 USB ports!
      S.
    • By Ade Turner
      I’ve just bought a Skywatcher EQ6-R Pro. I’m trying to drive it from Stellarium using EQMOD but I’m running into a problem I haven’t the experience to solve.
      This is my set up:
      Windows 7 Laptop > 10m active USB 3.0 cable > 4 port powered Atolla USB 3.0 hub > Lynx Astro EQMOD cable > Mount (plugged directly into hand control socket)
      When I first connected the mount to the laptop (a 2015 Dell Inspiron) Windows 7 searched for a serial/USB driver and installed it on COM 8 (according to Device Manager).
      In Stellarium I created a profile for the mount but it wouldn’t autodetect the COM port. So I manually set it to 8.
      When I try to connect to the mount it sits for a while and then tells me the connection has timed out.
      Anyone have any suggestions as to where I should start to try and get the connection sorted please? Thanks.
    • By gstallichet
      I just bought a Celestron 8se.  Which planetarium/scope control software do you recommend, Stellarium or Celestron's Starry Nights,  and why?
       
    • By pete_81
      Hi guys,
      With new mount and upgraded scope features, now looking to venture into imaging.
      Before I start, I'm not looking to get feedback on polar alignment, mono guidecam, better imaging cameras, etc; this is more a 'dummies guide' setup discussion! I'm not expecting to get great images at this stage, just more the options available, getting over some issues, so that I can jump outside on a clear night with an ideal, foolproof(!), setup for either imaging or visual as time would permit and what may work best for me. As you may guess from the topic name, I'm a mac user (Macbook Pro) and would rather keep to this if possible (whilst I do have Windows (and Ubuntu) via parallels, I'd rather not use these).
      I've got a setup which has worked well for visual, and obviously want to have a couple of 'staple' setups that I can use depending on expectations of night observing or imaging. So far, the best one for me has been the Skywatcher Wifi Synscan controller, which has worked a treat with my Android phone - I use the Synscan app to complete alignment and GOTO stars/planets/DSO etc, or Stellarium_plus after completing alignment. This removes the need for the Synscan Handset and any USB cables to the mount altogether. But I don't know if this will work for guiding.
      That then brings me to my issue on mac - connecting USB(A) between Macbook and Handset, I've attempted to control the mount through Stellarium. Trying each of the available connections (/dev/tty.usbsetial-1420, /dev/cu.usbsetial-1420, and just for sake of it, the /dev/tty.Bluetooth-Incoming-Port and /dev/cu.Bluetooth-Incoming-Port) in the dropdown menu under DeviceSettings/SerialPort, I cannot get the mount to connect (well, more like selecting the telescope and clicking the "Start" on the TelescopeControl just results in the spinning icon and I have to Force-Quit Stellarium and start again with the same result each time. Annoyingly (for fellow mac users!), Parallels/Windows/Stellarium connects and controls the mount fine! As the mount is the newer "pro" type, I also have a USB connection directly under the hand-controller RJ45 and AutoGuider ST4 sockets, but using this still results in the same issue. Another issue I have seen is that when I unplug the USB from the computer when connected to the handset, the date on the controller jumps significantly - for example, last night at ~23:30, I was transported through the local wormhole galaxy to Jan 2048 according to Synscan! Obviously unplugging isn't going to happen during a genuine session, but just wondering if this is a possible issue somewhere?!
      Any other mac users connecting USB directly to the SW 'Pro' mounts?
      Software wise, would folks generally suggest steering away from Stellarium towards KStars or SkySafari(Plus) for controlling the mount?
      Can the Wifi dongle be used for controlling mount from computer (any OS) or do I need to go USB either to handset or directly to mount?
      Is there an issue in using Mac USB to the telescope compared to 'straight' Windows (i.e. PC/laptop with Windows instead of virtual)?
      Anyway, back to topic... I've a Nikon DSLR to use for primary camera at this stage, which would be triggered independently from guiding software. PHD2 is my hopeful choice of guiding software (is EKOS with KStars similar?), with T7C guide-camera on 240mm f/4 guidescope, and at this stage, I can confirm PHD2 at least connects to the camera on OS-X. There is an ST4 port on the camera, but having read several topics, I think I want to pulse-guide directly - is this correct or is ST4 best for this setup? This sorta comes back to software and connections - my understanding is one of the following cable setups for guiding (as a minimum) :
      Guiding-camera => USB(A) => Macbook => PHD2 => USB(A) => SynscanHandset => AZEQ6
      Guiding-camera => USB(A) => Macbook => PHD2 => USB(A) => AZEQ6
      Guiding-camera => USB(A) => Macbook => PHD2 => Wifi => SynscaWifi Adapter on AZEQ6
      [using ST4: ST4_on_AZEQ6 => Guiding-camera => USB(A) => Macbook => PHD2] (no additional connections needed if ST4 is used)
      Additionally, I'd like to use an observatory package, say Stellarium/KStars/SkySafari, to select objects and drive the mount, then use guiding software to keep good 'tracking'.
      Where in this train does EQMac fit in, or when is it used?
      What about the 2019 addition to EQMod (ASCOM Alpaca)? Can this be used or is it already in other packages?!
      For Windows users, how does EQMod fit in (if I go down route of getting Windows laptop for controlling things, is the setup similar to above?
      There may be bits in the above that repeat, and for that, I'm sorry, just want to get across the message that I'm new to the guiding but haven't quite settled down into the software/hardware I'm expecting to use for 'goto' and 'guiding'
      TLDR:
      For a mac user, what setup and software are folks using for guiding and observatory softwares for the newer USB-on-mount 'AZEQ6/EQ6-R Pro' mounts from SW?
×
×
  • 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.