Skywatcher's synscan app fails to connect with ser2net

[olwaldi]

I'm trying to connect the synscan app (running on an android8 tablet) with my synscan EQ mount (being a motorized old Vixen GP). My mount is equipped with the skywather V4 handcontroller (no USB, no WiFi). But I've enhanced it by bluetooth (using the HC-05 module - sadly no BLE). The bluetooth connection works fine if used directly from skysafari V6.

My goal is to use Skywatcher's synscan app for alignment of my scope (instead of using its handcontroller). Sadly my bluetooth module HC-05 does not support BLE - thus it is not supported directly by that app.

From https://stargazerslounge.com/topic/308247-another-alternative-to-sky-watcher-wifi-adapter/page/2/ I've discovered the linux tool ser2net used to forward the rs232 line towards synscan app. Sadly this fails for my bluetooth connection. I'm using ser2net version 4.6.0 with the following yaml config:

connection: &synscan
  accepter: udp,11880
  connector: serialdev,/dev/rfcomm0,9600n81,local
  options:
    trace-read: '/var/log/trace-\o-read'
    trace-write: '/var/log/trace-\o-write'
    kickolduser: true

When I try to connect from synscan app, the 3 characters ":e1" are sent, and my mount replies by its position "AD89E000,3F379C00#" (both within the trace files). But the app fails to connect. Thus I'm convinced that the bluetooth connection is working fine (in both directions) with ser2net.

From another post here I might guess that my problem is the kind of communication - synscan app initiates the communication on port 11880, but expects the reply on an arbritrary selected DIFFERENT port. Using socat I could in priciple proof that by

socat -u UDP-RECVFROM:11880,fork SYSTEM:'echo "${SOCAT_PEERADDR}:${SOCAT_PEERPORT}"'

where SOCAT_PEERADDR is the correct IP from my tablet (with synscan app running) and SOCAT_PEERPORT is some port number (different for each connection try - i.e. when pressing Connect within the app).

 

Do you have successfully used ser2net to communicate with the synscan app? And how did you do that?

My next best solution is to replace my HC-05 module by a newer module  (e.g. AT-09) supporting BLE. Does BLE work at all within synscaan app?

 

Thanks for your interest in my problem, Michael

 

[olwaldi]

I did some other experiments to get a wireless connection between my synscan V4 handcontroller and my Huawei tablet, sadly without success.

Maybe my software on the handcontroller is too old - I'm using 4.39.5 (but I will NOT update because I had much trouble during my first try 6 years ago - it finally worked using Linux/wine + real RS232 interface within my desktop PC, my old USB2RS232 dongle did corrupt the firmware data, even when used from windows OS).

1. AT-09 BLE module

I couldn't even connect the AT-09 with my tablet - it was visible with name BT05, but connection always failed (using different pins 0000, 1234, 000000, 123456).

Using some BLE debugger apps (e.g. DSD TECH Bluetooth). I could send/receive ASCII data if connected via USB/UART dongle using

screen /dev/ttyUSB0 9600

But I was unable to enter AT-09 command mode. If AT-09 is not connected by bluetooth it automatically enters command mode to receive AT modem commands via UART. But all I got was the string "ERROR" for any keypress. That at least proves that baudrate is correct.

Trying BLE connection from within synscan app completely failed. I did NOT connect my mount but inspected possible data using the above screen command. Pressing connect did NOT trigger anything but an immedeate "Connection failure" from synscan app.

 

2. Direct serial connection to validate new USB2RS232-dongle

I've connected my Huawei tablet with a long chain of adapters: USB-C <--> USB-micro <--> OTG <--> FTDI/serial. When pressing Connect within synscan app I got an access request for USB serial - thus I know that my USB/serial adapter seems to be supported. Sadly I couldn't test it any deeper due to missing RS232 cables/adapters. And of course I want to use a wireless connection.

 

My final conclusion: I will no longer try to use the synscan app. Instead I'll stay with skysafari & handcontroller (for alignment).

 

Regards, Michael

 

[malc-c]

Can't really help, but the HC05 is basically a BT virtual com port, so you'll get the basic TX / RX transitions, but an advanced operation may well be above the firmware's ability, or as you say, not up to other BT standards.  What puzzles me is the command :e1 is a request for the mounts firmware version, which normally returns a string  '=vvvvmm' as response where vvvv is the version and mm is the mount type.  But reading the protocol manual, when sent to a handset it returns the position data 

protocol document

 

[olwaldi]

That's an interesting hint. Maybe the more recent firmware within skywatcher's mount do handle :e1 differently, see e. g. https://www.cloudynights.com/topic/656206-diy-wifi-adapter-for-skywatcher-telescope-mounts/page-3

As I wrote my mount's firmware is some versions behind. 

I've even tried the PC direct mode without success. 

 

Regards, Michael

[olwaldi]

Now I do believe that it is mandatory to enable PC-direct mode within my EQ mount. In that mode my mount replies with a version information:

synscan :e1
mount   =020402

Both strings are terminated with a carriage return (i.e. "\r").

Sadly synscan pro app still does not connect with my mount. But it even discovers the IP address automatically, i.e. no need to enter it manually.

 

Regards, Michael

[malc-c]

In "PC-Direct" mode the handset acts as an EQDir cable and passes through the commands, hence it now returns the firmware version of the motor board in the mount.  

Sorry I can't help further as I never used a wireless set up.

[olwaldi]

Maybe the connection between bluetooth adapter HC-05 and mount has to use the RJ45 8pin handcontroller port  on the mount and NOT the RJ12 auxiliary port on the handcontroller?

Currently I have plugged in both simultaneously: V4 handcontroller to RJ45 from mount AND HC-05 module to auxiliary port of handcontroller.

 

Regards, Michael

 

[olwaldi]

Now I've tried to debug the UDP traffic using tcpdump when synscan pro is trying to connect:

mount = PC-direct
app   = TABLET, no broadcast

# tcpdump -s 0 host TABLET and udp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:19:39.240388 IP TABLET.45560 > SERVER.11880: UDP, length 4
19:19:39.290710 IP SERVER.11880 > TABLET.45560: UDP, length 1
19:19:39.304042 IP SERVER.11880 > TABLET.45560: UDP, length 7

write - 2024/03/05 19:19:39 OPEN (ipv6,::ffff:TABLET,45560)
:e1
read - 2024/03/05 19:19:39 OPEN (ipv6,::ffff:TABLET,45560)
=020402

To me this looks fine - my TABLET sends from synscan app ":e1\r" and my mount answers with "=020402\r". But synscan app still cannot connect.

That's a good looking sample. But I've also seen tests where the app is sending its message three times within one UDP packet like ":e1\r:e1\r:e1\r" - and my mount also answers 3 times within one reply packet. Sometimes my mount seems to give up and starts to reply with its coordinates.

 

Hope that someone here might have an idea ...

Regards, Michael

Some additional mystery:

From the above tcpdump I'd conclude that communication is using ipv6. If I enforce ipv4 (by adding "ipv4," in front of 118800 within ser2net.yaml) my mount now reflects back ":e1" for each connect request from synscan app.

Edited March 7 by olwaldi
some new information