linuxUser, Thank you for those insights. Because I have not been able to image for some time but have been updating, its hard to pin down when it went wrong. Seems to have been between 3.4.2/1.8.5 and 3.4.3/1.8.6. I do not have a hand controller also would have to learn a lot more about git to attempt to go backwards.
I was wondering about trying to change over to the nightly build to see if anything was better, but seek boring predictability more than anything else so I would rather not.

Did you also see a change in how the mount initializes? It always started up un-parked and tracking. Now the driver indicates it is parked and not tracking.
/Tom

Hi All,
The "old" astrophysics experimental driver never worked for us in Australia. The mount always was 4hrs out in HA. This was due to UTC setting problems. So we are in Brisbane but the mount thought it was in Kiribati. Parking never worked due to these issues. I can only presume that this was not identified due to the driver not being tested by any Australian users? However, I appreciate, for the majority, this driver did work. At that time we just gave up on KStars/indi for AstroPhysics and used The Sky/SGP/ASCOM.

The latest iterations of the experimental driver, that Wildi is working on, are constrained by issues around the Lx200generic driver. (I am not an expert but I think that is why a previous working version was not committed to stable).
The version that I used a few nights ago appeared to work well so I have locked that in as my current AP driver but I have also experienced the mount not unparking as described by Linux user. So there are still problems to be worked through. Wildi is also trying to provide a unified driver that works with all versions of the GTO controller.

IMHO I would advise that the driver is rolled back to the Michael Fullbright version in the stable version of KStars so that at least the majority of users will have a functional system. I note that the latest indi driver update 1.8.6 does describe modifications to the Astrophysics driver. Although it looks like you have this already. I have not updated since this came out so cannot comment on it's functionality.

I have been having a number of other problems related to the kernel update to 5.4 and as a result I ended up on the 4.5.0 beta and found the Astrophysics driver unusable. Wildi has done months of work on the new driver and is working through the problems, so it is important to continue to provide testing of his iterative changes.
However, testing is testing but until this is sorted so that all users find it functional, we should be using the "old" astrophysics driver as the majority of users are reliant on its stability.
It would be nice to have an easy way of rolling the current driver back to the old version to avoid too much frustration.

In the meantime I do thank Wildi for all the time and effort spent so far. and am happy to continue testing to get a reliable driver for all users.

Mike

Hi Tom (wotalota),
I have not pinpointed the exact INDI version as to when the Astro-Physics Experimental driver changed, however I do know from about 3.4.2/1.8.5 (or 1.8.4) time frame onward it has not worked properly for me. I can say that a version of KStars 3.3.7 from last fall works fine, not sure what INDI version it is running. I have an old Pi3 SSD with this on it. I'll try to check what version INDI is there in the next few days.

Indeed I have also noticed the Experimental driver used to initialize and start with the mount un-parked and tracking and does not now. Instead it indicates parked and not tracking as you describe.

As mentioned in my last post, my recent testing of Wildi's driver has my mount tracking and pointing as if in the southern hemisphere. After reading Mike's (Spartacus) post and noting he is in Australia there may indeed be a direct correlation to why my mount was working as if in that hemisphere. I couldn't say directly without better troubleshooting and diagnosis, however ..... (EDIT) to clarify, this behavior is with the current driver in Git. I have only done limited testing with the driver pulled directly from Wildi's branch so I do not know if that driver/branch exhibits the southern hemisphere issue, even though my GTOCP3 controller is set for northern hemisphere, etc.

Hi Mike (Spartacus),

I do hope that Wildi can get the driver sorted out soon so it works for everybody around the globe and certainly appreciate all his work. Indeed I have spent a good deal of time testing his driver. Now that I have my mount back on the pier it is harder to get out to do the testing, however I still do test as time permits and hope to be testing the pier side function in a few days.

AGREED - the Astro-Physics Experimental driver should be rolled back to the working Michael Fulbright version, which seems to be from summer/fall of 2019. In recent KStars/INDI releases that driver is broken. It certainly has lead to a lot of lost imaging time, which we get precious little of here anyway, and a great deal of frustration (I am being kind in my remarks here)

Hi,

If you have a version of KStars saved from 3.3.7 you can exchange the indi_lx200generic and indi_lx200ap_experimental drivers from 3.3.7 to your current stable version (you need to create a symlink between the lx200generic and the experimental driver) and get your system up and running. As I said, I did this for one of Wildi's new drivers that worked like a dream and have had no problems since with this as the only change from the current stable KStars. The only caveat is that if you update it is likely to revert to the current setup and therefore become unusable.

Mike

Hi Mike,
As in your post and thanks for the suggestion, however:
I tried doing just this some weeks ago, but those drivers were referencing "libnova -0.14.so.0" and the current library is "libnova-0.16.so.0.0.0" so I also created a symlink for "libnova -0.14.so.0" which pointed to "libnova-0.16.so.0.0.0" (in the "/usr/lib/arm-linux-gnueabihf" directory if memory serves) and I still ran into problems getting that to work, however I do not recall all the particulars. SO after some time spent on this I moved on to other tests and tries until I am now using the "Astrophysics" (standard) driver with the caveats as described above. Thanks for the suggestion however!

Hi Wildi,

I have not had opportunity as yet to test the pier side functionality in the driver. At this point I am not sure when I will be able to return to testing. Please continue onward and thanks for your work on the driver.

Hello all

before I continue I'd like to say thank you to all contributors.

I was quite quiet during past about 10 days because I can not understand why "suddenly", after power on the AP mount, the controller is not in state "P" (parked). Status "AP parked" has nothing in common with "INDI parked" although they should be congruent/coherent. "Suddenly" is a synonym for that, that Mike, who carried out the tests between April and July, never observed such an event now clearly seen in the logs at various occasions but not always.
An intermittent failure is a nightmare for every observer as well for me. Since the very first reading of the status was "not parked" there was no possibility
"to park first, before unpark". I'll go through the init process again and try to isolate the cause. This can be done without clear skies.

INDI Park(ed)/Unpark(ed) vs. AP parked/unparked:
I studied the current and the celestrongps drivers and found, that they unpark finally unconditionally although there is a ParkData.xml involved which may contain in- or valid park status and coordinates or even is not present. At startup earlier versions let the mount track until RA motor stalls, e.g. hitting the pier, now the mount is stopped at the very beginning (not yet thought about a power cycle of the whole observatory during an ongoing observation). Jasem introduced in driver lx200ap the concept of warm/cold start. It is for me the link between AP controller park and INDI logical park status. Or in
other words, if anything goes wrong during unpark, a cold start is required and setting INDI status accordingly. So far I assume if something went wrong during unpark the fix was a manual sync. A process I feel uncomfortable.

I'll go on with the development of this driver, even if the consensus is to roll it back to Mike Fulbright's version, since it can not be that AP has, a proprietary, unified driver and we not

Kind regards, bye wildi

Wildi,

You are doing a great service and I hope you will continue to work on improving the AP driver. When I started tinkering with it in 2017 it would work for visual imaging but it didn't integrate well in a modern automated imaging setup with plate solving, etc. So I tinkered around to get it working to the point I could image all night unattended. But you notice I had the word experimental added because it was all new ground for me and wanted it to be clear to potential users I had not and could not test all use cases. I believe what you are doing now fits under that declaration.

I say keep going with your driver and don't roll back. I'm not going to be maintaining the old code any more as I sold my Mach1 and moved to an open source OnStep system because AP has been dragging its feet publicly releasing modern documentation for their mounts. I'm done using proprietary solutions as much as possible. Now I only have to rely on the binary blob from ZWO for camera and filter wheel and everything else is openly documented hardware. I'd love to get rid of that dependency but that is another topic...

As for people who were using my old driver I would say just freeze your software stack for now and use what has been working for you.

Wildi will get things working better than ever with the good feedback he is getting here.

Hello Mike and all

of course I'll continue until the driver is usable for most/all of the INDI users. Until then I agree with your proposal, that the "Westerners" freeze their stack.

Since there is a larger variety of KStars//INDI driver combinations I'll address the INDI forum members step by step.

Closed source controllers, produced in comparable small quantities, are problem for their users. I never understood why turning a gear at an angular speed of 86164/86400 rad is such a big affair (of course there are more things to set/maintain). Since I'm not the hardware guy OnStep is way out of this calamity.


Kind regards, bye, wildi

"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?