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

Read More...

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

Read More...

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.

LX200AstroPhysicsExperimental::updateTime entry

I'll look at that tomorrow because I did not find any traces that method UnPark has been called.

Kind regards, bye, wildi

Read More...

Hello Dahu

Regarding the timezone


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.

it happens ... or not


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.

Maybe a "if (dx < 1e-3 && dy == 1e-3) " parking condition may fix that,

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

Read More...

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

I do not see any messages in the INDI driver window about initializing.


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

Kind regards, bye, wildi

Read More...

Hello Dahu

- In step 5.2, when writing the park position data, the driver returns a "Can not change park position while slewing or already parked...".


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.

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


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

Read More...

Hello LinuxUser

I'm digging into your logs today.

Kind regards, bye, wildi

Read More...

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

Read More...

Hello Dahu

maybe, this GUI may be run from a hardcoded location

Yes, of course, it fetches the drivers from /usr/bin if not otherwise told.

1 Is that considered as negligeable or not ?

Since I never saw that please send me the log. Did you read that on the driver's GUI or are these values from e.g. KStars?

2- Also, in step 2, I see a 15 min difference in the sidereal time.

This might explain the position difference seen under 1. If sidereal time is wrong, then every position is wrong. Sidereal time depends on location an time both obtained from KStars. I often saw differences of several 5 sec but never 15 minutes. That can be clarified looking at the log.

3- And when I run step 6.1, the mount moves by a few degrees.

In step 4) the mount is moved a few degrees and in 5) Main Control 6.1) Parking Park(ed) the mount moves back to where it started after unpark.

Just in case in you have to redo the log, specify under Options all levels.

Thanks for testing, kind regards, bye, wildi

Read More...

Hello Dahu

I welcome any location and report, thank you. This time I specifically wanted feedback for the park positions.

I'm disturbed by your remark that you did not see the Startup Cold, Warm buttons. I attached a screen shot.

Script cold_start_part1.sh copies finally the files to $HOME/indi_cold_start/build and there in you have to execute

./indiserver ./indi_lx200ap_experimental

After that connect with KStars. There is no need to execute cold_start_part1.sh if you can

cd $HOME/indi_cold_start/build

Please let me know your findings, kind regards, bye, wildi

Read More...

Hello LinuxUser, Midwest Astronomer and

thanks for your feedback ! The most important information for me was if the local sidereal time has been read back correctly.
LinuxUser, running INDI as root is not necessary - I usually run it under default UID pi.

The below listed procedure can be carried out indoors and it really moves the mount. Please use the previously posted script can be carried out indoors to fetch, compile and run it.

Many other INDI mount drivers do not have the feature park to and unpark from and unpark immediately. Since unparking from a invalid park position is not the best idea I adapted the cold/warm start feature found in lx200ap.cpp (and removed the driver config read item). If there is no or an invalid ~/.indi/ParkData.xml one must perform a cold in all other cases a warm start. Only after that unparking is possible.

This driver is made for firmware versions D and V. I limited that artificially in order no tube hits the pier. Please contact me if you have a different version.

I'm happy to hear from you, kind regards, bye, wildi




0) power up the mount and bring it to park2 position (Az=90, Alt=0), mount points to the Eastern horizon on northern and southern hemispheres

1) Main Control
1.1) Connection Connect
1.2) Startup Cold
1.3) see Unpark From? and Park To? having the values Park2
1.4) Parking Unpark(ed)
1.5) see Hourangle Coords HA = -6, Dec = 0
1.6) see mount icon on KStars near the East point at Alt = 0

2) Site Managment check if AP sidereal time is correct against e.g. stellarium

Only if so proceed

3) KStars, select a star 5 deg above East point, goto, check if mount's movement was correct.

Only if so proceed

4) Main Control
4.1) Park To?, Park2 (even it is selected)

5) Site Managment
5.1) see Park Position AZ = 90, Alt = 0
5.2) Park Options, Write Data (park position can not be set while parked)

5) Main Control
6.1) Parking Park(ed)
6.1) Unpark From?, Last Parked

7) Options, Configuration, Save

8] Main Control, Connection, Disconnect

9) Kill and restart the indiserver/driver (the ount is still powered on)

At this point we have a valid ParkData.xml and the mount is at park 2 position.
A) Main Control
A.1) Connection Connect
A.2) see Unpark From? with value Park2
A.3) Startup Warm
A.4) see Unpark From? with value Last Parked
A.5) Unparking Unpark(ed)
A.6) Park To? Park3

B] Options, Configuration Save

C) Site Managment
C.1) see Park Position AZ = 0:06 northern hemisphere or southern AZ = 179:54, Alt = your latitude
C.2) Park Options, Write Data

D) Main Control
D.1) Parking, Park(ed)
D.2) Connection, disconnect (after mount parked)

D) Kill and restart the indiserver/driver (the mount is still powered on)


I) Main Control
I.1) Connection Connect
I.2) see Unpark From? with value Park2
I.3) Startup Warm
I.4) see Unpark From? with value Last Parked, Park To? with Park3
I.5) see line (my latitude is 47.6):
[INFO] Driver's config 'Unpark From ?' is set to 'Last Parked': will unpark from Alt=47.563900 Az=0.100000
I.5) Unparking Unpark(ed)
I.6) see Hourangle Coords HA = -5.59:51, Dec = 89:55:57

That's it.

Read More...

Hello

I have a version of the lx200ap_experimental driver that works with GTOCP2 version D and GTOCP4.
The below listed procedure has been tested East of Greenwich and hence people West of it are specially invited to carry it out.
People with a GTOCP3 or with GTOPC2 version above D please contact me.

In order to simplify a test I attached the bash script cold_start_part1.sh which fetches, compiles and starts the indiserver/driver
in $HOME/indi_cold_start/build and it works on x86_64 as well on RPis.

My repo is here: github.com/wildi/indi/tree/ap_park3


Either you create a local profile in Ekos or connect with KStars, Device Manager, Client localhost/7624.

As a rule of thumb, if anything does not follow your/my expectations, please stop. The Abort Motion, Abort button works :-)
but it will not be necessary because during this test the mount will not be moved. It can be carried out indoors.

First thing the cold_start_part1.sh must work.

The procedure is independent of an (not) existing ParkData.xml or driver's config file.


1) Power on the mount and locate one of the markers at the RA circle and remember its position.
2) Start Ekos/INDI and connect
3) Tab Option turn on the logging
4) Tab Main Control, see

Connection: Connect (as usual)
Driver config: Read

The latter reads the dirver's config file and ParkData.xml before one can Unpark(ed)

5) Connection, Connect
6) Driver config, Read
7) Set Unpark From?, Park2 (if not set so)
8) Set Park To?, Park2 (if not set so)

At this point, AP icon on KStars may be displayed at any location, ugly but unavoidable.

9) Press Parking, UnPark(ed) (only a sync happens, no movements)
10) see HA = -6:00:00, constant
RA : increasing every second
check if the RA circle marker is still at the same position

11) must see: AP icon exactly at az=90, alt=0, no movement
(During startup I stop tracking at the earliest possible moment)

12) Tab Site Management, check
Firmware: your firmware
ap sidereal time: is it correct within a few seconds with e.g. stellarium
AP UTC offset: your TZ offset including DST

The most import point is the sidereal time. If it is not correct, do not proceed.


13) Tab Motion Control, check your settings
in case file ~/.indi/AstroPhysics Experimental_config.xml
was available.
If it was not there: set your preferences followed by
Tab Option, Configuration, Save
14) The mount is still unparked:
Set Unpark From? to Last Parked
15) Tab Site Management, Park Options, Write Data
16) press Tab Main Control, Parking, Park(ed)
17) press Connection, Disconnect
18) check if the RA circle marker is still at the same position
19) kill the indiserver/driver

20) leave the power on

21) start ./indiserver ./indi_lx200ap_experimental
22) Connect with EKos/INDI
23) Connection, Connect
24) Driver config, Read
25) see
Unpark From? Last Parked
Park To? Park2
26) Check log window, see:

2020-07-27T16:01:22: [INFO] Driver's config 'Unpark From ?' is set
to 'Last Parked': will unpark from Alt=0.000000 Az=90.000000
2020-07-27T16:01:22: [INFO] Mount is parked

27) Press Parking, UnPark(ed)
28) see HA = -6:00:00, constant
RA : increasing every second
check if the RA circle marker is still at the same
position like at the very beginning

29) Press Parking, Park(ed)
30) press Connection, Disconnect
31) kill the indiserver/driver
32) Power down the mount

After I received (positive) feedback from people on the Western hemisphere I'll go on with the un-/park procedure and how to check if the meridian flip occurs at HA=0h +/- few seconds (typically the difference of AP and real sidereal time).

Those who ar used to see Unpark From? before connecting may ask why I changed that. In case no ParkData.xml is present or more likely the position therein is not valid an unpark from last_parked will surely fail. In addition I wanted to show a message in the log window where from the mount is actually unparking.

Kind regards, bye, wildi

Read More...

Hello LinuxUser

The reason why I'm behind my schedule is that I was "thrown" into a new project at my day job.
Un-/park and meridian flip at HA=0 works and I'm thinking more about the init process. E.g. I'm
using GTOCP2 with the experimental driver and I like to hide pulse commands.

Again, I hope at the end of this week I'm done so far that the driver is testable.

Kind regards, bye, wildi

Read More...