×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Astro-Physics Experimental driver not working properly in KStars 3.4.2

  • Posts: 311
  • Thank you received: 42
There was a change in behavior some time ago. It used to be that when the experimental driver started it began unparked and tracking.
When running to test something else and not planning to image it was an irritation since I had to remember to park it or risk finding it a day later hitting the pier.
Now it starts up parked which I prefer, but perhaps that parked status was not really true. I noticed today that the indi driver UI indicates the expected Park2 position which matches the physical position of the telescope since last used. But KStars is showing it to be in the classic Polaris Park 3 position.

I'll see if unlocking the mount and changing to Park 3 will help reset things.

Thanks for looking at it.

Tom

Edit

Changing to Park3 did not help.

Changed physical position of telescope to Park3 position and set INDI panel settings to match.

Site Management tab Park Options buttons are unresponsive.
There was no entry for apExperimental in ParkData.xml, manually edited one into the file.
Options tab, Configuration buttons appeared unresponsive from a UI appearance. however later found changes are being written to "AstroPhysics Experimental_config.xml"
Other parts of INDI panels also not showing the usual UI response to button clicks.
The Polling entry only detects selection for change if click is made at very end of field up near the set button itself.
This is not unique to mount UI.

Restarted.
Site Management tab now UI responsive and indicates Park3 position. Ekos now consistent with KStars position.

Ekos UI indicates parked, but tracking can be enabled. Right click in KStars offers unpark as option.
INDI driver panel also indicates parked.

Selecting unpark in indi panel both the indi and Ekos buttons change to indicated unparked but indi
message is "already unparked".

Right click in KStars now offers Goto etc instead of park as options.

Attempts to move the mount still result the error "Slew failed"
Last edit: 3 years 7 months ago by wotalota.
3 years 7 months ago #58397

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
Hi wotalota,

I have had almost identical results as you describe and I have always used Park 3. The Experimental driver worked great for me until recent months. The last good release of the driver that seems to still work OK is from last fall. From about KStars release 3.4.2 onward I have had nothing but frustration from the Astro-Physics Experimental driver. I helped Jasem and Michael Fulbright test this driver some years back when Michael was working on the drivers and started the Experimental branch. Once settled it worked great for a couple years (approximately). I do not know why the driver has changed in the recent releases of KStars/INDI.

I hope Wildi can successfully update the driver, however I have lost a great deal of imaging time due to this problem.

I have recently moved to successfully using the "Astrophysics" driver with the caveat that I have to initialize with my hand controller and do a "warm" connection. I have to check the park position as well as this is getting reset to 00:00:00 in both axis so I set this to what Park 3 would be for me (the Latitude of my location and azimuth at 00:00:00) , save this and check the Park Data xml file. Not sure why this keeps getting reset to all 0's. So far that seems to be working OK, however I must say I no longer trust the driver situation and I now have to babysit the system most of the night. Just the last time I imaged a few days back I did finally "step away" for a bit after I set up a sequence and the scope did a meridian flip and parked successfully. I was connected remotely and watching things that way. Again this is using the standard "Astrophysics" driver and initializing with my had controller.

I have had far too unpredictable behavior with the experimental driver as is. For example the last tests I did several days ago while connecting and initializing the mount with the driver as I had done before left my mount RA clocking in reverse and pointing in reverse as if I was in the southern hemisphere. This exact behavior has happened while testing the driver several times recently. When I power cycle the mount and start using my hand controller and use the standard Astrophysics driver then it works OK as described above.

I hope nobody touches the standard driver except to start e separate branch and/or driver if they do. This is what Wildi has done with his work (using a separate branch). I am not sure why the recent problems and failures are occurring in the "release" version of the Experimental driver, I just know it is unusable as is.
Last edit: 3 years 7 months ago by Midwest Astronomer.
3 years 7 months ago #58599

Please Log in or Create an account to join the conversation.

  • Posts: 311
  • Thank you received: 42
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
3 years 7 months ago #58606

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 41
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
3 years 7 months ago #58607

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
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.
Last edit: 3 years 7 months ago by Midwest Astronomer.
3 years 7 months ago #58610

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
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) :-)
3 years 7 months ago #58611

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 41
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
3 years 7 months ago #58612

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
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!
3 years 7 months ago #58613

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
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.
3 years 7 months ago #58763

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 19
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
The following user(s) said Thank You: Michael Fulbright
3 years 7 months ago #58823

Please Log in or Create an account to join the conversation.

  • Posts: 105
  • Thank you received: 30
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.
3 years 7 months ago #58865

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 19
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
3 years 7 months ago #58878

Please Log in or Create an account to join the conversation.

Time to create page: 0.914 seconds