NexStar Resource Site

line.gif (861 bytes)
Pop-Up Info Window
(close when finished)
line.gif (861 bytes)

line.gif (861 bytes)

Programming Examples

For those of you wanting to develop your own PC control program, I have extracted the complete GoTo RA-Dec and Get RA-Dec procedures from my work on NexStar Observer List.   Download  by clicking here.  An additional programming example is available on the page for Enhanced Commands for N8/9.25/11GPS and N5i/8i. They are all written in Visual Basic version 6, but could easily be adapted to most any programming language.  You may also want to click here to download an Excel spreadsheet that can be used to verify that your program calculates the "high and low bytes" correctly.

They are offered as is, with no implied warranty or support.  Have fun!  Also, refer to the next section on this page for additional programming help for the newest NexStar commands.

The following explanation may help you to better understand how to formulate the commands as shown in the programming examples and in accordance with the documentation provided above and in the NexStar manuals.

The first thing to understand is that we are never really sending any numeric values to the scope at all. With the old GT and N5/8 commands we take each encoder values and split it into two bytes  for RA and then two bytes for Dec. Each byte has a possible value from 0 to 255.  Then rather than sending that as a numeric sequence, we must convert each byte to an ASCII character (for example, using CHR in Visual BASIC). Then concatenate the "R", the ASCII characters for the high and low bytes for the RA, the ASCII NUL (not needed for N5/8), the ASCII characters for the high and low bytes for Dec and finally the ASCII NUL (again, not needed for the N5/8).

With the GPS and the new GT, things are similar, but, if you think in terms of the old GT and N5/8 commands, it makes it more difficult to understand. With the GPS/new GT, we take each encoder values and split it into two bytes for RA and then two bytes for Dec. Each byte has a possible value from 0 to 255.  Then we must convert each byte into a 2 digit hexadecimal number and form the command. Thus we send to the scope the "R", the 4 hex digits for the high and low bytes for RA, a "," (comma), and finally the 4 hex digits for the high and low bytes for Dec. The trick here is that we must have 2 hex digits for each of the bytes and we simply send them as a string data type in the "R" command.

So, for an RA of 3h 5.8m and a Dec of 50 degrees, we get the following 0-255 high and low byte values and their Hex equivalent:

  • RA High: 33 Hex: 21
  • RA Low: 7 Hex: 07 <--(the leading zero in the Hex value is required)
  • Dec High: 35 Hex: 23
  • Dec Low: 142 Hex: 8E

You can test values by using the Excel spreadsheet available above.

So, the commands we need to send:

  • GPS (or new GT): "R2107,238E" <-- don't forget the comma!
  • N5/8: "R" & CHR(33) & CHR(7) & CHR(35) & CHR(142)
  • Old GT: "R" & CHR(33) & CHR(7) & CHR(0) & CHR(35) & CHR(142) & CHR(0)

Where CHR is the function to convert an Integer (between 0 and 255) to it's ASCII character equivalent. Note that CHR(0) is the ASCII NUL character required for the old GT hand controller. Also note that the entire command is always a string value. In the programming samples, the LEN function in my sample routine is being used in conjunction with the MID function to insure a leading zero on any single digit hexadecimal number.  The '&h' is used to force the VAL function to treat the hexadecimal number as a hexadecimal value.


line.gif (861 bytes)

line.gif (861 bytes)
Copyright 2000-2017
Michael Swanson
 
  Contact the webmaster:
swanson.michael@usa.net