×

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: 59
  • Thank you received: 19
Hello Dahu

I found this message only in log file with timestamp 154110. To your surprise the driver was indeed still in state SLEWING although I'm sure you could not see any physical movement. In the log

DEBUG 131.307478 sec : Slewing... currentRA: 19.1491 dx: -0.000361111 currentDE: 6.43194 dy: 0

dx is always non zero while dy is. Looking at the condition when slew is considered complete:

// Wait until acknowledged
if (dx == 0 && dy == 0)

If important: this line is still and was there before I began (see commit 91438a0eda6d87bce96b06afda9ce2432b52f475). What me makes feel uncomfortable are the lines

double dx = lastRA - currentRA;
... a bit further down
lastRA = currentRA;


which indicate "noisy" value(s) at every readout. The dx values corresponds to about 19.5 arcsec.


In the logs I find only unpark/park from/to park 2 (two).

Reading file 154110 I conclude that there was no valid park data present (ParkData.xml) and the mount unparked from park 2 (Az=90, Alt=0, RA = 19:42:16 Dec 0:00:00). Then a slew started to RA=19:07:47 and Dec = 06*25:55. When you say "tiny" what did expect?


I found the line

Set UTC Offset 0 as AP UTC Offset -0 is successful.

Since you live in CET/CEST this value must be -2 currently. On what kind of computer is the driver running? Did you set timezone correctly? Was AP's sidereal time correct?


Could you please post the log file of Ekos, because there is the absolute date/time available instead of the relative as it is in the drivers log. That helps me to debug time zone issues. You'll find it under .local/share/kstars/logs.

Kind regards, bye, wildi
3 years 7 months ago #58285

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

  • Posts: 59
  • Thank you received: 19
Hello LinuxUser

I checked the log and found that that the status read back from the mount is from the beginning always

*1*99000210P000

instead of:

*P*00000210P000

The latter is the status Parked. Did you power cycle the mount controller before doing this test?
I checked the first mount status read out in about 70 log files and none has the above value 19...

If during Unpark(ed) an error occurs you'll see these messages and finally if it was successful, too.

Kind regards, bye, wildi
3 years 7 months ago #58293

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

  • Posts: 24
  • Thank you received: 3
Hello Wildi,

Thank you for having looked in depth at my logs. I have done some more trials.

Regarding the "Can not change park position while slewing or already parked..." error issue, it happens ... or not. I mean, either there is no error, and writing park data works correctly. In the opposite, if this error appears, then there is no way to workaround it, even by waiting for minutes hoping for the mount to "stabilize". I suspect that I felt in the "noisy" value trap. Maybe a "if (dx < 1e-3 && dy == 1e-3) " parking condition may fix that, or something similar.

For the Park3 final issue, I have not been able to reproduce it clearly. So we may forget about it.

Regarding the timezone, all my set-up (PCs, software, AP mount handset, etc..) is always set in UTC time. This simplifies greatly all the configuration. The AP sidereal time is identical to my software ones, no inconsistency.

Kind regards,
Dahu
3 years 7 months ago #58332

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

  • Posts: 59
  • Thank you received: 19
Hello Dahu

Hm, AP controller really expects local time it then calculates local sidereal time based on UTC offset. I assume that you have to perform an additional sync on a known star before you can perform a goto. I agree with you not using UTC in the context of astronomy is not the very best idea.

In the mean time I got from INDI forum member Spartacus two reports. He confirms the "it happens ... or not" characteristics of the unpark. Since I did not see that any time before I assume to sort that out is a matter of working on it.
Yes basically this will be the solution since in case of parking this condition

if (slewcomplete && (dx > PARKTHRES || dy > PARKTHRES))

with double PARKTHRES = 0.1 was/is already in place. But before I change that, I'd like to understand why it is not zero.

Kind regards, bye, wildi
3 years 7 months ago #58334

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

  • Posts: 311
  • Thank you received: 42
I have not been following this closely but post here in case something has changed in the stable release 3.4.3. Tonight might have been the first chance to image with this release.
I am getting the following error. I am west of Greenwich and the Astro-Physics Experimental has been working well for me for a couple of years.

[2020-08-18T19:10:05.748 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[SCOPE] CMD <#:Sd -13*47:49#> "
[2020-08-18T19:10:05.748 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[SCOPE] CMD <#:Sd -13*47:49#> successful. "
[2020-08-18T19:10:05.748 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[SCOPE] <Slew> "
[2020-08-18T19:10:05.748 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[SCOPE] CMD <:MS#> "
[2020-08-18T19:10:10.745 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[SCOPE] RES ERROR <-4> "
[2020-08-18T19:10:10.745 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "Error Slewing to JNow RA 18:19:58 - DEC -13:47:49 "
[2020-08-18T19:10:10.749 EDT INFO ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[ERROR] Slew failed. "
[2020-08-18T19:10:10.749 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[DEBUG] EXPERIMENTAL: check status... "
[2020-08-18T19:10:10.754 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[DEBUG] check_lx200ap_status: received bytes 6, [100000210P000] "
[2020-08-18T19:10:10.755 EDT DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[DEBUG] parkStatus: 1

Earlier there was some confusion whether the mount was parked or not at startup. The UI showed parked but selecting unpark gave measage: Telescope already unparked.
3 years 7 months ago #58367
Attachments:

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

  • Posts: 59
  • Thank you received: 19
Hello wotalota

RES ERROR <-4> means in INDI that there was a timeout. AP says in the protocol description that :MS# has not been accepted. Under these circumstances the controller does not send a response, hence the timeout.

I then checked if the controller is in parked or slewing status. That was not the case.
I'll look at that tomorrow because I did not find any traces that method UnPark has been called.

Kind regards, bye, wildi
3 years 7 months ago #58395

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

  • 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.

Time to create page: 0.896 seconds