Hi,

I have a eq3-2 synscan mount connected on a raspberry pi via a serial cable and serial to usb converter.
I used kstars/ekos on a PC connected on the same network as the raspnerry via a router. All is wired connection.

When I slew to some object the mount controler of Kstar return (Status:"slewing" an then Status:"tracking", which is perfect.

After some time (typically 15mn 30mn but sometime more than 1hour) the mount controler of Kstars return Status "error" and then Status "Idle".

If I go in the log I see:

[2019-01-12T17:02:13.042 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] Goto - JNow RA: 2.91194 JNow DE: 89.3483 J2000 RA: 2.51414 J2000 DE: 89.2679 "
[2019-01-12T17:02:13.048 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] CMD <a#> "
[2019-01-12T17:02:24.015 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] CMD <Ka> "
[2019-01-12T17:02:24.078 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] RES <a#> "
.....
<1A9F0400,3F7F1700#> "
[2019-01-12T17:02:24.265 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] CMD <Ka> "
[2019-01-12T17:02:24.265 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] RES <a#> "
.....
[2019-01-12T17:11:02.227 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] RES <#> "
[2019-01-12T17:11:02.236 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] CMD <e> "
[2019-01-12T17:11:02.290 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] RES <1AE26400,3F710C00#> "
[2019-01-12T17:11:02.342 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] CMD <Ka> "
[2019-01-12T17:11:04.293 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] RES <> "
[2019-01-12T17:11:04.356 Paris, Madrid INFO ][ org.kde.kstars.indi] - SynScan : "[WARNING] Synscan Mount not responding "
[2019-01-12T17:11:04.365 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] Abort mount... "
[2019-01-12T17:11:04.372 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] CMD <T> "
[2019-01-12T17:11:04.379 Paris, Madrid DEBG ][ org.kde.kstars.indi] - SynScan : "[DEBUG] RES <#> "
........

How could I solve this problem?

Thank for an advices

Update: I finally launch kstars directly on the rasperry pi to se if this could solve the issue, however the error is the same, so it is not an error linked to the networking.

Not specific to this issue. But random dropouts are often attributed to a handful of common faults such as loose contacts, power fluctuations, cold temperatures. some suggestions to troubleshoot such issues may be, swapping cables, a powered USB hub, testing indoors.

Best of luck.

Thanks.. I checked the code and I need to spend on some to make it more resilient. Will start today.

A possible short term solution while the ever hard working Jasem does some coding you could put your hand set (assuming you have one ) in between the RPI and the mount. Connect the hand set to the mount as normal and the serial cable(used for firmware updaes) from the handset connected to the pi usb via a RS232/USB (Note the RS232 not TTL big difference voltages).
You only have to make sure the handset is up to date firmware (see Indi Synscan i think has the details). No setting up needed for the handset at all (really only acting as a relay device) BUT this method doesn't seem to be effected with your problem - I have run many times this way for hrs on end with no problems.

Or just wait for the updated solution from Jasem

P.S. Just a thought and should NOT happen if wired BUT try switching off the power save on the RPI wifi comms - google it - something like "iwconfig wlan0 power off"

Thanks Jasem

I precise bit more: when the problem occurs, the tracking is aborted by the driver.
A least it would be good idea not to abort the tracking which goes perfectly well.

Regards

Hi Stash

This is already exactly the type of connection I use from the handset to the RPI.
Today I tried "iwconfig wlan0 power off" but I had the same problem occuring ofter 1àmn of tracking....

I'm now working on writing a completely new Synscan driver.. though it beats me why Synscan users won't just get a cable and use EQMod driver.

At any rate, the existing driver will be renamed to legacy, and this will be the standard. It will support custom slew rates and guiding. Maybe in a week.

Then it is NOT,IMHO, 100% guaranteed to be the Synscan driver at fault - I have been using it for 9mths with no problems AND I USE WIRELESS ethernet RPI not wired - mount connection is wired obviously. OK your mount is a EQ and my 2 "Grab & Go" are AZ but the SW protocol is so similar for both.

What type of RS232 USb Adapter are you using (FDTI,Prolific etc) could this be the source of your problem. I have used both Prolific and FDTI adapters but settled on FDTI - more expensive but never a problem (touch wood)

Another test could be to use Indi Synscan driver on the RPI connected to Synscan App(via TCP port 11882 or 11885 - check I cant remember), via Serial for the mount ,running on Windows with the same cables/adapters and see if that drops the link. The Synscan App(pro) has some statistics (repeats,speed in MSec groups) and can perform min network tests.

Are you sure that the Router(and cables) are working ok ? Most routers have a log which might shed some light on the problem (but dont hold your breathe )

As I say mine works so I would have hoped yours would too all things being equal. But being computer software etc nothing is 100% true.

Sorry Jasem but last time I tried EQMOD (on Linux/Indi) it would not drive my SW GoTo AZ mounts and using Synscan Indi driver by itself had parking issues. Can you guarantee EQMOD will now work with my SWAZGoto's without problems (no such thing as none ). Hence the use of the handset !

I did try the SWAZGTI Indi driver but that was even worse - in my experience

If EQMOD could drive all my mounts safely and 95% of the time that would be great but I do not wish to loose Clear Skies times - too few as it is.

I quite understand the monolith task of supporting numerous protocols (even if the SW protocols have common code) and appreciate and thank you (and others) for your devotion and hard work

P.S. I was an Windows EQMOD user for 2yrs .

Thanks for you advice STASH
I use a DB9 to USB cable with a CH340 chipset. The fact is that this is a very chip cable.
I will try to get a FTDI cable and test....
For the synscan/eqmod thing, the interest of the synscan is that you can still use the handset without unplugging and reseting, etc.

Hi ,

The CH340 chip is very good I use it all the time for Arduino projects (Nano with CH340 etc)

Yep my reasoning too - if all else fails I can still use the handset without too much disruption Plus if this year SW bring out a Linux version of Synscan App pro (it already runs ok under WINE for TCP/UDP connections) I will then replace the handset and be able to connect Windows Ascom aware App's thru SW Synscan Mobile Ascom plugin and have the best of both worlds

If network comms are causing problems you should see info in the Linux logs and IFCONFIG will shows high loss. It doesn't sound right for TCP to cause problems to serial but in my case it was nearly doing a "deadly embrace" and hogging the CPU's - but this caused problems with a GPS USB plugin and at the time I wasn't using the Wifi it was hard wired . But as I say check your linux logs etc.

Another thought - power supply what are you using to power the RPI and are the cables high enough AWG to carry current. Do you have a lot of kit plugged into the RPI ? Have you a powered hub ? Just open idea's

Hi

I made a mistake, my cable seems to be a Prolific one: this is the kernel report
[702426.075714] usb 1-1.2: new full-speed USB device number 15 using dwc_otg
[702426.177946] usb 1-1.2: New USB device found, idVendor=067b, idProduct=2303
[702426.177960] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[702426.177967] usb 1-1.2: Product: USB 2.0 To COM Device
[702426.177974] usb 1-1.2: Manufacturer: Prolific Technology Inc.
[702426.178794] pl2303 1-1.2:1.0: pl2303 converter detected
[702426.191602] usb 1-1.2: pl2303 converter now attached to ttyUSB1

Hi, some update:
I received today a FTDI USB cable (see below the dmesg of the RPI)
I slew to an object and the tracking has now been running for 2 hours without any failure!!!
Thanks you very mush STASH for your suggestion!!!

dmesg
[334932.601293] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
[334932.728768] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
[334932.728789] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[334932.728802] usb 1-1.2: Product: FT232R USB UART
[334932.728814] usb 1-1.2: Manufacturer: FTDI
[334932.728826] usb 1-1.2: SerialNumber: A50285BI
[334933.920049] usbcore: registered new interface driver ftdi_sio
[334933.920112] usbserial: USB Serial support registered for FTDI USB Serial Device
[334933.920262] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[334933.920369] usb 1-1.2: Detected FT232RL
[334933.923480] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[335001.991928] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[335002.095577] usb 1-1.3: New USB device found, idVendor=04a9, idProduct=3145
[335002.095597] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0