Honestly I don't remember why all test were done with "strstr" instead of direct variable access!
So I just left it to be similar with other part of code.

But as I said, there is a huge cleaning work to do all over the code.

If one day I feel courageous

> Honestly I don't remember why all test were done with
> "strstr" instead of direct variable access!

It makes sense to use strstr if you are testing a longer string with multiple characters in it.
But if it is a single character, testing the specific character is better: it is less error prone, and faster too.

> But as I said, there is a huge cleaning work to do all over the code.
> If one day I feel courageous

If we a) have a period of stability (e.g. several months) and b) not much additional features going it, then it makes sense to do the cleanup, because the likelyhood of it to mess things up is low under these conditions.

Otherwise, the "if it works don't fix it" rule prevails ...

Latest tests,

Even if everything seems to work there are still some stranges things.

Look at the video and see what happens to the Telescope position when "Parking" / "Unparking"
It jumps shortly to another position and nothing to see in the network logs
 

No problem on PR.

But I do want to modify it a bit. Below is what I've got instead.

I'd setup to use :rA earlier on OnStepX (& old on others), but we were certainly thinking along similar lines. Part of the reason for that is: I've got a mostly working checksummed response and retry with the long single char response call there, getCommandString is via lx200 calls. So when that's done, we can introduce it without going back to modify this. (I'd like to get all of the probing under that or the similar function and get rid of sendOnStepCommand & sendOnStepCommandBlind which provide little in the way of actual error detection. (Blind we might keep around, for older versions.) If we only use the lx200 for lx200, then we'll still have some longer timeouts/non-checked/etc. but they shouldn't mess much up if one were to occasionally fail. (Moving the guiding over might be good.)

For the future it might be easier to do git diff > patchfile (but that has it's own downsides)

All of this should be in the network-timeouts.

I will see about adding configurable timeouts before I make a PR. (probably today if not probably Friday.)

Actually, Should probably only define the OSrotatorDerotator if it's 'D', but I'll do that as well before the PR.

 

Alain,

That jump is strange.
It looks like a residual value from GD/GR. I have seen something like
it a while back, and it did not have any ill effect. Forgot what the issue
was though ...

Does it show only when you are over WiFi, but not over USB?
Or it shows in both situations?

James,
As long as you can test it over SWS and it works, I am okay with the new code. It is more complex but I guess more error checking is always good.

@Khalid,

the jump is only over WiFi.

And see I ordered the Wemos yesterday and they arrived today but Murphy was too in the mailbox ... Soldering Station dead.
Want to buy a new one and my preferred vendor"s site went down fo maintenance ....
So I say ..................... (all censored

@James,

Yes I like the idea about diff and patch file but sometimes it is difficult to know what the reference is.
OK for the "D" only for rotator.
Anyhow for this part we need to identify somebody willing to test and has a AltAZ mount.

Alain,

Here is an idea: run ngrep before you issue the park command, and see what the return from GD/GR is. My guess is that you will see something there. Maybe some command is slow and times out only over WiFi.

Khalid,

This is what I did, GR GD return same values as before command is sent
Parking:
4452 2021/11/17 13 00 07.377497 4687.377500 Indi :hP#
4453 2021/11/17 13 00 07.382059 4687.382060 OnStep 1.....
4454 2021/11/17 13 00 07.768024 4687.768020 Indi :GR#
4455 2021/11/17 13 00 07.774871 4687.774870 OnStep 01:59:51#
4456 2021/11/17 13 00 07.775074 4687.775070 Indi :GD#
4457 2021/11/17 13 00 07.781352 4687.781350 OnStep +55*02:16#
4458 2021/11/17 13 00 07.781451 4687.781450 Indi :GU#
4459 2021/11/17 13 00 07.786816 4687.786820 OnStep nIez/EW260#
4460 2021/11/17 13 00 07.787167 4687.787170 Indi :%BD#
4461 2021/11/17 13 00 07.791453 4687.791450 OnStep 0#....
4462 2021/11/17 13 00 07.791583 4687.791580 Indi :%BR#

Unparking:
7306 2021/11/17 13 01 21.918195 46881.918200 Indi :hR#
7307 2021/11/17 13 01 21.981059 46881.981100 OnStep ......
7308 2021/11/17 13 01 22.100660 46882.100700 OnStep 1.....
7309 2021/11/17 13 01 22.548499 46882.548500 Indi :GR#
7310 2021/11/17 13 01 22.555101 46882.555100 OnStep 01:33:42#
7311 2021/11/17 13 01 22.555365 46882.555400 Indi :GD#
7312 2021/11/17 13 01 22.561630 46882.561600 OnStep +55*43:01#
7313 2021/11/17 13 01 22.561967 46882.562000 Indi :GU#
7314 2021/11/17 13 01 22.567141 46882.567100 OnStep Npez/EW260#

I was referring to the sequence that you did starting at 0:33 in the video.
Not unpark, rather the jump when parking.

The cross hairs are in Cassiopeia, but when you issue the park command, they jump to Camelopardalis then back.

If you can capture that sequence in ngrep from before you click, until the park is done.

Also, I found that ngrep -T give calculated times which is very helpful. And -l (small L) will do line buffering.

T +1.000631 indi:38842 -> onstep:9997 [AP] :GR#
T +0.199375 onstep:9997 -> indi:38842 [AP] 11:03:37#
T +0.000310 indi:38842 -> onstep:9997 [AP] :GD#
T +0.019753 onstep:9997 -> indi:38842 [AP] +90*00:00#
T +0.000234 indi:38842 -> onstep:9997 [AP] :GU#
T +0.019763 onstep:9997 -> indi:38842 [AP] nNpHSzEo150#

The first line has an offset of 1 second, which is the polling frequency in INDI.
After that, you have the exact microsecs it takes for each command.

I see the jump too.

It happens on Park like you have in the video.

But here is the interesting part: if I park from the web interface, there is no jump. So it is some other command that is issued from INDI that causes it.

So, any of these commands:

T +0.336700 indi:38842 -> onstep:9997 [AP] :hP#
T +0.023055 onstep:9997 -> indi:38842 [AP] 1
T +0.240731 indi:38842 -> onstep:9997 [AP] :GR#
T +0.019536 onstep:9997 -> indi:38842 [AP] 21:27:53#
T +0.000137 indi:38842 -> onstep:9997 [AP] :GD#
T +0.019809 onstep:9997 -> indi:38842 [AP] +62*40:55#
T +0.000206 indi:38842 -> onstep:9997 [AP] :GU#
T +0.019882 onstep:9997 -> indi:38842 [AP] nISzEW150#
T +0.000267 indi:38842 -> onstep:9997 [AP] :%BD#
T +0.019612 onstep:9997 -> indi:38842 [AP] 29#
T +0.000110 indi:38842 -> onstep:9997 [AP] :%BR#
T +0.019900 onstep:9997 -> indi:38842 [AP] 161#
T +0.000153 indi:38842 -> onstep:9997 [AP] :GX90#
T +0.019867 onstep:9997 -> indi:38842 [AP] 0.50#
T +0.000201 indi:38842 -> onstep:9997 [AP] :GX95#
T +0.019735 onstep:9997 -> indi:38842 [AP] 0#
T +0.000179 indi:38842 -> onstep:9997 [AP] :GX96#
T +0.019771 onstep:9997 -> indi:38842 [AP] B#
T +0.000132 indi:38842 -> onstep:9997 [AP] :GXE9#
T +0.019859 onstep:9997 -> indi:38842 [AP] 32#
T +0.000109 indi:38842 -> onstep:9997 [AP] :GXEA#
T +0.019870 onstep:9997 -> indi:38842 [AP] 32#
T +0.000111 indi:38842 -> onstep:9997 [AP] :GX9A#
T +0.019879 onstep:9997 -> indi:38842 [AP] 10.0#
T +0.000124 indi:38842 -> onstep:9997 [AP] :GX9C#
T +0.019876 onstep:9997 -> indi:38842 [AP] 70.0#
T +0.000132 indi:38842 -> onstep:9997 [AP] :GX9B#
T +0.019825 onstep:9997 -> indi:38842 [AP] 1010.0#
T +0.000113 indi:38842 -> onstep:9997 [AP] :GX9E#
T +0.019899 onstep:9997 -> indi:38842 [AP] 4.0#
T +0.000389 indi:38842 -> onstep:9997 [AP] :A?#
T +0.019614 onstep:9997 -> indi:38842 [AP] 900#
T +0.000253 indi:38842 -> onstep:9997 [AP] :GX02#
T +0.019832 onstep:9997 -> indi:38842 [AP] 0#
T +0.000164 indi:38842 -> onstep:9997 [AP] :GX03#
T +0.019738 onstep:9997 -> indi:38842 [AP] 0#

I captured all but only showed Parking / U,parking.
But there is nothing like a coordinate jump in the dump.
But before I have my new soldering, I hope before the weekend, I can do nothing with my Wemos

That may be something I haven't dug into with regards to lower level stuff setting values. Like everything that caused the align/slew done nightmare.

If you can't figure it out, It'd be good to see what the KStars debug logs have (They should have something as it jumps in Kstars) or the raw INDI wire. (I don't ever park except sometimes to test.)

Note:
I made (and then fixed) some bugs, my network-timeout branch should be bugfree (tm) and it's been playing around for a bit without any issues.

Just a note if you use them: getCommandSingleCharResponse is sometimes a replacement for getCommandString, but only if it lacks a trailing # all uses now in network-timeout no longer have that, and are noted as such.) getCommandSingleCharErrorOrLongResponse is otherwise to be used if it has a trailing #. (But it handles the other a lot faster.)

Also the hardware pain with regards to this is real. I did get the esp8266s, but now I need a new CP2102 serial board. Yay dropping and then managing to step and rip the traces off the board for the microUSB. (Rest is fine.)

I think that solves all the issues with the SWS connection. Though I don't have a mount to test or a wireless capable board I can easily simulate an alt-az on.

-- I say that, then it crashes on stod(). Conclusion Everything needs error checking or it may crash INDI and KStars. Argh