Using Stellarium to Control your Mount with a Mac - SOLUTION

[Neil McRae]

I had a problem using windows vista and stellarium. I had EQMOD and ASCOM drivers installed and EQMOD and Cartes du Ciel worked but Stellarium would not.

Got advice from another forum to load "Stellarium Scope" software (free download) and today got it all up and running without any problems. The documentation with it is pretty good. Can be found at WWW.welshdragoncomputing.ca

Neil

[vulcan]

Glad to hear you got it sorted obs30. I am adding a link to this thread on the Mac AStronomy Group as it may prove useful to others.

[NickK]

Ok, I have two R232 usb-serial devices connected - one Prolific (the EQDIR) and one FTDI which is an active robotics interface.

Using Kermit I can see that the FTDI works - with loop back by connecting the RX & TX pins. I can get the FTDI and Prolific talking - ie you can talk between the two kermit sessions - so those are both working fine and the respective drivers are fine.

Using Windows 7 in VM I can get ASCOM controlling the mount using the same EQDIR without a problem. However if I try running stellarium connecting using either the EQDIR or the FTDI board to the mount I get nothing.

This doesn't seem to be a driver issue or a kit issue - probably stellarium or the protocol it's attempting to use to control the mount.

[Digz]

Glad its all sorted obs30

@Neil, stellarium scope looks like a good plugin but its not needed for Mac users

@Nick, half of what you say goes straight over my head (by some way, lol) but can you explain why you are using EQDIR to connect your mount to Stellarium?

[chrisshillito]

This doesn't seem to be a driver issue or a kit issue - probably stellarium or the protocol it's attempting to use to control the mount.

Synta mounts talk their own proprietary protocol which I don't believe Stellarium, or its telescope driver plugin, know nothing about. You can of course use celestron/nexstar protocol but only if go via a synscan (which acts as a protocol convertor).

The only driver that I know of that provides a comprehensive implementation of the native Synta protocol is EQMOD but of course this is an ASCOM driver and runs under windows. Whilst Stellarium itself doesn't support ASCOM drivers (well it didn't last time I checked) those wishing to use EQMOD (or indeed any ASCOM driver) can use stellarium scope as means to link Stellarium to ASCOM driver functions.

Chris

[NickK]

Synta mounts talk their own proprietary protocol which I don't believe Stellarium, or its telescope driver plugin, know nothing about. You can of course use celestron/nexstar protocol but only if go via a synscan (which acts as a protocol convertor).

I had a quick look at the EQDIR sources - I need some additional time but I think you're correct.

[obs30]

Glad to hear you got it sorted obs30. I am adding a link to this thread on the Mac AStronomy Group as it may prove useful to others.

Very good idea! Thank you.

Actually, I also have Win7-64bit installed as bootcamp and it can be started as a VM using Parallels. The usb-to-serial adapter is recognized, but the original Win7 drivers for the PL2303 are not accepted by Win7. ... So I am indeed very happy that the Mac OS X works

[chrisshillito]

I had a quick look at the EQDIR sources - I need some additional time but I think you're correct.

Hi Nick,

I wouldn't waste time looking for details of the Synta protocol within the open source EQMOD code. Synta protocol handling is abstacted to a "closed source" dll.

Chris.

[NickK]

The EQDIR source tree does only provide DLLs and their function declarations - that's obvious however buried in the tree is also the original GNU firmware and serial code which gives the protocol - it also handles a subset of the meade protocol.

If Synta or EQDIR have moved away from this then it's still possible to loop the serial traffic from the handset through one serial->usb device, through a sniffer/logging application and back out to another usb->serial device to the mount.

[NickK]

Very good idea! Thank you.

Actually, I also have Win7-64bit installed as bootcamp and it can be started as a VM using Parallels. The usb-to-serial adapter is recognized, but the original Win7 drivers for the PL2303 are not accepted by Win7. ... So I am indeed very happy that the Mac OS X works

It's because the driver is written for kernel address space - this means that it has to match it's address sizing. Hence if you attempted a 32bit driver in a 64bit address space which is more hassle than it's worth (the 32 bit driver can't reference the hardware/resources that are mapped outside the 32 bit range).

A twisted analogy is like looking though a 4000mm fl at the moon and then you can't get all the moon in the EP (32bit=normal field) at the same time at that resolution (64bit=mega wide field but without loosing any definition).

OSX's prolific and ftdi drivers are also kernel extension (kext) drivers but the kext bundle can store both 32 and 64 bit inside IIRC.

[NickK]

The EQDIR source tree does only provide DLLs and their function declarations - that's obvious however buried in the tree is also the original GNU firmware and serial code which gives the protocol - it also handles a subset of the meade protocol.

Researching that code further - it's likely that this is not the code in use - the PICs in use are different for starters!

Also inside the EQ6, the circuit board has an interesting configuration:

Two PIC16F886 microcontrollers, each with two Allegro A3959SLB-T motor drivers (basic PWM drivers). So this looks like each axis has a PIC and two drivers.

Logically (and it looks as if) the DEC PIC controller handles the serial I/O and then only worries the RA PIC controller when it needs to change the RA. This leaves the RA to spend it's limited CPU cycles on the timing of the RA tracking.

[chrisshillito]

The EQDIR source tree does only provide DLLs and their function declarations - that's obvious however buried in the tree is also the original GNU firmware and serial code which gives the protocol - it also handles a subset of the meade protocol.

If Synta or EQDIR have moved away from this then it's still possible to loop the serial traffic from the handset through one serial->usb device, through a sniffer/logging application and back out to another usb->serial device to the mount.

Hi Nick,

I believe the code you are referring to is actually the protocol for the earlier EQ6 mounts, not the later Synscan versions. This wasn't actually written by the EQMOD developers so I'm not sure why it has found its way into the EQMOD development tree, probably because some of the basic code structures were used as a starting point in the Synta implementation.

You can of course reverse engineer the protocol by spying on the comms between handcontroller and mount - this is exactly how we did it for EQMOD. Of course seeing the data is the easy part - decoding what it means is a little harder. Sadly Synta have never been bold enough to go public with their synscan protocol. There is nothing to prevent reverse engineering and its subsequent use/application but unfortunately those doing so cannot assume the right to openly publish what may after all represent commercially sensitive information. This one reasons why for EQMOD we chose to go the closed source dll route.

Chris.

[NickK]

If I use stellarium and then use the serial-handset cable with the hand controller (not using pc-direct mode) then it will slew however after a few seconds it decides to move again - this could be the handset correcting what it thinks is an incorrect position.

[NickK]

Sadly Synta have never been bold enough to go public with their synscan protocol. There is nothing to prevent reverse engineering and its subsequent use/application but unfortunately those doing so cannot assume the right to openly publish what may after all represent commercially sensitive information. This one reasons why for EQMOD we chose to go the closed source dll route.

Chris.

Ahh I understand - for the mount.

OP, the Synscan User Manual quote:

In the planetarium software of your choice, choose "Celestron NexStar 5i" or "Celestron 8/9/11 GPS" in the driver setup menu and follow the instructions provided by your program to establish the connection to the telescope. The SynScan'" should be under the full control of your computer once the connection is successfully established

Synta have also published a protocol in a manual though, for the handset in the user guide appendix (guide here). For example sending 'e' will return "D3CB9500,2C199200#" as per the guide. However as EQDIR have stated there's additional latency going through the controller. Just out of completeness - sending the other commands such as goto and tracking commands work too.

I now have Stellarium controlling the mount- so to finish this thread investigation.

So for Stellarium on native OSX, these are my findings:

1. Stellarium on OSX cannot simply connect via the EQDIR hardware usb-serial converter to the mount directly - this, as Chris has pointed out is down to the protocol.

2. To use Stellarium on OSX you will need:

* The Prolific VCP or FTDI drivers installed.

* plug in your usb-serial device (I'm using a standard FTDI usb-serial cable - the EDDIRECT box doesn't seem to work as the connector isn't standard RS232) into the handset using the handset-RS232 cable.

* find the driver name by opening terminal and typing:

ls /dev | grep usbserial

This will give you some names, the one you're interested in depends on the driver, Prolific (ie EQDIR) will show up as "cu.usbserial" whereas FTDI append the serial number of of the chip "cu.usbserial-00001004" (the 00001004 will differ for you). Thus your serial port is /dev/cu.usbserial...

* Turn on the telescope control in Stellarium - you will find this in the Configuration Window Plugins tab then select "Telescope Control". Tick the box that says "load at startup".

* restart stellarium for setting to take effect (the configure button is no longer greyed out).

* In stellarium simply press ctrl+0 (that's numeric zero) or select the "Move a telescope to ..." button on the bottom bar.

* Use the configure telescopes as per the stellarium wiki guide, select "Stellarium direct" and enter your serial port "/dev/cu.usbserial" (or "/dev/u.usbserial-00001004" etc) and select "Celestron NexStar (compatible)" as your device type. Press "OK" at the bottom.

* In the "Telescopes" window, under the Options tab - tick the three boxes in the GUI section (this makes stellarium show the position of your scope on screen).

* back in the telescopes tab you should see your scope "stopped".. simply now click "start" and it's status should switch to "connected". Usually this is under #1 telescope.. the number represents the scope number.

* You should now be able to use cmd+scope number (slew to current mouse target) and alt+scope number (slew to screen centre) to move the scope around. Note - the PC/linux documentation states ctrl+number, however Expose will switch screens with ctrl+number key hence cmd+number.

[chrisshillito]

Logically (and it looks as if) the DEC PIC controller handles the serial I/O and then only worries the RA PIC controller when it needs to change the RA. This leaves the RA to spend it's limited CPU cycles on the timing of the RA tracking.

Both PICs are connected to the serial lines and receive and respond to serial messages. The protocol itself includes addressing to ensure that only the appropriate PIC responds to a given message. Both PICs are running the same code and accuracy/timing of tracking on each is identical.

Chris.

[obs30]

Hi NickK

Just a couple of remarks on your procedure, which did not work for me.

...

So for Stellarium on native OSX, these are my findings:

...

2. To use Stellarium on OSX you will need:

* The Prolific VCP or FTDI drivers installed.

Here the important point for me was, that I tried different drivers from different sources:

1) From the CD that had come along with the cable => did not work

2) From the website from the cable manufacturer (Linklogic) => did not work

3) From the "welcome to Prolific" website => guess what => did not work, either, and turned out to be identical with the LogiLink ones or better the other way around, LogiLink provides the Prolific 2303 drivers

4) The 64bit drivers from the Apple Driver Site (same as the prolific-sourceforge project). They worked out of the box.

For re-installing the drivers you might need to go through the manual un-installing of the kext stuff (kextunload, rm -rf etc. as su) as described in the readme files that are part of the driver package/zip.

NOTE: While the Apple site "only" provides a zip file for manual installation, the actual author and sourceforge sites of this driver provide a standard disk image (dmg) and package-type (pkg) installation, which is much more convenient.

...

* find the driver name by opening terminal and typing:

ls /dev | grep usbserial

This will give you some names, the one you're interested in depends on the driver, Prolific (ie EQDIR) will show up as "cu.usbserial" whereas FTDI append the serial number of of the chip "cu.usbserial-00001004" (the 00001004 will differ for you). Thus your serial port is /dev/cu.usbserial...

These were exactly the drivers that DID NOT WORK for me.

Any driver that generated a call out or tty, which contained the "usbserial" did not work on my brand new MBP 2011, OS X 10.6.7.

The new driver generates a device called "cu.PL2303-000013FA".

Actually, for me the /dev/cu.... were only generated with any driver, when the usb-adapter is PHYSICALLY plugged into the Mac. Not before. And they disappear, when the cable is unplugged.

** As for Win-7

Thank you also for the hints with Windows 7. Of course, 64 bit is an overkill for any serial connection ;-)

I am just a little bit surprised what is going on on my machine, when none of the ORIGINAL drivers seem to work, ALTHOUGH it is stated on the Prolific webpage, that they should...

Now I found a solution that works for me and I do not really tweak around on the hardware or any other deep-down settings. I just want the fastest machine possible, since for my number-crunching work I need a powerful yet portable machine.

[NickK]

Both PICs are connected to the serial lines and receive and respond to serial messages. The protocol itself includes addressing to ensure that only the appropriate PIC responds to a given message. Both PICs are running the same code and accuracy/timing of tracking on each is identical.

Chris.

Ok, that's possible with no flow control - very simplistic implementation.

[NickK]

Hi NickK

Just a couple of remarks on your procedure, which did not work for me.

<snip>

I tend to favour FTDI for numerous reasons:

* they seem to work (including the drivers!)

* Bit Bang mode offers very high transfer rates

* Each FTDI chip has it's own serial number along with a programmable USB identity so when you plug that in, software can associate that usb-serial with a particular device (mount/camera etc).

I've actually complied the sourceforge Prolific drivers for the Prolific - the fun is that with newer versions of Xcode the source needs tweeking (the new clang compiler doesn't like 'goto' that he's used prolifically..). Just looking at the open source code - yup it calls it cu.pl2303 as it's up to the driver to name it.

The usb-serial needs plugging in first for the /dev/cu.X to appear.

Sorry if I was going around the houses - I like to dig down until I understand what's happening and why.

It's interesting because the Prolific VCP drivers actually do send signals out - hence the loopback between two kermit sessions (the other using the FTDI).

[obs30]

I tend to favour FTDI for numerous reasons:

* they seem to work (including the drivers!)

* Bit Bang mode offers very high transfer rates

* Each FTDI chip has it's own serial number along with a programmable USB identity so when you plug that in, software can associate that usb-serial with a particular device (mount/camera etc).

...

The usb-serial needs plugging in first for the /dev/cu.X to appear.

Thank you for all that digging. I highly appreciate a thorough analysis.

Well, I bought that PL2303-based usb-serial cable last year. It worked without any problems on my old IBM X41 under WinXP. Now I changed to the MBP and all the trouble started.

Hind sight is 20/20. Maybe now I wound buy a different cable based on a different chip. Thanks for the advice, though.

The nice thing about WinXP is that it has been around for so long that there are no more driver problems. Even the "recent" drivers are at least 2 years old.

The usb-serial needs plugging in first for the /dev/cu.X to appear.

You might want to edit your post on the procedure accordingly, since you wrote the cu.usb... is visible right after installing the drives prior to plugging in the cable, which was not the case for me. Just change the order and it is OK for everyone.

[NickK]

You might want to edit your post on the procedure accordingly, since you wrote the cu.usb... is visible right after installing the drives prior to plugging in the cable, which was not the case for me. Just change the order and it is OK for everyone.

Done - the bullet point was added as an edit after.

[obs30]

Done - the bullet point was added as an edit after.

THANKS!

[obs30]

* You should now be able to use ctrl+scope number (slew to current mouse target) and alt+scope number (slew to screen centre) to move the scope around.

Hi again on this... ;-) Depending on the settings for "OS X - Exposé & Spaces", Ctrl+number might switch the screen or nothing happens. On my Stellarium version, CMD+1 moved the scope. This was also mentioned and confirmed by others earlier in this thread.

[NickK]

Hi again on this... ;-) Depending on the settings for "OS X - Exposé & Spaces", Ctrl+number might switch the screen or nothing happens. On my Stellarium version, CMD+1 moved the scope. This was also mentioned and confirm by others earlier in this thread.

Peer review is a good thing I'm an expert at cmd+tabing and command+~ (between windows of the current application) Edited accordingly!

[engstrom]

Forgive me for asking if this has already been covered (checked this thread but didn't see a solution). Can you use stellarium to control an Heq5 Syntrek mount on a mac?

[Telrad]

Forgive me for asking if this has already been covered (checked this thread but didn't see a solution). Can you use stellarium to control an Heq5 Syntrek mount on a mac?

engstrom, prehaps this thread might help?

http://stargazerslounge.com/beginners-help-advice/124495-stellarium-telescope-control-problem-heq5-pro.html