I'm running kstars-bleeding and libindi-full, including libindo-LX200_AP (all from the ppa:mutlaqja repository) under Ubuntu 13.10, and kstars is NOT playing well with my 2001 vintage AP900GTO-CP2 with the EI ROM chip upgrade.
After running the mount through an 'N-Polar' alignment routine ending with the scope pointed at Polaris, I fire up kstars, make sure the time and location is properly set, and start the LX200_Astro-Physics service. I then connect to the mount from the INDI control panel, set the tracking to Sidereal, and have a look at the kstars display. The telescope cross hair is no where it sight. If I right click on the screen, slide down to the LX200-AP option and select 'center cross hair', the program show the cross hair buried below the horizon in a place completely unrelated to Polaris. If I right click on Polaris, again slide down to the LX200-Astro-Physics option and select 'synch', instead of synching the cross hair to Polaris, the program slews the telescope off to someplace also completely unrelated to Polais' position. If, after a clean restart of everything including a reboot, I select 'slew' from the right-click on Polaris--> LX200-Astro-Physics sub menu, the scope again slew off to the wrong position, although not as far as it would had I chosen 'synch' instead'. If I then do a right-click on Polaris--> LX200-Astro-Physics--synch, the mount heads off into a slew that if left un-aborted would surely crash the scope into the pier.
At this point, if I disconnect from the mount, shut down the INDI service and turn off the computer and unplug the USB/Serial adapter from the scope and try to do a 'park to position 1, the mount wanders off to some place not even close to position 1. By now, the mount has no idea where it;s pointed, and a complete cold restart is required to return to a properly ordered state.
This behavior remains unchanged whether I set the 'Sync' string in the INDI configuration to 'CM' or CMR' Quite frankly, this is a complete show stopper in an effort to get out from under the tyranny of Micro$oft/Windose, and ASCOM. It all looks very much like a serious flaw in the code, but if it might be a case of operator head space, I'm open to suggestions. Thanks
Let me preface what I am about to describe works with an AP1600GTO mount which I have worked with. I take no responsibility for what other users may do with their AP mounts, even if the model is exactly the same. Please, evaluate and use this information at your own risk.
If the mount hand control allows for an "External" connection, select that option. The mount should not be in the normal autoconnect mode. We begin with the mount in a position close to horizontal.(Park1) With the telescpe powered in the External mode, the hand control will display a message indicating that it is waiting for external software to communicate with it. At that point, our connection SOP is similar to yours. We fire up KStars, start Ekos using INDI settings for the LX200-AP and "Connect" to the mount. After a successful connection is made, we click for "Cold" initialization of the mount. No movement occurs. If successful, we click the "Site Management" tab. Under that window, we have entered the Lat,Lon data for our site in the Western Hemisphere. The Longitude value we enter was obtained by subtracting our longitude from 360 degrees. Our latitude is a normal positive number. Once entered on the right hand boxes KStars will have these for future use, however, it DOES NOT initialize them with the mount. So, we must click "Set" to register them each time.
If all goes like ours, you will see the red telescope icon on your KStars display at this time. In our case, it shows a telescope position just above the horizon in a view facing North.
Since we are still in a testing phase, I can not tell of the accuracy of the slewing. I can tell you, it does "Slew" to appropriate sky positions. WE HAVE NOT used the sync function on KStars. We have only used Slew, and, not yet under the stars. But, the mount does appropriate meridian flips, and, it does slew into a reasonable position for the objects selected within KStars.
I would appreciate it to know what you might find.
Thanks for the advice. Unfortunately, it does not solve the problem. Close, but no cigar... My AP900GTO-CP2 with the E1 ROM chip onboard doe indeed allow for external initialization. I invoked that option on the keypad as you suggested and restarted the mount. Sure enough, it came up saying it was waiting for the external program. At that point I continued with the procedure you describe, following your instructions to the letter. While this does get the telescope cross hair above the horizon, it is still no where near where I expect it, i.e., due North at or just above the horizon (Park 1). Instead, it show up just under the bowl of the Big Dipper AKA Ursa Major. If I ask the scope to slew to, say, Polaris, it goes off in some completely inappropriate direction. If Park the mount back to position 1, it slews to a spot that appears to be where the cross hair first showed up, i.e., scope of the east side of the pier (rather than on the West) and about 10 degrees above the horizon.
Clearly, something is amiss with the initialization of the mount. I'm inclined to believe it has something to do with the longitude setting. I'm in California, USA, so my longitude is -121:53:1 or 121:53:1 W. If I try entering a negative number for longitude, it fails saying lat or long missing or incorrect. If I add 'W' or '+W' as a suffix, it produces the same results I described above. I tried doing a 'warm' initialization with AUTO CONNECT set to "NO" and got similar, but slightly farther off results.
Now I've considered the possibility that being a CP2 controller and running the E1 ROM revision might be at the root of this, but back under Windose, programs like Stellarium, The SkyX, Maxim DL, PEMPro, all interact with the mount in the expected manner with no need to makes special adjustments for the controller type or the ROM version.
Just to clarify a couple of things. Your longitude is 238.47 based on your actual longitude of 121.53. You do not enter - or W.
Second item, don't worry about the direction the icon goes on the KStars screen. I know, its crazy, just trust that your mount SHOULD never place the counterweights above level. If it does, something is wrong and stop it immediately.
If you consider Polaris the intersection of an X and Y axis when viewed with the word North at the bottom, You will find the lower left quadrant and the upper right quadrant will have the telescope on one side of the mount. The upper left quadrant and the lower right quadrant will have the telescope on the other side.
As for the AP mount speeds of slewing, I can only hope yours is slower.
Your clarification was helpful, if not entirely intuitive. By that, I mean using numbers outside the traditional -180 - +180 range for longitude just seems odd. In any case, it did put the telescope cursor somewhere within reason upon initialization. However, I'm afraid that's the best I can say. I tried slewing to a few stars, and the mount appeared to go to appropriate parts of the sky although I can't tell with any certainty since I indoors under cloudy skies. But the telescope cross hair kept getting farther and farther from the target star as I went farther from the pole. At no time did the mount appear to go to the wrong side of the pier (the CW shaft stayed below horizontal), but there was a severe discrepancy between where the scope had been asked to point and where the cross hair ended up. Finally, I sent the mount back to park position 1, and it had no idea where that was, At this point things did go CW up, and I terminated the slew promptly. BTW for tests like these, I do keep the slew speed down to 600X maximum.
None of the above inspires any confidence that the kstars/libindi/ekos system is anywhere near ready for prime time. I expect things to 'just work', and that is clearly not an appropriate expectation here. Which is not to say I won't check in from time to time to see if any progress has been made, but for now, for my day to day imaging, it looks like I'll stick with Maxim/PinPoint/Sequence Generator Pro, etc., for target acquisition and data collection.
I would suggest the manufacturer's website and downloading the Keypad 4.12 manual. Pages 62+, 80, 82+. These contain some specific information which might help.
In particular, see the top of page 82 where your E1 rom is mentioned.
No need to go to A-P's web site as I have both hard and electronic copies of the manual at hand, and I have consulted them in the course of dealing with this issue. As to the specific reference to the top of page 82 and it's mention of the E, KE, E1, and KE1 chips, I fail to see what the broken horizon check command has to do with the fact that the LX200_AP module does not come close to tracking the mount's motion except close to the pole. With reference to page 80, I'm familiar with the difference between the CM# and the CMR# commands and the fact that CM# should only be used during initial calibration when the mount is known to be on the correct side of the pier. I do have the INDI configuration of the mount set properly to reflect correct usage of these 2 commands. Finally, the discussion of orthogonality is moot since the mount is known to be acceptably orthogonal with either of the two telescopes I own being mounted.
I do appreciate your help and suggestions, but I really have no further interest in try to get what is essentially pre-alpha software to work properly. I'm happy to leave that task to the INDI developers. With your help, I do believe any misconfiguration or misuse of the software as a source of the observed problems has been rule out. That said, I think what would be most helpful would be for me to file a bug report.
By way of follow up... I've been in touch with the author of the LX200_AP module. FWIW, that code hasn't been updates since 2007, and Markus Wildi has since moved on to the RTS2 project. He does, however, acknowledge that the driver has some "issues", and he has kindly agreed to work with me to get them resolved.
I don't have any idea how many people may be using this code. My guess is not many, given there's only been one respondent to this thread. That said, I will report back if there are updates or developments..
I just migrated the Astrophyics driver to use the newer INDI framework and updated LX200Generic driver, and remove quite a bit of the features provided by the older LX200 AP driver just to make sure the newer driver can work fine.
Can you please test the newer AP driver and let me know how it goes? Don't expect it to fully work yet though.
I'll be happy to test the newer framework/driver. How may I get it installed? I've got the mutlagja/astrometry.net and mutlagja/ppa/ubuntu saucy repos configured for apt-get. Sp would a simple "apt-get upgrade" do it?
Yes, but if you're using the PPA, wait until tomorrow until the packages get rebuilt. Furthermore, run indiserver from the command line:
indiserver -v indi_lx200ap
Then in KStars, go to Device Manager, Client Tab. Add a new Host with Name "AP Driver", host "localhost", port "7624", then connect to it. Before you connect, go to the Options tab and enable Debug. After connection, press "Cold" to init the cold start up. Please send me the logs from the INDI Control Panel and also from INDI server in command line. Let me know how it goes.
Edit: FYI, Regarding syncs, only :CM command is implemented now. Will add :CMR later on.
Great!! Infortunately, I got a bit ahead of myself and did the upgrade today. Ooops! I'm going to assume that repeating it tomorrow will pull in the updated driver. I'll try that, and if it doesn't bring down the latest, I'll uninstall and re-install.