Issue705(part of the issue): Added Altitude and Azimuth to TelescopeTCP class #3626
Conversation
… stellarium packet for alt/az is the same as for dec/ra
Fixed codefactor comment "blank line at start of code block"
| if(res) | ||
| { | ||
| const bool equinoxJNow = equinox == TelescopeControl::EquinoxJNow; | ||
| const StelCore::RefractionMode mode = equinoxJNow ? StelCore::RefractionOff : StelCore::RefractionAuto; |
There was a problem hiding this comment.
The necessity for refraction correction should depend on atmosphere visibility. It has nothing to do with JNow setting. What is your motivation to connect them?
There was a problem hiding this comment.
Actually I'm not sure what it is used for. The reason I have this check is because I saw in the TelescopeGoTo method that it was used to correct the J2000 position. See line 300-304:
Is there a way to check for atmosphere visilibility. And if so should it also be used in the screenshot above?
There was a problem hiding this comment.
IMO, when driving a telescope from a terrestrial location, it is safe to assume (the real, physical) atmosphere (in which we breathe) is on.
If you have "pure" J2000 data from a catalog/ephemeris (without refraction correction), You must convert them to JNow equatorial position without refraction correction (core->j2000ToEquinoxEqu(j2000Pos, RefractionOff) when the telescope expects that (and applies refraction correction internally).
Then, to compute geometrical Alt-Az position for a goto capable device, you compute alt-az position (core->j2000ToAltAz(positionJ2000, refractionMode);) If your telescope expects AltAz coordinates to be corrected for refraction, you should compute with RefractionOn. If your telescope expects AltAz position to be without refraction correction (because it will do that by itself!), you use RefractionOff.
I have never used an alt-az GOTO telescope, so I am not familiar with these protocols. Maybe this needs yet another config option ("Goto is AzAlt and expects/does not expect refraction correction") Does such a device track the object after the goto slew? Why not just send RA/Dec to a properly configured/set up mount?
There was a problem hiding this comment.
I know that my own Eq6-r pro does refraction correction based on the elevation you input. I don't know about other mounts.
Seeing that the class I'm extending is the TelescopeTCP class which is most likely used for (I asumme??) for a homemade telescope control system maybe it would be wise to have these options under the Telescope properties when you set up the host.
For example:
What do you think?
There was a problem hiding this comment.
Probably the Boolean JNow setting will have to be extended to a 3-value J2000/JNow/AltAz, and an additional Boolean RefractionCorrection would govern the independent extra. @alex-w ?
There was a problem hiding this comment.
@alex-w I wanted to extend the relevant telescope classes with altitude azimuth. I thought a natural (and easier place) to begin with would be the telescopeTCP class. As you know the TelescopeTCP class is the one instantiated whenever a user configures a telescope with a "remote computer". I assumed that one would also want access to alt/az in this kind of setup since a "remote computer" might not be limited to an equatorial mount.
There was a problem hiding this comment.
Well, the mount can be AltAz-only and I fear these mounts will not understand some parts of protocol. Plus EQ/AltAz-mount requires setting the mode. In both cases changes of protocols can be for first item only - commnication directly through a serial port. The second item is incompatible now (I really don't know modern use cases for old Stellarium protocol for mounts - a TelescopeServer).
What about real hardware - is it working in AltAz mode?
There was a problem hiding this comment.
This may be useful for DIY projects with self-made controllers (e.g. Arduino, self-made axis decoder/motor protocol, ...). But I have never used the telescopeTCP stuff, so I cannot say how relevant this still is.
The docs in TelescopeClient.hpp indicate a "Stellarium telescope control protocol" to be included in "telescope server software". Where is this all? (Yes, Google found a 1-page file from J.G. on some "free" site.) Is/Was that a reference implementation of something useful? Then it should probably be archived in a repo here. And somebody who was involved should write the design docs to explain it all. (OK, dreaming...)
There was a problem hiding this comment.
The first version of TelescopeServer is located in SourceForge (SVN: https://sourceforge.net/p/stellarium/code/HEAD/tree/trunk/), the second version is in GitHub: https://github.com/johannesgajdosik/TelescopeServer2
There was a problem hiding this comment.
So I'm wondering if this is the right course of action with this patch. Whether we should continue with this PR?
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
alex-w
added
the
subsystem: plugins
Description
Issue 705 describes a need for sending Altitude and Azimuth with the Telescope plugin.
I've added this functionality to the TelescopeTCP class as a starting point. The plan is to extend the other classes when I've had more time to research their specific protocols.
With this fix for TelescopeTCP the Stellarium protocol has been extended with two entries Altitude and Azimuth which means that the packet length is now 28 bytes.
I've added a new protected method in the TelescopeClient abstract class that converts j2000pos to altitude and azimuth. This can then be used in any derived class that might need this conversion. More specifically , as mentioned above, it is now used in the TelescopeTCP class in the TelescopeGoTo method.
Fixes #705 (issue)
Screenshots (if appropriate):
Type of change
How Has This Been Tested?
This was tested with a python script with a TCP server. The TCP server receives Slew commands from Stellarium and interprets and prints the contents to the console.
Example of a print where azimuth and altitude was added:
Test Configuration:
Checklist: