×

INDI Library v1.9.9 Released (30 Nov 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Astro-Physics Experimental driver not working properly in KStars 3.4.2

  • Posts: 59
  • Thank you received: 18
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
2 years 5 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.
2 years 5 months ago #58865

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

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

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

  • Posts: 283
  • Thank you received: 35
"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?
Mach1, TS86SDQ, ASI071, ASI174, OAG, focusPro
2 years 5 months ago #58886

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

  • Posts: 77
  • Thank you received: 16
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?
Vixen 114ED
Borg 45ED (as guider)
Astro-Physics 900GTO with GTOCP3
ZWO ASI071MC Pro
ZWO ASI178MM (Guider)
Raspberry Pi3/Pi4
2 years 5 months ago #58898

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

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

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

  • Posts: 77
  • Thank you received: 16
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!
Vixen 114ED
Borg 45ED (as guider)
Astro-Physics 900GTO with GTOCP3
ZWO ASI071MC Pro
ZWO ASI178MM (Guider)
Raspberry Pi3/Pi4
2 years 5 months ago #58901

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

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

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

  • Posts: 283
  • Thank you received: 35
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.
Mach1, TS86SDQ, ASI071, ASI174, OAG, focusPro
2 years 5 months ago #59198

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

  • Posts: 77
  • Thank you received: 16
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!
Vixen 114ED
Borg 45ED (as guider)
Astro-Physics 900GTO with GTOCP3
ZWO ASI071MC Pro
ZWO ASI178MM (Guider)
Raspberry Pi3/Pi4
2 years 3 months ago #62257

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

  • Posts: 283
  • Thank you received: 35
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.
Mach1, TS86SDQ, ASI071, ASI174, OAG, focusPro
2 years 2 weeks ago #65890

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

  • Posts: 11
  • Thank you received: 0
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
1 year 11 months ago #67022

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

Time to create page: 0.886 seconds