×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

EQMod Tracking problems

  • Posts: 17
  • Thank you received: 2
Hi I have some problems with my diy astroeq controller and an eq5 mount.
Under windows in the Ascom software everything works fine, but i wan't the astrometry feature from indi.
The problem is that tracking don't works. The log says "begin tracking" but the steppers dont move.
When I start the tracking manual the stepper moves a few seconds but than stops moving.But in Ekos I can see the Mount-icon moving (the software knows that the mount dont move).
Here the log:
Warning: Spoiler!


In the log is a little second problem visible: the connections works only after the second try to connect the first try to connect fails every time.
I don't know if the problem is in the indi/ekos software or a bug in the astroeq-firmware.

I'm using "indi-full 1.2+r1.255~ubuntu16.04.1 amd64" and "kstars-bleeding 5:16.04+r5764.255~ubuntu16.04.1 amd64" from the ppa.
Kernel: "Linux niklas-W230SD 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux"
7 years 9 months ago #8637

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

You should enable full verbose output to a file, including scope verbose and see what commands gets sent and what is received.
Last edit: 7 years 9 months ago by Jasem Mutlaq.
7 years 9 months ago #8638

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

  • Posts: 17
  • Thank you received: 2

Replied by Niklas on topic EQMod Tracking problems

I made a log with Driver Debug, Scope Status, Serial Port and Verbose Mount
Last edit: 7 years 9 months ago by Niklas.
7 years 9 months ago #8641
Attachments:

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

  • Posts: 226
  • Thank you received: 88

Replied by Jean-Luc on topic EQMod Tracking problems

Hi,
I looked at the log and the AstroEQ firmware stops the motor during the first second of tracking (which is launched at the end of the goto) at 105.407636sec.
For tracking the mount should be set in low speed slew mode for both axis. This is the mode in which the firmware jumps when it ends its goto command, as the :f status commands report at 105.407700sec. The Indi driver does not send the :G "set mode" command if the mount reports it is already in the desired mode. So I think the AstroEQ firmware is not in a correct state if it does not explicitly receive that :G command, even if it reports it is in low speed slew mode. I can't verify but I think the ASCOM EQmod driver should send this :G command after a goto when it starts tracking. Are you able to check that by logging the ASCOM driver ?
Quickly looking at the AstroEQ firmware I also notice that a :I command seems to start the motor, but it should normally only set the speed register. This is why the mount starts tracking for a while. Only the :J command should start a motor on my mind.
7 years 9 months ago #8649

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

  • Posts: 17
  • Thank you received: 2

Replied by Niklas on topic EQMod Tracking problems

I used a serial port logger to see what the ascom software send and there are a ":G11"

File Attachment:

File Name: send.htm.txt
File Size:4 KB

File Attachment:

File Name: read.htm.txt
File Size:7 KB
7 years 9 months ago #8651
Attachments:

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

  • Posts: 2
  • Thank you received: 0
@geehalel, AstroEQ doesn't start movements when a :I# command is issued, it only starts when a :J# command is issued. The :I# command will update the current speed for manual slews and tracking (it doesn't affect GoTo movements). If the mount is currently moving in a slew or tracking movement, the update will happen immediately (I think that is where you are misunderstanding the code. If it is not currently moving, or it is doing a GoTo, the :I# command will do nothing until the next :J# command.

What is happening is that Indi is failing to send a :G# command, so when it receives the :J# command, it starts performing a GoTo movement as that is the mode that it was last in. This is why the axes start moving for a short period - it is doing a GoTo of the same length as whatever the last one was (which was a short correction in this case). Without the :G# command it is not being told what it should be doing.

There is very little documentation on what the Skywatcher protocol does with some of the flags. In fact it seems there is much that is not documented. The AstroEQ parser is based on what EQMOD does (not necessarily what a Skywatcher mount does) because that is the only reference I had to work on - in fact AstroEQ is designed to work with EQMOD which guarantee compatibility with anything that Skywatcher does. In this situation, EQMOD will *always* send a :G# command after a GoTo movement is complete, so there is never an issue.

In the case of checking the flags, AstroEQ uses one of the flags (I forget which one) in the :f# response to signify whether a GoTo is *in progress* not whether it is in GoTo mode.

I suppose I could change things so that the AstroEQ resets the current mode back to slew after a GoTo is complete rather than staying in that mode. But I would have to verify that it would still work correctly in all situations with EQMOD (compatibility with the official EQMOD software trumps compatibility with INDI I'm afraid).


Kind Regards,
Tom.
7 years 9 months ago #8711

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

  • Posts: 226
  • Thank you received: 88

Replied by Jean-Luc on topic EQMod Tracking problems

Hi Tom,
Well I just saw a motorStart call inside the :I case statement but did not investigate further.
I wanted to be sure that it was the lack of the :G command which was the issue as nikiosna has confirmed.
Yes, I also built my own hardware using EQMOD as a first driver, and the brief description of the protocol that skywatcher published in 2011. I still don't have a skywatcher mount, but uses some simple breadboard clone to perform tests.
As I said, the skywatcher firmware jumps to the slew mode when a goto is finished, that's why sending a :G command is not always mandatory after a goto (that's the way the Indi driver has worked as for now).
I actually have the same problem as the test (wether sending a :G command) is inside a SetMotion function called from ... 3 points: Slew and SlewTo should be ok, the last is SetRate which is used in guiding. I could put out the :G command from the test but that will imply a :G command will be sent for every guiding command.
Another solution would be to explicitely send a :G command at the end of a goto in the ReadScopeStatus function, but that would require to make public the dispatch_command function from skywatcher.cpp (or make the EQMod class a friend of Skywatcher class) as I've dissociated the protocol code from the driver code itself. This would have less impact other than this code structure.
I can't perform any changes for the moment, I even did'nt make a fork yet as Indi has recently moved to github, neither can't do a real sky test. I work far from home and I am quite busy in this period. Maybe someone have some time to try this and test guiding on real sky (if anyone has ever used it;-)). I think I will have a deeper look to this issue during holidays this summer.

Kind Regards,
Jean-Luc.
The following user(s) said Thank You: Niklas
7 years 9 months ago #8718

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

  • Posts: 17
  • Thank you received: 2

Replied by Niklas on topic EQMod Tracking problems

I have edited the skywatcher.cpp SetMotion function to
if ((newstatus.direction != currentstatus->direction) || (newstatus.speedmode != currentstatus->speedmode) || (newstatus.slewmode != currentstatus->slewmode)) {
    StopWaitMotor(axis);
}
dispatch_command(SetMotionMode, axis, motioncmd);
read_eqmod();
And the tracking did work for me. I don't know if the guiding sends now too many commands, because i don't use guiding at the moment.
But i have the idea to add an extra bool as argument to control the dispatch_command.
void Skywatcher::SetMotion(SkywatcherAxis axis, SkywatcherAxisStatus newstatus, bool SetMotion) throw (EQModError)
{
...
  if ((newstatus.direction != currentstatus->direction) || (newstatus.speedmode != currentstatus->speedmode) || (newstatus.slewmode != currentstatus->slewmode)) {
    StopWaitMotor(axis);
  }
  if(!SetMotion) {
    dispatch_command(SetMotionMode, axis, motioncmd);
    read_eqmod();
  }
 ...
}
But for that I have to edit every point where SetMotion is called.

Here the log from the test where dispatch_command is outside the if statement.

File Attachment:

File Name: indi_eqmod....log.txt
File Size:32 KB
The following user(s) said Thank You: Jean-Luc
7 years 9 months ago #8729
Attachments:

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

  • Posts: 226
  • Thank you received: 88

Replied by Jean-Luc on topic EQMod Tracking problems

Nice, that was effectively the idea. Concerning guiding, that would just add some overhead, but I can't say how it impacts in real conditions (a few millisec maybe).
I think I would prefer to add an extra public SetMotionMode method in the skywatcher class, which unconditionnally sends the corresponding ':G' command to the mount, and calls that new method at the end of Gotos. Now I wonder which mode to use, clearly slew mode, but highspeed or lowspeed and in which direction. I will look to what the firmware does in detail.

Thanks,
Jean-Luc.
7 years 9 months ago #8743

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

  • Posts: 2
  • Thank you received: 0

Low speed slew west (and south for DEC axis) makes the most sense, though it probably doesn't matter very much.
7 years 9 months ago #8750

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

  • Posts: 226
  • Thank you received: 88

Replied by Jean-Luc on topic EQMod Tracking problems

Hi,
I've added a ResetMotions() function in skywatcher.cpp to unconditionnally put both axes in low speed slew mode , and calls that function at the end of gotos.
May you test if that works for AstroEQ mounts from my repository before I ask a pull request ?
I can not make real tests for skywatcher mounts, if someone could perform a test that would be glad.

Jean-Luc.
7 years 8 months ago #9146

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

  • Posts: 17
  • Thank you received: 2

Replied by Niklas on topic EQMod Tracking problems

I will test it in the next week. I have currently a few exams.
7 years 8 months ago #9162

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

Time to create page: 0.753 seconds