"Until then I agree with your proposal, that the "Westerners" freeze their stack."

Any suggestions on how to go about doing that after already having accepted an update to the current stable release?

Wildi, Mike, Wotalota,

Wildi- definitely keep going and I look forward to when you get it working. I will continue to test and offer feedback as much as I can.

Mike - You are correct about freezing our software stack, however as Wotalota has pointed out, I too have updated the software since (see my thoughts below). I have also tried getting an earlier driver working but had problems with that (see some earlier posts on this thread).
I have also started looking at the OnStep system recently. Can you tell me what mount you are running that system on (please, pretty please)?
Sadly, my recent call to Astro-Physics just didn't go very well and any mention of open source software (INDI, KStars, etc.) was met with some hostility followed by a rant of software theft and then an argument to convince me the merits of Windows and Ascom. I have used them and know it works OK (sometimes) and like you I am done with proprietary solutions.

Wotalota - right I am in basically the same spot except for one case as follows below.

ALL - I have found that Michael Fulbright's version of the experimental driver is also broken in recent releases. I did find by luck an older SD card that works on a Pi3 (or Tinkerboard, I have to check this) that is from summer or fall of 2019 KStars version 3.3.7 that seems to work OK. To be sure I will have to setup to run some tests so as to verify the full working state of this earlier version since the later versions are not really usable and the reason why I began this post. In any case we do need a working driver until Wildi can get his work more complete and this might relax the pressure on Wildi as well.

1. The standard "Astrophysics" driver (not the Experimental Driver) - I am able to use this driver as long as I use my hand controller to initialize, however it does over wright my park position in the Parkdata xml file to all 0's. Can that be a quick fix? I need to test further if this driver can be used successfully without the hand controller since once I got it working with the controller I just started to image my target and never got back to further testing.

2. Owing to the weather and other pressure on my time for the foreseeable future what I can do is take my mount back off the pier sometime in the coming days and setup inside for some basic testing with hopes that will help in driver development and testing.

3. The Astro-Physics Experimental driver - once a working version can be determined it would be great to be able to get this back in the INDI stack - maybe as new name such as Astro-Physics Experimental-Fulbright or some such rename. Or whatever may work? Thoughts?

Please don't use my name in anything I am not working on the driver or INDI/EKOS these days.

What I do to freeze my software stack is create schroot environments that I run INDI/EKOS under. You can use hard linked and then not use much disk space to have several parallel environments installed. I always have a stable environment I never touch and then my development environments which can be at various states of broken at any time.

These days people probably use some new fangled gadget like a docker image to do something similar.

Mike,

You are quite correct, I should have thought about that:
My sincere apologies!

You may not have seen my question above - I have also started looking at the OnStep system recently. Can you tell me what mount you are running that system on (please, pretty please)?

Thanks!

No worries I know you mean the best. I did some work on the driver but I was just adding to the work already done so just doesn't make sense to call it after me as I just did some of the work.

I use OnStep on a G11. Works pretty well. But you need to have a bit of a tinkering mentality to use OnStep I believe. It isn't as plug and play as say buying an AP mount.

I think I'm back to something for the Mach1 I can use while the driver is being modified.

I did a build from current sources but into different bin directory. Then using github located the 4 lx200ap_experimental files from 1.8.5 replacing those in the local build area. After the build was run again, the indi_lx200generic binary was moved into the distribution's bin location.

The mount now starts up from cold unparked and tracking, Park/unpark and goto now work. Also KStars shows the correct location for the mount in the sky map. Many of the INDI panel's buttons are still dead, though I expect I will be able to edit the XML file to change settings in the meantime.

Now I suppose I should remove the PPA to prevent any updates.

Wildi,

I hope this finds you doing well. I am just following up to see how the driver re-write is going. I hope it is progressing well.

Until then I have been using the standard "Astrophysics" driver successfully with my GTOCP3.

Thanks for all your work!

LinuxUser,
If you still have your setup installed, I am getting signs of life here. Presently running EKos stable with INDI 1.8.8 but hopefully the same for a normal stable install. I running Mach1 with VCP4-P02-08 firmware.

To get the options tab, save and load buttons to work I needed to disable verbose logging in the EKos profile.

Options tab: Load and Save buttons not responding.
To reproduce. In the EKos profile being used, open "Logs" setting. Enable verbose logging
to file, along with some Ekos and INDI options selected.
In telescope INDI window the Debug levels, Logging Levels and Log Output entries will then
appear in the Options tab. At this point the options save button does not work.

Then needed to manually edit ~/.indi/AstroPhysics Experimental_config.xml to add an entry for the
cold start buttons:

<newSwitchVector device="AstroPhysics Experimental" name="STARTUP">
<oneSwitch name="COLD">
On
</oneSwitch>
<oneSwitch name="WARM">
Off
</oneSwitch>
</newSwitchVector>

Without the edit, manually selecting cold start first thing each time Ekos is started has the same effect.

Can now park/unpark, slew and return to park.

Hello all, I am new to this group and new to INDI. I am still mainly using Windows / ASCOM but I really want to switch to Linux and use CCDCiel or EKOS. To this end I have purchased a RPi4 and have it set up with all the software. However, on testing it seems that the mount is not working properly and specifically it seems to have problem parking and un-parking to/from Park 3. This is how I found this thread.

I am wondering if there is any update about potential fix for the problems with the driver? If one is not forthcoming in the near future, is there a workaround so that I can use my mount with INDI / CCDCiel? I do not mind parking and un-parking to/from a different position if that means it will work. If it matters, I am in New Zealand so I am east of Greenwich and also south of the Equator which I suspect will add to the complexity....

Thank you

--deleted -- duplicated

Henry,

I'm not sure the current status of the driver. I sold my Mach1 so I'm not working on it now.

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