In recent days I encountered and narrowed down a problem with Ekos controlling my Losmandy Gemini 1 system. It all started when I noticed that certain commands never reached the mount, in particular :hN# (stop tracking) and :hW# (restart tracking).

My Gemini 1 was connected to the Indi server's /dev/ttyS0 via serial cable and DE-9 connector. The mount did not react to "stop tracking" commands, neither via Ekos nor Indi buttons. While the Indi logfile clearly stated these commands were sent to the mount, Gemini's debug mode confirmed they were NOT received. This was confusing since other commands like :GR#, :GD# and :Gm# were received 100% of the time. So no cable or connector problem.

I then tested with a laptop. I used the same serial cable, just added a USB<->serial converter since my laptop did not provide the old fashioned D-Sub port. I was surprised to see that 100% of the :hN# and :hW# commands were received by the mount.

So I got back to the first computer and added the USB<->serial converter. Conncted to ttyUSB0 all commands including  :hN# and :hW# were received.

I added a third computer, tested at ttyS0 ( :hN# and :hW# commands lost) and ttyUSB0 (all commands received).

I admit this sounds dubious but I tested again and again over the course of days but the result remained the same. :hN# and :hW# commands were lost when sent via ttyS0 and received when sent via ttyUSB0. Same result with two computers.

One thing that I also noticed during these tests is the driver's "connection port" configuration "/dev/ttyS0" is not saved despite clicking the SAVE CONFIG button over and over again. After the next restart always "/dev/serial/by-id/usb-FTDI_USB__-__Serial-if00-port0" popped up.

Hi there,

you could try (after connecting the serial cable) running running stty -a -F /dev/ttyUSB0, resp. -F /dev/ttyS0 to see how it's set up.
For my Celestron AUX converter it e.g. is configured as follows

$ stty -a -F /dev/ttyACM0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

Thanks a lot, Thomas!

The output

@SA76R4:~/Astro$ stty -a -F /dev/ttyS0   
speed 38400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe echok -echonl noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

@SA76R4:~/Astro$ stty -a -F /dev/ttyUSB1
speed 38400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe echok -echonl noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

AFAICS is exactly the same.

Astonishingly it appears to me the :GR# etc. commands are not affected as they are being received by the Gemini controller. Are the GR GD Gm commands issued in the same way as the hW and hN commands, "codewise"? I found where the hW and hN commands are sent in the source code but (apart from having no clue as to what is being done there)

I didn't find out where the GR, GD, Gm commands are issued so I can't compare.

Thanks again for your time!
CS!

As you mentioned the stty is identical, so the problem must be somewhere else. The commands GR, GD, Gm are listed in the source code here:

[thomas@x230 ~/dev/astronomy/indilib/indi/drivers/telescope]$ grep -nr ":GR#\|:GD#\|:Gm#" .
./eq500x.cpp:823:    else if (getCommandString(PortFD, b, ":GD#") < 0)
./eq500x.cpp:833:    else if (getCommandString(PortFD, b, ":GR#") < 0)
./lx200pulsar2.cpp:897:    return (getSexa(fd, "#:GR#", ra) && getSexa(fd, "#:GD#", dec));
./lx200pulsar2.cpp:1086:    bool success = PulsarTX::sendReceive(fd, "#:GR#", response);
./lx200driver.cpp:1684:    DEBUGFDEVICE(lx200Name, DBG_SCOPE, "CMD <%s>", ":GR#");
./lx200driver.cpp:1691:    if ((error_type = tty_write_string(fd, ":GR#", &nbytes_write)) != TTY_OK)
./lx200driver.cpp:1734:    DEBUGFDEVICE(lx200Name, DBG_SCOPE, "CMD <%s>", ":GR#");
./lx200driver.cpp:1738:    if ((error_type = tty_write_string(fd, ":GR#", &nbytes_write)) != TTY_OK)
./lx200driver.h:117:#define getLX200RA(fd, x)     getCommandSexa(fd, x, ":GR#")
./lx200driver.h:118:#define getLX200DEC(fd, x)    getCommandSexa(fd, x, ":GD#")
./lx200gemini.cpp:489:    // Send ':Gm#'
./lx200gemini.cpp:490:    const char *cmd = ":Gm#";
./magellandriver.h:49:#define getMAGELLANRA(fd, x)  getCommandSexa(fd, x, "#:GR#")
./magellandriver.h:50:#define getMAGELLANDEC(fd, x) getCommandSexa(fd, x, "#:GD#")
./rainbow.cpp:700:    if (sendCommand(":GR#", res) == false)
./rainbow.cpp:713:    if (sendCommand(":GD#", res) == false)
./ioptronHC8406.cpp:34::GR#            2:12:57.4#   RA
./ioptronHC8406.cpp:35::GD#            +90* 0: 0#   DEC
./crux_mount.cpp:1092:    sprintf(szCommand, "#:\\GE($GR #:GR#"
./crux_mount.cpp:1093:            ":\\GE$GD #:GD#"
./lx200_OnStep.cpp:2133:    getCommandString(PortFD, OSPier, ":Gm#");
./lx200_OnStep.cpp:3043:    // * 94 pierSide (N if never) {Same as :Gm# (E, W, None)}

Hi there,

did you check whether the problem is also occurring with version 1.8.9? Since version 1.9.0 a lot of code is C++ modernized and this could
be a side effect. I am testing on master, but observing/imaging on version 1.8.9.

Cheers
Thomas

Thanks a lot for your reply, Thomas!

Previously I did all tests running latest GIT but after reading your suggestion I reverted to Indi 1.8.9 and KStars to 3.5.2 Stable. Unfortunately the issue remains, no difference.

Interestingly, not all tracking start/stop commands are lost. With one of the two indi servers connected, "loss rate" is ~95% while with the other it's ~50%. They are both of the same type (Shuttle XPC SA76R4), the only difference is one is equipped with an AMD Athlon 2 X2 240 CPU, the other with a Phenom II X6. So they employ the same com port hardware. Yesterday I re-formatted one of the two, installed  a fresh Kubuntu 20.04.2 LTS with no other software than just the basic system, git, gcc, etc. and Indi/Kstars. The "loss rate" of ~50% remains unchanged.

If you've got more ideas what to test, please let me know!
Thanks and CS!

Hmm that sounds indeed strange....

How about running your tests in full debug mode and providing the log files.

I had another idea and started minicom, connected to the Gemini via /dev/ttyS0 and did type the commands by hand. It did work 100% of the time!

When Gemini is started in debug mode, the handbox displays all commands that are being received. When connected via minicom, the display shows the commands as I type them. When connected to Indi via ttyS0, the handbox display does not show any of the :hN# :hW# commands so they are not received. It does show lots of :GR# :GD# and :Gm# commands being received though.

[2021-05-28T17:22:51.341 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:hN#> "
[2021-05-28T17:22:51.344 CEST INFO ][           org.kde.kstars.indi] - Losmandy Gemini :  "[INFO] Mount is sleeping... "
[2021-05-28T17:22:51.560 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] ReadScopeStatus: TrackState is <0> "
[2021-05-28T17:22:52.393 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:hW#> "
[2021-05-28T17:22:52.396 CEST INFO ][           org.kde.kstars.indi] - Losmandy Gemini :  "[INFO] Mount is awake... "
[2021-05-28T17:22:52.560 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] ReadScopeStatus: TrackState is <2> "
[2021-05-28T17:22:52.561 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:GR#> "
[2021-05-28T17:22:52.583 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <00:46:27> "
[2021-05-28T17:22:52.583 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] VAL [0.774167] "
[2021-05-28T17:22:52.583 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:GD#> "
[2021-05-28T17:22:52.606 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <+89:57:53> "
[2021-05-28T17:22:52.606 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] VAL [89.9647] "
[2021-05-28T17:22:52.606 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:Gm#> "
[2021-05-28T17:22:52.614 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] RES: <W>, lst 8.378139, ha 7.603973, pierSide 1 "
[2021-05-28T17:22:53.513 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:hN#> "
[2021-05-28T17:22:53.515 CEST INFO ][           org.kde.kstars.indi] - Losmandy Gemini :  "[INFO] Mount is sleeping... "
[2021-05-28T17:22:53.614 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] ReadScopeStatus: TrackState is <0> "
[2021-05-28T17:22:54.605 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:hW#> "
[2021-05-28T17:22:54.607 CEST INFO ][           org.kde.kstars.indi] - Losmandy Gemini :  "[INFO] Mount is awake... "
[2021-05-28T17:22:54.614 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] ReadScopeStatus: TrackState is <2> "
[2021-05-28T17:22:54.614 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:GR#> "
[2021-05-28T17:22:54.637 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <00:46:27> "
[2021-05-28T17:22:54.637 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] VAL [0.774167] "
[2021-05-28T17:22:54.637 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:GD#> "
[2021-05-28T17:22:54.660 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <+89:57:53> "
[2021-05-28T17:22:54.660 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] VAL [89.9647] "
[2021-05-28T17:22:54.660 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:Gm#> "
[2021-05-28T17:22:54.668 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] RES: <W>, lst 8.378712, ha 7.604545, pierSide 1 "
[2021-05-28T17:22:55.525 CEST DEBG ][           org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:hN#> "
[2021-05-28T17:22:55.527 CEST INFO ][           org.kde.kstars.indi] - Losmandy Gemini :  "[INFO] Mount is sleeping... "

I clicked 10x at "stop tracking" and "start tracking". While doing that, I had my ear to the motor. In fact the mount never stopped tracking so all :hN# commands had been lost.
The full logfile is attached.

The current status is this:
:hN# and :hW# commands are not reliably received by the Gemini controller when issued by Indi via /dev/ttyS0.
Just seconds later the same commands are received by the Gemini 100% of the time when issued by minicom via /dev/ttyS0. Same hardware, OS and cabling.

The commands are however reliably received by the Gemini controller when issued by Indi via /dev/ttyUSBx.

What I also noticed is the Tracking Button in the Mount TAB always is ON. The same applies to the "Status" in the Setup TAB, it's always "tracking". Even when tracking has stopped.