Meade Serial control

[algwat]

Gidday,

Just found I can use processing.org serial software to talk directly to my Meade ETX90. When combined with camera software. A one stop solution seems possible.

Has anyone tried DIY telescope controllers ??

I put up some code soon.....

kind regards, Alan

[Barrykgerdes]

Meade protocol for accessing all the control functions of Meade telescopes is accessed via a serial RS232 port and a table of these commands is available from Meade. Many other telescope controls eg. Gemini 1 also use the Meade protocol for communication

I have written many programs firstly in basic as described in the LX200 series manuals and later converting these to QB64(Gl) so that they run on 64 bit platforms to access various control functions.

No matter what your preferred programming language the requests sent to the telescope and the replies received are universal so go to it and write some code.

Barry

[algwat]

Thanks Barry
Yes I found the Meade control statements PDF (2010).
Still working out the write - read buffers.
I want to get a continual RA/DEC or ALT/AZ position readout.
Just not working cleanly.... I want to workout ALT/AZ first.

I am using a Targus RS232/USB with the handset still in the daisy chain.
Starry Night and Stellarium working ok.

Kind regards, Alan.

[Barrykgerdes]

Good Alan
I just use an "operate" loop that polls all the parameters I need to see or modify about 12 times/sec. I don't read the Alt/Azm because my programs all have a sub that does the conversion.

http://barry.sarcasmogerdes.com/qb64/ETX-control.zip

This is a program to drive the ETX written in basic (QB64(gl)).

Barry

[AndrewJ]

Gday Baz/Alan

Just a quick few comments.
Querying the scope too often is not "normally" very useful, as at a max, the 497 type handboxes only read the encoders 10x per sec.
The LX200GPs can extend this out to 0.33x per second if polar.
Also, if polar, the 497s rs232 responses for Alt and Az Lie :D as they dont do a proper conversion, they return "base relative" encoder vars.
On top of that, the firmware also stores a secondary set of dummy variable "copies" of RA/DEC/Alt/AZ as they go, and use these at times to respond to serial commands.
Depending on whats going on in the background, these may not get updated as often as they should be :shrug:
Ie treat the results with a grain of salt;)


Andrew

[Barrykgerdes]

Hi Andrew
I wrote those programs in the days when computer processors worked in Hz rather than GHz. So the loop only polled the telescope once every few seconds and each request had to wait for an answer. In the mean time the program looks for key presses, calculates the time, sidereal time etc every loop.

With the speed of the modern processors the loop runs much faster but as you say lots of the answers to requests are read more than once within the cycle of their calculation in the controller. Practically this is not noticed.

Actually there are two versions of the LX200 and ETX controllers. One is just a mirror of what is in the telescope. The other only uses the positions read from the position in the controller, resets the buffer and sends a goto command as required and all the sky data is read from an appropriate data base. This format allows me to use the main source to control Celestron and Synscan as well as the Gemini by just changing the commands that read and write to the scope

Barry

PS I don't normally use these programs in the field. I just use them to run my LX200 test set, Heq5 and Gemini mounts to test that the computer can talk to the telescope.

BG

[algwat]

Appreciate the code very much thanks Barry.

I got continual ALt/AZ readout by polling handset readout using "#:ED#"
once very 5th screen frame of 30.

Will see how far I can get with some of your QB code converted.
My software is not going to be any thing commercial, and will alert you when I have a good set of functions happening.

I am only looking to use this as a wide field ALT/AZ mount controller, don't really need it to be completely accurate, but if it happens that's a plus.

Kind regards, Alan

[AndrewJ]

Gday Barry

Re


I would need to reread my notes, ( as there are too many firmware variants out there now and they all work differently :shrug: ),
but as i mentioned earlier, there are some "multi use" global vars ( 4 byte ints ) that get used to hold data along the way and too high a polling rate can in some instances chop these up via the internal interrupts, ie the 4byte int "appears" to get its MSB and LSB set in two different states.:sadeyes:
Its rare but it does happen.

Alan,
By using the :ED# method, the data shouldnt get chopped up, but it will be slower than normal processing, and requires the Hbx to be left in that screen. I would suggest if you are set up AltAz, just use the correct serial commands and read at a rate no greater than say once per second and all should be well, and the hbx can be used as per normal.

Andrew

[Barrykgerdes]

I don't use the #:ED# command. I just use #:GR# and #:GD# and HP mode.

This gets the position that is stored for the mount current position and I calculate the Alt/Azm in the program. I use "Put" and "readdata" to get around problems in QB64(Gl) that don't allow some OPEN commands

The other commands used are to enter RA (Sr+HH:MM:SS) and Dec (Sd = sDD:MM:SS) and Goto (#:MS#) and slewing controls from the arrow keys.

Some of the other parameters are read from the scope at program start like location and time offset but not read again.

There are also sub routine features to set location, date ,time etc if required

All other data is read from data files that can be updated if required.

Barry

[AndrewJ]

Gday Baz

Just to be pedantic:P ( cos its hot, and i can )



:GR and :GD dont return "the object", they ( are supposed ) to return where the scope is currently pointing, and can be affected by glitches.
:Gr and :Gd return the theoretical data for the last selected object
and are not affected by the glitches, but may not relate to current if the hbx slew keys or guiding has been used .
Meades code is a ratsnest in some places and is far more fragile than it should be, due to the way they share/use global variables.
IIRC, one user used to keep a running average of position and didnt declare it to be correct until he got 3 common reads for RA/DEC.
All good fun to watch for.

Andrew

[Barrykgerdes]

Sorry Andrew

I should have said gets where the scope is pointing after alignment or intermediate positions when slewing to a new position. I was trying to read from the source that does not have any useful comment lines and I did not have a handy print out of the commands. I also modified the original source that did read the Alt/azm to bypass this "read" and calculate the Alt/Azm for the object.

I found a number of differences in the program I had and the program I thought I had. The basic source was written nearly 20 years ago for the LX200. I just re-hashed it to suit a Gemini, ETX-70 and HEQ5 and then to work with Qb64 so it would work in Win 7, 8. so I could test computer control with the different mounts.

Barry

[AndrewJ]

Gday Baz



Yep, but as i noted, i was just being pedantic :D,
as the two commands can give very different results.

Also, just as another aside, based on yr clarification above,
reading RA/DEC "during slewing" is even more fraught with error,
as Meade uses another set of different "faked" variables to report the RA/DEC based on "projected" positions in time.
Ie in AltAz for final tracking, they calculate a point a set period in time ahead of now, and set the Az and Alt motor rates accordingly, ie they adjust the motor speeds until current matches projected. This mechanism allows any residual error, backlash etc to be accounted for,
but can create other problems ( like DEC guiding in polar with the latest Audiostar firmware )
Until the slew is almost finished, these projections wont be stable, but they may also not relate to reality, so again, a grain of salt is reqd if the data is to be "relied upon".

Andrew

[Barrykgerdes]

Yes however the read position loop will make a number of readings (and calculations of Alt/azm) while the scope is slewing. It just serves to show the scope is moving just like the old boxes on the LX200.

The scope of course converts the RA/Dec position into alt/azm increments to track but I have never had any trouble in this area. The movement is smooth enough for my use.

By the way I corrected that post to read mount current position and blamed you as the reason for the edit:P:lol:

A further by the way. Have you melted yet? I see the trams are in trouble again with buckling track!

Barry

[AndrewJ]

Gday Baz



You are too kind :D



Fridge is full of beer and freezer has a frozen bottle of Stoli "just in case".
This weather ( like Adelaide ) is ridiculous. Overnight minimums only just getting down to 30degC at 6.00am then already rising again is crazy.
Even my Camelias have sunburn after 2 days.



The price of privatisation i guess.
Stuff is no longer built and maintained for 100% operation.
If a beancounter says its cheaper to let it fail then fix it, vs maintain it, thats what they do.
Im stunned that they can get away with saying
"sorry, its going to be really hot today, so rather than us break down on you, we just wont provide a proper service till its cooler"

It will be really interesting to see what happens after 4 days like this in a row. I reckon lots of infrastructure may start to show its real condition.

Andrew
( hmmmm, my latest stubbie is just starting to melt enough to drink )

[algwat]

Ok,
so here is a bit of work in progress code for you to play with. if your game...
The Meade is doing some funny things if I send complicated command strings...

This code will move the mount N-E-S-W, has a target example string, has a zero-zero AltAz home. And a few other buttons. It overlays most of the info on the camera image, could be useful for many things later.

You will need to determine your com port, and your camera needs to be windows detectable, ie. a DMK. . It can be made to save PNG or JPG images.

Some possibilities for later....
Pixel values can be read dynamically...
real time measure a variable star ....
find all the bright stars in the FOV....
track selected stars to make guiding calculations....in field guiding...
spot fast movers, meteors, satellites.....

copy the text file into a new 32bit processing.org sketch and save it.

Also note that Serial only works in a 32bit processing.org sketch.

kind regards, Alan.
Have fun.... not really offering any support, but happy to help if I can...
added screen example of AltAz mode....