Karl: The AUX port is *NOT* an RS-232 serial port! You need a special level converter to connect PC serial port to AUX. You need PC-port for this. Please do not connect your PC to the mount by AUX port. You can destroy your mount, your PC, or both by doing so. If you have no PC-AUX adapter, use the HC serial port.
Read More...
Last night there was some nice weather and I decided to run a bunch of tests of a current driver. Most of my previous comments and conclusions stands, but I have a little bin more data and some additional conclusions and comparisons.
It was run with astroberry compiled caux and other drivers and kstars compiled from git.
One more thought. I really do not know what happens after the guide pulse. I guess encoders got updated, and the effect is the same as would be if we moved the mount with slew commands. But this is just my guess. It is possible that the MC hides this update and subtracts the guided angle from the reported position. In other words: if the position on the axis does not change after guide pulse, we are good. Otherwise, we need to do this subtraction in the driver by keeping track of the guiding shifts - this may be tricky but seems doable (the guiding pulses are simulated anyway, thus there is a strict relation between length of the pulse and actual number of steps shifted).
Read More...
The initial driver was intended only for the AltAz mount, like the Evolution. The Eq mode is an afterthought. Nevertheless, the same approach will still work for Eq, since no mount is perfectly aligned and the input from the alignment routines can be still used to correct rates in Dec and RA - thus eliminating the necessity for very precise polar alignment. Thus, I would not switch to a completely different tracking mode for Eq mounts. Since the standard Eq mode (sidereal rate in RA + guiding pulses) is much simpler, it should be fairly easy to add it as a switchable option. Remember that not everyone has a guider - thus removing corrective guiding would make the driver less functional. As for the fight between the tracking and guiding pulses: I do not know really. But, I think that it should be fine since we are controlling the speed not the position and the target position is not changing. Thus, we are correcting only the errors of the mount not the tracking rates and target position.The motor controllers handle constant angular velocity and two types of goto movements. You specify angles for the gotos, and then you specify the tracking rates in both axis (with MC_SET... commands). These rates are constant - if you switch off the driver or lose the connection, the scope will keep rotating with constant angular velocity. That is why it may be unsafe to operate without limit switches or supervision. The 30s period is arbitrary and probably fine for visual observing. It is definitely not enough for high-Alt positions (the AZ rate changes rapidly). We are actually sending adjustments every second in the current driver based on +/- one-minute position difference. The controllers seem to have no problem with this rate of adjustments. In my view the guiding does not shift the position on the sky it only corrects for the errors in the mount. The tracked position (thus also tracking rates) does not change. So in this respect we should be fine as long as we are not reading back the encoder positions to modify the rates. The first version of the driver actually did just that, and I had huge difficulties with making it consistent. At present, the tracked position is changed only when we use movement controls. But in this case we are supposed to move the tracked position on the sky (that is an assumption).
Do not hesitate to ask if something is still unclear. The interplay between tracking, guiding and manual movement is really tricky to get right. I do not think we can avoid making some assumptions. Otherwise, there are simply too many degrees of freedom.
Read More...
Quick follow-up about signedness of angles in AUX commands. I have reviewed my notes and it seems that the angles are indeed 24bit unsigned ints which are farctional full rotations. So 360deg = 2^24 in the angle field.
Read More...
Do you mean SkyPortal (SkySafari) driver? It connects to the indi server, not to the scope.
The 2000 port is a port of the Wi-Fi module in the telescope. You can connect to it with CAUX driver, Celestron SkyPortal or SkySafari.
The SkySafari *driver* speaks LX200 protocols on different port and acts as a bridge between indi server and the SkySafari application.
Read More...
Thanks for the explanation, Jasem. Let me just comment a bit, maybe it will help in deciding the directions.
I guess we need another remote session when moon will be up
Then I will either prove myself wrong or proof to you that it actually works
I just tested exactly this scenario: Manually point to the moon sync and follow with next two points. It seemed to work with simulated ccd. The real sky is another matter, though.
Let us wait for good weather and the moon/jupiter/venus
Read More...