If you get a package built of KStars in the next week or so, then that should solve your problem, and don't bother with minicom, picocom, the OnStep Python API ...etc.
But if you do not get it soon, then try one (or more) of the above workarounds.
Actually the Python API already does set the horizon and overhead limits using the :Sh and :So commands. So no changes needed in the code.
But you need to edit examples/config.py and enter your location, time, ...et.c as well as the above limits under this section:
# Horizon and overhead limits hor_lim = '-10' ovh_lim = '90'
Yes, and yes.
You can install it from a terminal using:
sudo apt install minicom
picocom -eq -b9600 /dev/ttyACM0
The FYSETC S6 definitely has a serial port. I know, because I am the one who ported OnStep to it.
DFU is only used when flashing the firmware to the board. Once that is done, and you power cycle the board, you should have a serial port over USB, provided that you followed the steps that are on the OnStep Wiki correctly.
One possibility is to add the commands that Alain detailed to the OnStep Python API . Then, since you use Linux, you will have Python on it, and you can run the API from the command line.
But this is temporary. The bug needs to be fixed regardless, as Alain outlined.
I have not seen any packages built (KStars Bleeding, and INDI) after all these fixes from a month ago.
Did I miss them? Or are they in the pipe line and will be available soon?
Thanks Alain for explaining how the bug is manifested/expressed.
Thanks Jasem for fixing it.
I hope that stable packages are built in the coming couple of weeks or so.
The "telescope connection disappearing" issue is in KStars, not INDI?
Yes, now that I tried a couple of times, the connection info is shown and can be changed.
I guess we need to report this to Jasem, so it is fixed before the next packages are built. Right?
Jasem merged the PR from James.
So I updated from Jasem's repo, then compiled it and testing now over WiFi.
There are no timeouts.
One very important and confusing change: there is no way to change the connection at all since all the fields are missing now.
Here is a screenshot to better show what the issue actually is.
Thanks for looking into this in more detail, and finally solving the crashes.
Just to be clear, does the PR include only the different timeouts for network vs. serial?
Or does it also include checking the presence of the devices we know will cause timeouts if they a not there (specifically the return of :FA (focuser1), :fA (focuser2), and :GX98 (rotator)?
If the PR does not include those, then I really think these should be included.
Yes, I am using ESP8266 Board Manager version 2.4.2, and it works.
Espressif, the company that makes the ESP8266 and ESP32, does not have a good track record for stability on newer versions. They always introduce problems. The classic case of good hardware but inferior software.
I think there are two separate things here:
1. Investigate what is different in SWS vs. USB (and even the older WiFi addon)
2. Proper device detection (rotator, focuser, and in the future thermometers, and other features), and not polling devices that are not there.
Task 1 is a technical development task to get to the bottom of why SWS delays responses. Howard gave some clue in the thread I linked to earlier.
Task 2 needs to eventually go into Jasem's repo, because it is the efficient way of doing things. Only 10% or 20% of OnStep users have a rotator, so why make INDI "too chatty" for something that is not there. The focusers are used more, but most users who have them has only one. So why poll the second one? And so on.
I am okay with delaying task 2 until you get to what the underlying issue for task 1. But task 2 must go in for efficiency's sake.
Thanks for digging into this. Yes, I suspected that delayed results going to the subsequent commands would crash (e.g. expecting a number on Cmd1, which times out, then Cmd3 gets it, and things go haywire.
So yes, buffer clearing is a good idea, but how long would one wait? SWS has a default of 200 ms timeout, plus the time a command takes on OnStep. It varies. Maybe 250 ms minimum timeout is safe? I don't know.
Yes, if you bypass the Wemos you will get different results. The thing is, the Wemos runs new software (SWS) which has some internal processing, and is a bit different from the addon. So what you are seeing is probably buried in SWS somewhere.
Regarding the rotator, are you testing with the conditional GX98 code? If not, then yes, the :r commands will take a long time and cause problems.
I don't have much to add here, so will wait until the experts finish their analysis.
In the meantime, should Alain push the small GX98 patch to Jasem, to prevent having others report the same issue?