Position Output, Send Error (111)

[lhaughUNIT9 (Luke Haugh)]

Hello,

I am trying to access tracking data from a TCP port but I seem unable to start the service. I’ve connected the device to my local network, and I’m able to connect to the web page & status looks fine and I can see my location on the map.
However when I go to position output, click on TCP, enter

Role: Server
Address: localhost
Port: 6666
Format: NMEA

And hit apply, I get a message saying Waiting… but it never finishes and the port never opens.
Eventually this is replaced with Send Error (111)

System report:

ReachView version 2.10.0

Simple system report

app version: 2.10.0-r0
'wifi_status, interface: wlan0':
- Client state
- IP address: 192.168.0.102
  mac address: fc:db:b3:93:32:e6
  ssid: TP-LINK_QA
base mode:
  base coordinates:
    accumulation: '2'
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - '0'
    - '0'
    - '0'
    format: llh
    mode: single-and-hold
  output:
    enabled: true
    format: rtcm3
    path: tcpsvr://:9000#rtcm3
    type: tcpsvr
  rtcm3 messages:
    '1002':
      enabled: true
      frequency: '1'
    '1006':
      enabled: true
      frequency: '0.1'
    '1008':
      enabled: false
      frequency: '1'
    '1010':
      enabled: true
      frequency: '1'
    '1019':
      enabled: false
      frequency: '1'
    '1020':
      enabled: false
      frequency: '1'
    '1097':
      enabled: false
      frequency: '1'
    '1107':
      enabled: false
      frequency: '1'
    '1117':
      enabled: false
      frequency: '1'
    '1127':
      enabled: false
      frequency: '1'
bluetooth:
  discoverable: false
  enabled: false
  pin: '***'
correction input:
  input2:
    enabled: true
    format: rtcm3
    path: ttyMFD2:38400:8:n:1:off
    send position to base: 'off'
    type: serial
  input3:
    enabled: false
    format: rtcm3
    path: :9028
    type: tcpsvr
logging:
  base:
    format: RTCM3
    started: true
    version: null
  correction:
    format: RTCM3
    started: true
    version: null
  interval: 24
  overwrite: true
  raw:
    format: UBX
    started: true
    version: null
  solution:
    format: LLH
    started: true
    version: null
lora:
  air rate: 2.6000000000000001
  frequency: 868000
  output power: 20
position output:
  output1:
    enabled: true
    format: nmea
    path: :6666
    type: tcpsvr
  output2:
    enabled: true
    format: llh
    path: :2013
    type: tcpsvr
rtk settings:
  elevation mask angle: '15'
  glonass ar mode: 'off'
  gps ar mode: fix-and-hold
  max horizontal acceleration: '1'
  max vertical acceleration: '1'
  positioning mode: kinematic
  positioning systems:
    compass: false
    galileo: false
    glonass: true
    gps: true
    qzs: true
    qzss: true
    sbas: true
  snr mask: '35'
  update rate: '5'

[Simo_Simolin]

I have exactly the same problem with two Reach RS modules (because the problem is identical with two modules then it shouldn’t be module specific bug?). Anybody has a solution to this?

[Simo_Simolin]

Now I know what the problem is! At least for me the problem was that I am amateur at TCP/IP communication and made a stupid rookie mistake.

So the thing is that when the Reach is set as a server, the TCP/IP communication requires that computer acting as a client and retrieving information creates a socket connection to the port specified for the TCP/IP communication (for you it would be 6666). This way the client starts to listen the server port of the Reach module and also responds that the packet was received. After this the “Waiting…” text disappears from the ReachView Position output window and is replaced by “Connected to 192.xxx.xxx.x”. This can be tested by creating a socket connection for example with TCPIP Builder application available here (free software): TCP/IP Builder • drkbugs

I hope this helps.