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!

Indeed Mike, the AP mounts are worth holding on to! My AP900 would make a great candidate for converting to OnStep. I have done some preliminary testing of OnStep using a WeMos R32 with CNC V3 Shield following the OnStep wiki and it went well. I will use this setup to convert my Vixen GP/DX mount to OnStep for which I have most of the parts now except some belts and pulleys.

I have ordered a MiniPCB2 kit from George Cushing and will begin the assembly soon. This is intended for the AP900 provided the GP/DX proves out OnStep well enough and I am sure it will based on my reading of the OnStep wiki, build examples, and forum, etc. The DEC axis drive failure on my AP900 certainly accelerated my desire to look into OnStep as an option which was also supported by what you and others have said about it. I may repair the mount with AP parts, however I do not feel any great need to, which is one reason I haven't done it already. I frankly prefer to just fix it myself with available off the shelf hardware/software components which will free me from vender dependence. I have done so in the past with the laser engravers that I designed and built for my engraving business and so I am no stranger to the task. The big issue is dealing with mounting the stepper motors with the existing worm mount. I do have some ideas I am looking into. I just need more time to work on the project as usual.

At present I am working more on readying my older yet not much used LX200 Classic from storage. I have been wanting to get that scope back into service anyway. A new challenge to be sure but worth it I hope.

I played with OnStep on a G11 mount and it is a nice project. With the TMC stepper drivers I used it slews faster than the Mach1 could and is absolutely silent - can barely hear it 15 ft away. I was always worried the Mach1 would wake someone in the middle of the night.

@Mike - the Onstep is very interesting. I am a tinkerer with some electronic, 3D printing skills, and have previously built various circuits including my own dew heat controller using ESP Wifi Arduino. Therefore I am quite tempted to give Onstep a try - sounds like I can get a lot of what a CP4 or CP5 can do at a fraction of the cost. The difficulty though I suspect, with a project like this, is the lack of documentations - I do not know what stepper motor or geared motor is in my Mach1, and I also do not know the pin out of the various connectors. I suspect this is going to make it hard to adapt Onstep onto the Mach1., and potentially risky.

Hi HenryNZ,
In answer to your initial inquiry about using your mount with KStars/Ekos I suggest you use the standard "AstroPhysics" driver. I used this driver with my AP900 GTOCP3 very successfully the last several times I was able to image before my mount went down. In general it will work fine from Park 3 or any park position you define with the exception of a "Warm" initialize as I described in my previous post a couple days back as following:
- "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." -
In using the "AstroPhysics" and NOT the "AstroPhysics Experimental" driver I was able to get back to imaging all night with a programmed sequence and everything worked as expected including meridian flips and parking. I would program the sequence and get some sleep until the sunrise. Just follow what I said above if your mount is already initialized, either previously from a "Cold" start in KStars/Ekos or from your hand controller if you have it and initialized that way. If you have a GTOCP4 it will work the same as the GTOCP3 with this driver.

For details on using the standard or "legacy" driver see this section (even though it states to use on older GTOCP2 controller I had great success with my GTOCP3. The CP4 should also work the same.) :
indilib.org/telescopes/astrophysics/astrophysics-legacy.html

In answer to your last question to Mike, which I am sure he will respond to, the motors in the Mach1 and all Astro-Physics mounts made in the last 20+ years are servo motors and not stepper motors. Stepper motors and servo motors are controlled very differently so you would have to switch out the motors as well as the controller (OnStep in this case is designed to drive stepper motors). In addition the power and torque curve of these type of motors are essentially reverse i.e. steppers have the greatest power and torque in the low RPM region while servos have higher power and torque in the higher RPM region, This leads to a need for different gear ratios as well. This is a very general comparison between servos and steppers and may not hold for all cases, however ... etc. In any case it would lead to a challenge in getting the motors sized (to a matching size in this case (around NEMA 11 I think) if you are to use the existing motor and worm mounting blocks), gear ratios matched for acceptable performance and so on. Not impossible but does need a bit of planning and testing. So your suspicion of the difficulty in adapting the Mach 1 to OnStep is correct. It is certainly achievable but has to be weighed against many variables, each of which are dependent on the individual.

All that to say - try the standard "AstroPhysics" driver until the experimental driver is finished as it is currently being addressed per /Tom (wotalota) as seen in his posts. You can always to an indoor simulated run while testing the standard driver if your system is available. I hope this information will be of help.

Thank you LinuxUser. I will give it a go next time.

Apologise for the noise but I have to reverse myself again. Today I am back to being able to control the mount.
To be brief. Mach1 VCP4-P02-08, 1.8.8, 3.5.1 stable.

Before running I look at the .indi xml files.
Telescope: Park position = 2 (weights down, telescope facing east) unpark from = last parked.
ParkData: Park Status = true, park position = 2.
Both as expected.

Power on mount
Start KStars & Ekos/INDI using the GUI interface.
INDI panel Park To selection is blank with red LED. Select Park2 and save
Use the INDI Startup: cold start button
This establishes the initial conditions to be Parked with Tracking off. Ekos and INDI panels are in agreement.
INDI select unparked, Ekos also changes. Use Ekos to select parked and INDI also changes.
Select unpark and turn tracking on. Via KStars slew to nearby object. Park scope.
This sequenced worked.

Since the previous driver default unparked conditions was tracking, any suggestions on how to setup for the scheduler?
I have to pre-setup the mount using the cold start button? I did not see a way to have tracking start when changing from parked to unparked, or after slewing to a target. So do I also have to leave the mount unparked and tracking, selecting a target that will still be safe when the scheduled time arrives?

Items to be looked into.
- Why the INDI `Park To' field is lost from time to time.
- Why enabling verbose logging to file appears to prevent the mount indi options save button working if that is still true.
- How to automate the cold start, unpark, track sequence.

Hi Henry,

I can confirm that the current Astrophysics experimental driver does work well in the Southern Hemisphere (Brisbane) in the following setup.
RPi4 running Ubuntu Mate 20.1 and using the current KStars Nightly build (now locked in). The mount is Astrophysics GTO1100 with the the CP4 controller and V13 firmware. The connection to the Pi is direct USB2 with no handbox.
If you have been trying some different configs I would suggest that you open the /.indi folder and delete the Astrophysics Experimental_config.xml file in order to start afresh.
Plug the mount into the RPi and powerup the mount. Start KStars and EKOS and start the profile that you have created for the mount (just for testing keep this simple and just use the mount and a CCD simulator.) Make sure that you have set your geographical co-ordinates in KStars settings and tick the "KStars updates the mount" box.
As has been mentioned before you could disable verbose logging if this interferes with the buttons (cold and warm)
Start the driver profile and open up the Astrophysics tab in the indi gui.
Do not unpark yet!
Go to the "unpark from" and set this to whatever your mount is current set at (Park 2 or Park 3 seem to work for me) make sure the mount is at the position that you set for "Park from"
Go to "Park To" and set whatever you normally park to (usually Park 3 for me).
At this point do not worry about where the mount appears on the KStars planetarium
In the indi gui click the cold start button.
Make sure that the "park to and from" values have not changed
Now click on unpark and track in the EKOS gui (or the indi gui)
Your mount should not move at all but should start to track
Now go to the Site Management tab in the indi driver and click on write data to save the parking co-ords
Now you should be able to do a test slew by clicking on a point relatively close to the current mount position be ready to stop the mount in case it flies off in the wrong direction
The mount should slew to the desired point on the planetarium.
Now go to the options tab in the indi mount gui and click "save config".
Now try parking but just check that the indi gui shows your desired parking position.
Press "park" in either the indi or EKOS tabs and the mount should park OK.
Try disconnecting the mount, close down the program then restart and connect again.
Your information regarding parking positions should now be retained for "park from" but is unlikely to hold for "Park to" so always remember to set this before you unpark and save the config but you will have to click on cold start in order to be able to unpark and continue as before.
If for any reason the cold/warm start buttons dont work just disconnect the mount then reconnect and select cold start to allow the unpark to work
It's not perfect but it is workable once you understand the limitations.
Previously the mount would always try to park as if it was in Kiribati for me in Brisbane and this made it always 4 hr out of sync so pretty frustrating. Wildi's hard work on this driver has given us a very workable solution and we thank him for all the hours he has put in!

BTW I tried the editing of the xml file as suggested above but both cold and warm buttons stopped working so I have stayed with the situation as described above.
Hopefully this makes sense and will get you on the right track.

Mike