So in multiple day+ long tests, I see plenty of network timeouts, but 0 crashes, even while accessing it with multiple things. About 6-ish per hour at 2 second timeouts on my network.

I did go ahead and change to LOG_WARN and to return true to ReadScopeStatus. (Focusers/Rotators and such are still LOG_ERROR) so the scope doesn't go into error status.

Unless anyone sees a problem I'll see about a PR to main tonight.

NOTE: The logs will have a combination of INFO/WARN/ERROR. I mostly kept the wording the same, but I'm not sure I like it: This update aborted, will retry...  (Kept the same for easy find/replace.)
Mount will not change state due to the LOG_ERRORs. (To prevent stopping captures, sequeneces, etc.)
Mount will not disconnect.


TODO (related or discovered due to this):
Convert the Focusers & such that are in functions other than ReadScopeStatus to others.
One issue is that the scope doesn't register as disconnect when on the network, I believe this is the case with the existing network code as well. (But you were more likely to have a crash than notice that.)
LX200 adjustable timeout. This is a bit trickier than I thought needing to touch a lot more things, so I'm going to make it separately. (This is IMO better than just OnStep, and will get all the LX200 functions we use, plus it should benefit anyone using a network adapter for an lx200, TeenAstro or others.)
Alain's investigations into the rotator differences on SWS vs direct.
Park: I'm not sure I'm understanding the process right (I don't use it normally), but when I set a position it's now slewing to it.

Question: Should I raise the network timeout from 2 sec to 3 sec or higher?

I see little reason to not keep the serial at 0.1 sec, I don't see errors with it, even on the slowest platform we have. There is one edge case: serial to wifi or bluetooth to serial might be slower, but only if it's setup as a serial port, as opposed to accessing the serial port over a network. I don't have a bluetooth serial module to test right now. (and I've had horrible luck with them.) That should be resolved with the adjustable timeout patch later on.

Read More...