Hey Guys i did a compair of the log first started via USB
second start via WIFI

In this case its not home parked but tracking on target

strange behaviour still

I thing to move my laptop OS to mate, it seem to work best if i google rond on this forum

Chris

@Blueshawk,
WiFi, bof , I just did the setup to try to help Chris!
I am not convinced WiFi is the right thing to drive a scope.
During my previous life an an automation engineer, I was many times in front of the choice to use or not WiFi and the proposed solutions were quite professional and expensive but I always did take the choice of reliability over comfort.
But I had some colleagues working in Nuclear plants and swearing WiFi is the future .... fear the future ...
Matter of education I think!
checking this "Telescope altitude is below minimum altitude limit of 0. Aborting motion..."
in which portion of code do you find this? I didn't.


@Chris
I did the test on Debian Buster with an Arduino since I have nothing else to test.
Just realized your question, If you search the culpit of all this mess, I am the guy that wrote the driver

I fully agree with azwing here. WiFi is not the correct network stack to drive a telescope. There is just too much instability, interference, slowness, ...etc.

What I do is drive the telescope over USB from a laptop that sits alongside the telescope, then access the laptop over WiFi.

The difference is that if my remote desktop session times out, the laptop is still driving the telescope as normal, and I just reconnect and I am at the same place.

On the other hand, if you are driving the telescope over WiFi, and there is a timeout, the software that is driving the telescope does not have any knowledge of the telescope's status (where it is pointing, is it tracking or slewing, ...etc.) Very dangerous ...

Hi Khalid,

thank you to support me on this side
My dream is:
- Communication CRC based (howard started to implement this)
- Watchdog that would emmergency stop the scope (based on toggle bit or counter)

But as Khalid said, "the best is the enemy of the good " I could fix the latest bug and now I would like to work a little bit on the new release

Even that will not help in all cases. For example, the network link is so bad that the checksums fail and the two sides have to retry and retry. Under these circumstances, the link becomes unreliable for real time workload.

This will help. Howard has a LIMIT switch implemented, and it is meant to address some of this. If the scope points the wrong way, this pin is toggled and all motion stops. Addresses most cases, but not all.

I tossed in some more Alignment stuff (The check for max stars shouldn't be needed, as I asked and Howard updated it, but yay!) and sent a pull request azwing's way.

I haven't tested under the stars, but it's mostly cosmetic.

I like the checksums, but unfortunately, as mentioned, that would mean redoing everything in the lx200 drivers we use. Which while doable is kinda iffy IMO. I do want to do guiders and motion (The scary parts), but I'm not sure about the rest. (Someone else is more than welcome to do it!)

For the watchdog, issue an abort every so often if not getting anything back, or are you thinking of cutting power?

James,

there is an implementation of Checksum driven communication but don't remember which driver.

Watchdog, yes I would cut the power, I coume back to you on more details

Stupid cloudy nights. It looks like it's the lx200gemini.cpp

I looked at it a little bit, and durr, we could override a few functions. It initially looked more than I would have thought, but it boils down to a few:

We have writing to the actual thing:
lx200driver:
1. tty_nread_section
2. tty_write_string
3. tcflush
4. getCommandString (Calls 1, 2)
5. getCommandString (Calls 1, 2, 3)
6. (Others which call 1, 2, 3, 4)
7. tty_read
8. setStandardProcedure (Calls 1, 7, 3)


Onstep:
21. sendOnStepCommandBlind (Calls 2, 3)
22. sendOnStepCommand (Calls 3, 7, 1)

As far as I can tell, (I'd have to double check) we just need to handle the ones in bold. (And I just realized there was a duplicate getCommandString)

Attaching All_PortFD (a grep of lx200_OnStep.cpp) and All_fd (a grep of lx200driver.cpp) So people can double check, but it looks like what we can do for checksumming is to override 1, 2, 3, 7 from my list above.

So if we do that:
1. We should get a standard LX200 frame :ABccccdd#
2. We would then need to give it a checksum sequence number, change the : to ; and possibly a queue? to deal with re-transmits.
2A: So that will now look like ;ABccccddXXS# (SInce I already used 'c' Xs are the checksum and S the sequence)
3. We will always get a reply, which at the minimum will be the sequence number.

Will that mess up the read function (getCommandString) it seems like it will, so we need to add that.

As far as the queue, I'd think of it, as simply a couple of saved ones, and a retire on receipt of the message? Or should we do something more?


Here's how that's handled:
Checksums:Note the :60# (char 6, not number 6) causes this: (In case you wondered how the comment above is true.)Which with checksums is always going to be of the form (Sequence as _) CK_FAIL09_# (Because that's what CK_FAIL checksums as...)


Example with reply:
Send: :A?#
Receive: 600#
Send: ;A?80A#
Receive: 60096A#

Example without normal reply:
Send: :Ms#
Receive: Nothing
Send: ;MsC0A#
Receive: 00A#
Send: ;MsC0B#
Receive: 00B#

Calcuate checksums (in python if you want to play with it manually), with attached file, to make it easy (rename to .py or C&P to oschecksum.py):


Is that clear to everyone? Have I missed anything before I start on it? Do we need a queue to handle the retransmits? Hopefully that was all comprehensible. (I'm submitting without looking it over before I lose a long forum post!)

Alain
Two things first
One, Kudos or so call Karma's for you, to extent the success of howard in to the INDI platform i think that must be said!!!
Secondly i agree with Khalid, Wifi is not the part of connection if you want to build a remote Observatorium, you must relay on your connection. But from home to garden setup i think its no problem.

About the message didn't received that message any more. but still that extra GR# ind the mount status in error.
Yesterday i reinstalled my machine, hardway to get a clean install. But with out succes still the same.
I am very busy on this moment i hoop in the weekend to make clear debug trace of mount with USB and WIFI to give you some more information i also will test this on raspberry because in the end i like to move to that direction like your setup. Because i appreciate that you dive in this issue if i don't react it is strange so there for also this message that you know .

Chris

I also agree it's not a great way to go. I was just impressed by the connection working. I've used wifi to the mount side server before and it's terribly slow and unreliable. At one point I had a long range dongle up on a stick to reach into the house! I use a 1gig cat5e line to the mount computer and usb for everything from there. I use two runs of the stuff to reach north and south facing brick pads in both yards.
I had to rob parts from my OnStep rig to get the new mount going but I have all intentions of setting it back up using older parts(rpi3/canont1i etc.) for general wide field use and testing sometime soon.

Clear skies!

but seeing is a 1...

Here is an update on the reset issue some have faced with Ubuntu 18.04.

My astro laptop's SSD drive failed, and replaced it with more recent used laptop and a new SSD with more capacity. I was running Xubuntu 16.04 LTS up to this point. So I took the opportunity and re-installed the new laptop with Xubuntu 18.04 LTS.

I tested with my OnStep STM32, and never saw a need for resetting, or failure to connect in the several times I tested with KStars.

The only thing I did was to run this command after everything was installed:

Other than that, nothing special. It all just works.

Note that Arduino based OnStep has a reset issue after the initial connection, and reported in the mailing list. I have no Teensy based OnStep to test with.

Alain,
I remember you mentioned that you have a branch which you wanted to stabilise and submit to mainstream. Could you please let me know what is this branch and if you had a chance to test it?