Hello LinuxUser

pier side is back. You can use script cold_start_part1.sh to fetch/compile it from my repo.

You wrote that you completed the procedures successfully. Beyond that did you observe any failures/glitches?

Michael Fulbright's version worked only West of Greenwich but not East as Spartacus pointed out in this forum. Since files lx200ap.cpp and lx200ap_gtocp2.cpp contain the same error:

if (setAPUTCOffset(PortFD, fabs(utc_offset)) < 0)

I'd like to clean up the code and unify the driver for all GTOCPX and firmware versions (I still use D) as my next task.

Concerning renaming/checkout an earlier version I can not do much. That's up to Jasem. But if the current bleeding edge driver does not fail I'm recommending to keep it.

Kind regards, bye, wildi

Hi Wildi,

Thanks for adding pier side back to the driver. I'll use your script as usual, fetch/compile and test. I will run with logs and note any difficulties if I have any.

I understand that Michael Fulbright's version does not work East of Greenwich, however in order to get some imaging done I went back to what works for me here until your new driver is at a working stage. I will also fetch and compile the latest bleeding edge KStars/INDI and test with your driver there and let you know how it goes. I have SD cards specifically for this type of testing so I can keep my "production" version as is.

I hadn't realized the Greenwich/UTC error was in other lx200 code bases, however this would follow since the Experimental driver hooks to the lx200ap code set. It is good that you are cleaning and unifying the driver.

Jasem mentioned in a reply to me in another post here indilib.org/forum/ekos/7460-kstars-3-5-0...ion-issue.html#58121 about your driver merge in Git so as mentioned above I will also test this. Again, you are correct that if this bleeding edge driver works then let's keep it.

Thank you!

Hi Wildi,

I tested the latest Git including your driver there. The logs are attached. Here is the test and outcome:

1. The mount is turned on and ready. The bluetooth to serial interface is on and connected to rfcomm0.
2. I select and start my test profile in Ekos (Astro-Physics Experimental driver and simulated CCD)
3. Then connect to the profile which connects the mount and CCD
4. The driver connects and properly identifies my GTOCP3 and V2 firmware
5. On my first start I do a "Cold" initialize
6. Set unpark from as Park 3, set Park To as Park3
7. Try to unpark the mount and just get error message about parking first, etc. (see logs)
8. After several attempts I am unable to proceed. Cannot get past the error messages.
9. I did try to do a goto several different times, however the mount just did not move.
10. Perhaps the mount is not initialized properly or ? (I do not see any messages in the INDI driver window about initializing. I do get this feed back from the old driver such as mount initialized and the site location and time was sent to the mount.)

I wasn't expecting this fail since my earlier tests on your driver completed OK.

I did not test your latest driver with the pier side information added although I did pull it from your Git using your script.

I hope the logs will help to identify what is happening.

Hi Wildi,

I have re-run the entire test sequence #2, and things go better as, this time, the driver sidereal time was in sync with some independent sources. I cannot figure out what is different from my previous test run that may explain that fact. Kind of a mystery for me.
However, I still see 2 glitches :
- In step 5.2, when writing the park position data, the driver returns a "Can not change park position while slewing or already parked...". Despite the mount was not slewing nor parked, it was in tracking mode.
- After the last step (I.6), I parked the mount (to Park3) just after having unparked it from the 'Last Unpark" position which was supposed to be the Park3 one. So I was expecting the mount to move for a tiny movement, but it slewed by a few degrees (5 or 10 degrees, hard to evaluate precisely). May this related to the issue I got in step 5.2 ?
I attach the 3 log files (with full options) for each 3 sub-test sequence in case that helps.
Thanks for your time and dedication,

Dahu

Hello LinuxUser

I'm digging into your logs today.

Kind regards, bye, wildi

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

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

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

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

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.

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

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"