Hi,

I have an AZ-EQ5 connected directly via USB. (Synscan Controller is not connected as it seems to mess with the serial communication and cause disconnects)
scope is a 6" f/4 with a sony a6000 in prime focus via gphoto indi driver

Kernel: 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Software: xubuntu with kstars edge and indi from ppa
INDI Library: 1.2.0
Code $Rev$. Protocol 1.7.
kstars 2.6.0 - ii kstars-bleeding 5:16.04+r5965.2605~ubuntu16.04.1 amd64

My location is near Berlin/Germany around 52° N 13° E

The biggest problem I have is that the alignment seems to work only some small parts of the sky and produces very odd results for other areas.
For example I start with a levelled mount with rough sky alignment in EQ mode. I point the scope into the direction of Vega and use the solver to get a sync point. Then go to Arcturus and do the same.
The problem seems to start then that the telescope behaves unpredictable. Slewing to Dubhe might point the scope into Polaris region or even -40 to the ground.
The EQMod icon in Kstars might jump to a different location while slewing. The mount might also end up at an incorrect position on the sky. Which I solve again with sync and tell the scope to move to the destination I wanted in the first place but it does not slew there as EQMod still thinks it is already pointing there.
I also noticed that sometimes the alignment values in the Indi client become totally out of bound. (like several million degree of AZ/EL)

Is this caused by the very rough polar align or some missing configuration or a bug? I attached a log which looks strange at around 1127 seconds into the file as the coordinates change a lot in a few seconds.

I also noticed that as soon as I connect in Kstars with Ekos/Indi to the EQMod Mount that the time in the top left corner changes. For example I start Kstars and it shows "LT: ... 22:40:00 CEST" After connecting EQMod it jumps to "LT: ... 21:40:00 CEST"

Thanks
Karsten

Ofcourse it's hard to pinpoint such problems, but it does sound very similar to a problem I had with my first AZ-EQ6 mount. The motherboard was acting up and indeed sometimes just lost its true position. Basically, it reported wrong positional data to KStars/INDI. I would check your connections and mount itself. Try using the handcontroller to do the same and see if it's acting weird as well... then you have a mount problem.

Btw, why are you using multiple points etc? I normally just polar align the mount, focus, go to a random place and platesolve and then the mount seems to know pretty well where it's pointing at.

are the stepper positions affected by alignment data? I calculated the position in degree and degree change per second from the reported stepper positions in the attached image. (, = . )

I tried to improve the alignment with multiple points as the mount was not going where I intended.

Hi Karsten,
As you point out, the problem arises at 1127seconds: the DEC axis seems to move by itself and it lasts for at least ten seconds. It seems, reading your log, that you were tracking at that time (only RA encoder is moving), and the DEC axis starts to slew at 1127 seconds whereas the status for DEC axis reports that the DEC motor is stopped (this is the :g2 command). And the slew seems to be large, from 8387943 to 9934536 at 1137. Furthermore the indi driver stops tracking at 1128 because of horizon limits, so both motors should be stopped at that time.
I would suggest to look at the mount configuration using the hand controller: maybe some sort of PEC is enabled or alt/az mode is engaged or whatever, actually I have no idea. The AZ/EQ5 uses quite a powerful cortex-M4 processor (regarding to the usual PIC processors) and it is possible that most of the control lies in the motor controller now, and not in the hand controller. So what you did with your mount may have an impact on what you do after while, the motor controller remembering some status at start-up.
Now the indi driver never alters the RA/DEC encoders in the motor controllers, only on connection they are set to the home position if the mount was unparked or uninitialized (this is the :E command you could see on connection).
Concerning the jump in LST in kstars when connecting the mount, it seems that your system clock is not at UTC (or the converse I always forget). The driver uses this clock to compute LST and supposes it is at UTC, and it ignores DST and such things. So the simplest thing to do is to tell kstars to send its current time (which is the correct one) to the mount, there is an option to do that in the prefs menu.

Jean-Luc.

Hi,

I did an other session but forgot to post an answer

I did some more tests with my mount. I reset the mount/handset to default settings.
I tried to watch the position on the handset while connecting with the PC but that drops the connection due to communication errors pretty quickly. (Could be that the built in usb2serial uses the same connection as the handset) Without the handset connected I never get connection problems over USB.
This made me remember what might have caused the direction errors as I did not restart from polar home most of the times due to the connection losses. I just reconnected and resynced from plate solving. I guess that Indi does not like that.
I added a log that shows some jumps in RA while the RA encoder does not even move. While slewing over a certain point the coordinates where jumping from 7.73* to 19.7* for the RA value. This might have been caused by the sync and stored a bad value for meridian flip.
I sometimes also get some very strange coordinates but have no reproduction for those issues. (hits the 2^32 signed limits) (see the screenshot from 23:05:10)


With the kstars time display I still can not make an sense out of it. The BIOS clock is on UTC. System time and timezone are correct for CEST. Device Updates are set to update the device. (see screenshot from 11:37:12)
before connecting:
LT: time correct 11:37 timezone correct: CEST
UT: time correct 09:37 timezone incorrect: CEST (needs to show UTC)

after connecting:
LT: time 10:37 timezone: CEST (did it disable summer time? but then it needs to show 10:37 CET or 11:37 CEST)
UT: time correct 09:37 timezone incorrect: CEST (needs to show UTC)

Karsten

Hi,
I believe you misunderstood how alignment works. It does not make a direct correspondence between the aligned coords given by the plate solving and the current RA/DEC encoders (or change the encoders themselves). It supposes you made a goto to a target just before and then uses the aligned coords to build a model of your misalignment. So you should start with your scope pointing to NCP, power on the mount, launch the indi driver and server, goto to a target, plate solve and sync. And add other sync points by goto target, aolve, sync. If you power off the mount in between without pointing to NCP and without restarting the driver the alignment model gets lost. This surely explains the jumps in RA/DEC with motor physically stopped because the telescope RA runs with earth and when the model (which uses it to compute your aligned RA) changes its alignment face, it uses three other sync points. If you enter sync points as you described above the model is then lost.I think the timezone should be constant, as you don't move. CEST or CET depends on your country.

I've been having similar issues where the mount goes haywire after a few captures & solves, whether I am using "sync" or "slew to target" afterwards. Perhaps some of the confusion comes from this tutorial which says to "slew to target" when doing alignments: www.indilib.org/support/tutorials/137-al...with-eqmod-ekos.html

I have started with a clean slate a few times using the following procedure and I always seem to run into the mount going haywire not long afterwards. I guess it doesn't help that kstars crashes every so often.

Here's what I have been doing:
- park the scope near NCP
- delete all sync and align points in ekos
- exit kstars
- reboot
- launch kstars/indi
- unpark mount
- go to alignment module
- do a capture and solve (I am getting successful solves) with sync (or slew to target)
- select a new target a couple of more times

Are there any other steps I should be doing?

Thank you