Arduino-based Cartes du Ciel Skywatcher bridge
I’m currently developing a prototype connecting a planetary software on a laptop or tablet like “Cartes du Ciel” or Stellarium to my Skywatcher AZ-EQ6 GT telescope mount. Physical the connection should be WLAN using an Arduino and an Ethernet shield. There are commercial WLAN products out there, but I was not pleased of the stability. SkyFi lets you control a telescope or other serial device from a computer, iPhone, or iPod with WiFi wireless communication from SkySafari. To user other programs additional different HW and SW components are required, and go wrong. You do not want care about instability in the field. so finally I went back to good old serial over USB.
Like most instruments in astronomy, my particular unit can be controlled remotely via a serial connection, but doing so would require an USB to Serial Adapter and the control computer to be within, at most, 15m.
Proposed here is an Arduino-based converter that uses a TCP socket to send and receive commands to and from a serial device. In this way, the mount control unit can effectively be placed on the local network. Whilst the Arduino can happily handle all the tasks associated with running the motors and pointing the telescope, in a modern observatory standard applications and driver rule. A wide range of astronomy applications are needed for successful imaging. All such applications talk to telescopes using the common ASCOM interface. None of the planetarium etc software I wanted to use knows a thing about my Arduino system. Nor did I want to write an ASCOM driver to sit between the Arduino and the application software I needed to use. So this is basically just a virtual serial over IP bridge, using the standard ASCOM driver and logging on a LCD in between and an exercise how simple SW can be.
Connection the application to a virtual port
Virtual Serial Port Configuration
To communicate with the Arduino ethernet board, a piece of software is required to emulate a virtual serial port. I use a one of eterlogic.com because it is simple, versatile and stable. VSPE is intended to help software engineers and developers to create, and test applications that use serial ports. It is able to create various virtual devices to transmit/receive data. Unlike regular serial ports, virtual devices have special capabilities: for example, the same device can be opened more than once by different applications, that proved to be very useful. This software offers quite a few features:
- Virtual device: connector
- Virtual device: data splitter
- Virtual device: pair
- Mapper device
- User mode device: TcpServer
- User mode device: TcpClient
- User mode device: Serial Redirector
- User mode device: UDP Manager
- User mode device: Bridge
- Embedded HTTP server
- Data monitoring
Setup is simple, I created a virtual port and connected it to my Arduino server IP port.
Skyscan Arduino Uno hardware considerations
For the Skyscan handbox, electrically, only a 3-wire, TTL level RS232 serial signal is required, namely Ground, Rx, andTx. Typically, the Synscan handbox (HBX) is connecting to this motor controller. An old Windows PC can use its serial RS232 port (rarely today) dropping down to TTL level (by a level shifter/transceiver). A more popular option is to use a USB-serial RS232 TTL-level dongle toperform such function. (One popular commercial product for that is anEQUSB device.)
arduino_board
The Arduino Uno provides TTL level serial RS232. The Arduino Uno microcontroller board is based on the ATmega328 (datasheet) to support the Internet of Things. It has 14 digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, a 16 MHz ceramic resonator, a USB connection, a power jack, an ICSP header, and a reset button.
HBX
It contains everything needed to support the microcontroller; Theoretically onn needs has to connect the three wires (TX, RX, GND) to the Skyscan to get started. In practice that does not work, although both are within TTL level (Arduino on the low limit 4.4 and (my) Skyscan on the high limit 5.4 Volt for High. A TTL or RS232-TTL converter is needed. Better for shielding the expensive Skscan anyway.
Skyscan
As you can see, the Ethernet shield sits on top of the arduino, in the developing phase with a fixed connection a bread board for simple connections. The Arduino Uno has only one – well uno – serial output, otherwise you need to use two digital outputs as soft serial.
Another possibility would be implementing EQMOD in the pass through modus of the handbox. EQMOD has been very successful in enabling the very powerful Synscan microstepper based GOTO mount to be extended with many powerful features.
Since Skywatcher has released its intelligent motor controller API into the public domain: http://code.google.com/p/skywatcher/ there will be many new opportunities.
Skyscan Arduino Uno software considerations
To the handbox the communication is always initiated from the application side, a typical open sequence, is initiated with an “?E”, after response followed by “V, P, M and J”, to which the handbox has to be appropriately respond going finally in the polling mode with “e” to ask for RA and DEC.
Set Connected COM5 Baud rate: ps9600 Timeout: 1000 Transmission format – Bits: 8 Parity: None Stop bits: One
request from app————–GET RA/DEC —- only one byte taken from response
> ? (HEX[3F])
> E (HEX[45])
< C (HEX[43])
request from app————–GET VERSION —- response 2.2
> V (HEX[56])
< # (HEX[02][02][23])
request from app————–ask for —-
> PG (HEX[50][01][10][47][00][00][00][01])
< [80]# (HEX[80][23])
request from app————–ask for —-
> PG (HEX[50][01][11][47][00][00][00][01])
< [80]# (HEX[80][23])
request from app————–Get Model response i series
> m (HEX[6D])
< # (HEX[03][23])
request from app————–Is Alignment Complete? response yes
> J (HEX[4A])
< # (HEX[01][23])
request from app————–Get precise RA/DEC
> e (HEX[65])
< 9B8E8C00,12129000# (HEX[39][42][38][45][38][43][30][30][2C][31][32][31][32][39][30][30][30][23])
request from app————–Get precise RA/DEC polling repeated
> e (HEX[65])
< C1FBEE00,14618000# (HEX[43][31][46][42][45][45][30][30][2C][31][34][36][31][38][30][30][30][23])
———————————
The reason for the sequence of commands at the start is to detect a Celestron (alike) mount and identify what protocol it uses. If the Arduino doesn’t send the correct response then the driver will report that there’s no Celestron scope connected.
There are several things that may give trouble:
An Arduino (or some Arduinos) does a reset when the serial connection is made and is looking for a boot start. The “?” string can be ignored but the “E” must give two hex numbers, in particular the first character must be ASCII hex. Anything else will cause it not to be recognised.
The first issue may cause a problem, if the Arduino is not responding to the first characters. There’s a difference between “E” and “e”, they return different length strings. Also the 5.0.30 driver has been replaced by the 6.0 driver recently.
Motor communication
To the motors the communication is always initiated from the handbox side. The control word starts with a “:”, followed by one character (as Op code), then either a “0” (for RA) or “1” (for DEC), followed by the optional parameter, then end with \r (0x0d) character to the end the command.
The motor controller will take in the command and execute it, if the command is coherent with the intelligent controller’s internal state.
Note 1: although some command (e.g., GOTO a new position) may take time to complete, the motor controller will still return with the acknowledgement immediately. Affirmative return started with “=” (followed by optional status/parameters). This only confirms that command is received okay and is not violating the motor controller’s state. Negative/error would return with a “!”.
Note 2: there is no queue in the action-command queue. A new action type of command will supersede the previous action type of command.
Note 3: there is no call-back from the motor controller side (e.g., GOTO command completed). So the handbox side has to poll for the current status from time to time.
The command Op code can be lower case alphabet, which is to get information or status. Some of them are simply getting pre-stored mount basic parameters (they are hard-coded, defined in the motor board firmware, and not changeable). Others are used to query intelligent motor board status (e.g., current position).
The command Op code can also be upper case alphabet, which is reserved for action type of commands. E.g., “L” is for emergency stop (when mount-hit). See here the protocol version 1.2 of the Celestron nexstar5, which the Skyscan is emulating: 1154108406_nexstarcommprot
RS 232 Protocol on TTL level
The Arduino has a hardware interface, called a UART, to control serial data. The input/output of the UART is typically located on pins 0 (RX) and 1 (TX).
The microcontrollers built in UART (universally asynchronous receiver/transmitter) can be used to receive and transmit data serially. UARTs transmit one bit at a time at a specified data rate (i.e. 9600bps, 115200bps, etc.). Ardunio uses a method of serial communication referred to as TTL serial (transistor-transistor logic). Serial communication at a TTL level will always remain between the limits of 0V and Vcc, which is often 5V or 3.3V.
The method of serial transmission used is such, that a logic high (1) is given by Vcc and a logic low (0) by 0V. Normal RS-232 is similar, except that the ranges of voltages used to represent the data are different to make communication more robust.
The serial port on your computer (if iyou are lucky enough to have one, they’re quickly becoming a relic) complies with the RS-232 (Recommended Standard 232) telecommunications standard. RS-232 signals are similar to your microcontroller’s serial signals in that they transmit one bit at a time, at a specific baud rate, with or without parity and/or stop bits. The two differ solely at a hardware level. By the RS-232 standard a logic high (‘1’) is represented by a negative voltage – anywhere from -3 to -25V – while a logic low (‘0’) transmits a positive voltage that can be anywhere from +3 to +25V. On most PCs these signals swing from -13 to +13V.
The more extreme voltages of an RS-232 signal help to make it less susceptible to noise, interference, and degradation. This means that an RS-232 signal can generally travel longer physical distances than their TTL counterparts, while still providing a reliable data transmission. To interface between these two signal levels, one must first invert and regulate them. This is commonly done using a MAX232 IC.