The driver is being reworked and will hopefully be updated again soon.
Using EKOS I could get it to park/unpark by first using the cold start button. Since the introduction of the cold start button is recent I had to first
edit the configuration file to add the cold start button definition. Being a new install you might already have it working. See the post before yours.

Are you presently testing via EKOS.

Do you see the cold start button in the telescope's INDI configuration screen panel?

/Tom

I am using Indi with indistarter and ccdciel. I can see that the Mount is initialised with date time and location information. However I cannot seem to unpark the Mount and therefore I do not know if the Mount knows where it is pointing. There is a cold start button on the control panel.

Thank you for the update. It appears that Markus got very busy after the latest changes he made to the driver. Do you have any changes planned for this driver? What exactly needs to be done since I'm somewhat rusty on this particular driver.

I have not used it this winter so only have superficial impressions noted in my last but one post.

There is some odd behavior in the indi panel using the save button. I had to disable logging in the EKOS setup panel. That removes the logging check boxes from the telescope's INDI panel and then the save button would work.

But the main thing was the introduction of the cold start button in the INDI panel. The user has to locate it in the INDI panel and push it before any of the EKOS mount controls such has park/unpark will work. Not sure how that will play with the scheduler since it does not offer such an option. The initial startup conditions are different now: unparked and not tracking. However one can not slew to a position or do anything else until the cold start button is used. I think that is true even if the mount has not been powered down from one EKOS run to another. I would prefer whatever cold start does, for it to be automated or its requirement be conditional on identifying older mount firmware.

I think some of my initial difficulty with getting it to work was that the cold start button was not there or was not working, can't remember which. This was because was not defined in my mount's INDI XML file due to the file being retained across installs. When I tumbled onto that and edited the file things started to work.

Now I am happy to find the mount can be parked/unparked and slew to a position which appears to be accurate. This is west of Greenwich which I understood to have been an issue previously. This means I can stay with Ekos and will have an imaging session one fine night to try it out more fully.


[edit 1]
I went to the indi computer to get some file examples for Henry and did not find things as remembered and outlined above regarding initial conditions and the xml file. Once again did not find the cold start buttons to be stored in the file, but it did seem to work allowing park/unpark. Will update when I have time to try again.

[ edit2 ]

A simple test:

The Startup: cold/warm state is not stored in the xml file and that might be intentional in that they are operational and not meant to indicate a state to be preserved and used across invocations.

My system starts with Ekos indicating unparked. The indi panel parking buttons look identical with the parked/unparked state seemingly undetermined.

The Park button does not change anything.

Pressing INDI startup cold button will change Ekos Parking field to Parked and INDI also to parked.

Then pressing the Ekos unPark button will change Ekos to unparked. INDI will issue a warning "Status unparked, park first" Red LEDs on Parking and Unpark from fields. TheParking field is indicating Parked.

Now the Ekos Parking Park buttons blinks when pressed but does not changed status.

INDI message "Telescope already parked."

At this point the cold/warm start buttons do not help.

Henry,
See if using the cold start button in the indi panel allows you to unpark the mount.

Thanks Wotalota. I will give it a try.

I wonder if it is of value to monitor the serial communication between PC and mount on a functional Windows set up and see how the Windows driver initiate the mount? It is something I can potentially help with if it will help the driver development.

The mount initialization is well understood I think. The recent updates have always seemed to hint of confusion between the state between Ekos, INDI and the mount.
Doubt we can get far at this time without some fixes, see the second edit I am about to make to my previous post.
/Tom

I have gone through all six pages of posts in this thread. In the middle of this thread there is some comment about the park and unpack state at first boot up. I have come across an PDF from astrophysics which states that for firmware version S and before, the mount will immediately begin tracking upon start up, whereas after that version the mount will not track until it is told to do so. It also states that when you just turn off the mount without parking first the mount will store its current position and on power up resume from the same position. I wonder if this explains some of the confusion mentioned in those posts...

astro-physics.info/tech_support/mounts/p...ositions-defined.pdf

Hi wotalota (/Tom),

I just noticed this thread is active again and read your posts from about 3 weeks back onward. At present my AP900 mount is not working and has not been so for several months. The declination motor encoder feedback is not working and thus I need to replace the motor assembly (they are a matched motor/encoder assembly when built). The motor and static discharge protection circuit will cost $625 + to replace and as such I have not yet repaired it.

When I was last using my AP900 I was using it with the standard "Astrophysics" driver as written by Jasem. I was able to run successfully through the night with meridian flips and correct parking (Park 3) as well as use the Pulse Guide feature. The only issue I had with this driver (as memory serves) is that if the mount was already initialized and I did a "Warm" connection then I would have to go and click the "Default" park button in the INDI driver, otherwise it would not park to Park 3 correctly. This is not needed on the first initialize ("Cold") connection as the Park position is not modified. I had intended to log this and send a report, however my mount died before I was able to run the tests. Otherwise the standard driver worked perfectly throughout many all night sequences.

I am uncertain my next step with the AP900 as I may sell it after I repair it or possibly convert to Onstep. I absolutely love my AP900 mount, however my last communications with Astro-Physics as regards any help in developing an open source driver was met with outright antagonism. There apparently is a great dislike and distrust to open source (or at the very least a great misunderstanding about open source) that I was wholly unsuccessful in affecting. In all other ways my dealings with Astro-Physics have been exemplary. They make awesome mounts and telescopes and provide very good help and service for their equipment. There is still an outside chance I may keep the mount after repair, however I have spent a great many hours (days/nights) with Jasem, Mike Fulbright, wildi, and others (thanks to all their work and efforts) over the last 4 years or so in trying to get a good driver for this mount. Alas, it has been a hit or miss ride with far too many misses to suit me, notwithstanding the excellent work of all those developers involved. My best overall "long term" use has been with the recent standard "Astrophysics" driver as authored by Jasem.

I am not certain as to when I will get my AP900 repaired and as such I am getting some of my other equipment out of a many years long storage and preparing those for use. I wish you and all others involved the best on your efforts to correct the driver.

I sold my Mach1 for those exact reasons and moved to a mount solution which had an open source solution which was supported by the manufacturer. If you have the means and skills to convert it to OnStep that could be a great route and most likely much more productive than relying on Astro-Physics to ever be helpful with an open source project.

I like my AP mount and telescope too much to give them up. Before AP I had iOptron which was far from satisfactory and an NEQ6 which was a lot better but still not the same league. So I will just have to suck up and keep using Windows until an open source driver becomes available. Disappointing I know but imaging time is too precious to be wasted due to mount issue and my AP is a keeper for this reason.

AP did say in a technical document (link below) they are prepared to give limited information to allow Mac/Linux users to make something useful. Certainly they gave info to the developer of SkySafari and Luminos such that those iOS app can drive the mount. So may be there is hope?

astro-physics.info/tech_support/mounts/q...t-workflow-guide.pdf

They are great mounts and worth hanging onto - hope things work out!