OpenCPN not dispaying data from LWE multicast GPS

[PGDO]

I am trying to connect a SAAB R5 GPS to a computer network via a switch.


Output from de SAAB is IEC 61162-450 LWE compatible
SAAB IP addres set at 192.36.66.82
Computer IP address 192.36.66.xxx
I can ping the SAAB without problems.
Wireshark shows GPS data on 239.192.0.4 port 60004 which is correct for LWE

So the data is available on the OpenCPN computer, OpenCPN is configured to receive data via UDP on 239.192.0.4 and port 60004 but debug window isn't showing any NMEA data.

My current thoughts are that OpenCPN is not parsing the datastring correctly.

Wiresharp datastring dump
0000 01 00 5e 40 00 04 da 3b c3 33 28 8d 08 00 45 00 ..^@...;.3(...E.
0010 00 84 00 00 40 00 01 11 87 2e c0 24 42 52 ef c0 ....@......$BR..
0020 00 04 ea 64 ea 64 00 70 88 1e 55 64 50 62 43 00 ...d.d.p..UdPbC.
0030 5c 73 3a 47 50 30 30 30 31 2c 6e 3a 31 39 34 2a \s:GP0001,n:194*
0040 31 42 5c 24 47 50 52 4d 43 2c 30 30 30 31 35 37 1B\$GPRMC,000157
0050 2e 30 30 2c 41 2c 32 31 32 30 2e 36 38 35 33 38 .00,A,2120.68538
0060 2c 4e 2c 30 38 39 34 30 2e 36 30 32 33 32 2c 57 ,N,08940.60232,W
0070 2c 30 2e 30 30 2c 31 36 39 2e 32 35 2c 31 34 30 ,0.00,169.25,140
0080 36 31 39 2c 30 2e 34 2c 57 2c 44 2c 53 2a 34 42 619,0.4,W,D,S*4B
0090 0d 0a ..



Anybody any thoughts on this?
Anybody who knows a program which can convert the Multicast LWE UDP data to normal NMEA 0183 and put it on the network again?

[rgleason]

So the data is available on the OpenCPN computer, OpenCPN is configured to receive data via UDP on 239.192.0.4 and port 60004 but debug window isn't showing any NMEA data.

Looks like you have the address all right.


What baud rate? What are your OpenCPN connection settings?
Screenshot please.

What baud rate is the GPS sending at?

Maybe a little refresher with the manual will help
https://opencpn.org/wiki/dokuwiki/do...ections_window

If you get the Connections settings right, and baud right, it will stream nema0183.

[Hakan]

PGDO..
In OCPN connections try a network input connection and set Network address: 0.0.0.0 Network port: 60004
-> Apply
(The address 239.192.0.4 is another network you'll never reach)

Show NMEA Debug window and see what's received.
Håkan

[PGDO]

@rgleason
Connection to GPS is by Ethernet not com port.

@HAKAN
I tried following IP addresses;
0.0.0.0
192.36.66.82 (IP address of GPS)
239.192.0.4 (IP address of multicast)

All the same result, no data in debug window
Is the debug window supposed to showing only valid NMEA sentences or also raw data?

As you can see in attached screenshot Wireshark sees GPS data coming from 192.36.66.82 with destination 239.192.0.4 Light Weight Ethernet (LWE) as per IEC 61162-450 specs.

Since Wireshark sees the data I still think that the problem is with OpenCPN LWE support.

Looks like I have to write a translation program (like GPSGate) for IEC 61162-450 spec navigation equipment as I haven't found one yet.

[rgleason]

"Connection to GPS is by Ethernet not com port."

Who said that? ... I guess I did, by suggesting baud rate.

[PGDO]

Originally Posted by rgleason

Who said that? ... I guess I did, by suggesting baud rate.

Yep, you did but thanks for taking the time to respond.

[bdbcat]

PGDO...
Congratulations. You may be the first person in the universe to try OCPN with IEC 61162-450.
And, unsurprisingly, it probably does not work out of the box without at least some internal tweaking to the TCP/IP parameters setting up the connection, and probably also the packet parsing logic.

So I guess we will start looking for a low-end device that speaks 61162-450, and work out a solution.


Thanks for the heads-up.
Dave

[PGDO]

Hi Dave,


Yes not the run of the mill kind of system I am interfacing with. Bridge is a Wärtsilä SAM Electronics setup. I want to use OpenCPN in my cabin as I have been doing on other vessels for the past 6+ years but am having a hard time getting the sensor data on the network here.


I might resort to using the pilot plug, not my preferred method of interfacing but probably the easiest. Bought myself a secondhand Cenkin AIS pilot plug which I will get onboard in 3 weeks time.


I will probably be writing a interface program myself just for the fun of it although my programming skills are a bit rusty at the moment.


If you decide to add support for IEC 61162-450 in OpenCPN I would be willing to test it as long as I am on board which is 50% of the year.

By the way, respect for OpenCPN it has some good features and compares well with regard to professional ECDIS systems (SAM and Transas).



Best regards,
Peter

[bcn]

Peter,

can you please take a run with Wireshark and the publish the file?
If you would not like to post it here, you can drop it by mail to us at o-charts.

Thanks

Hubert

[PGDO]

Hubert,


Would you also like a Wireshark file with from a IEC 61162-450 LWE AIS?


Regards,
Peter

[bcn]

Yes please,

the more different data, the better.

Hubert

[Hakan]

Originally Posted by PGDO

@rgleason
Connection to GPS is by Ethernet not com port.

@HAKAN
I tried following IP addresses;
0.0.0.0
192.36.66.82 (IP address of GPS)
239.192.0.4 (IP address of multicast)

All the same result, no data in debug window
Is the debug window supposed to showing only valid NMEA sentences or also raw data?

As you can see in attached screenshot Wireshark sees GPS data coming from 192.36.66.82 with destination 239.192.0.4 Light Weight Ethernet (LWE) as per IEC 61162-450 specs.

Since Wireshark sees the data I still think that the problem is with OpenCPN LWE support.

Looks like I have to write a translation program (like GPSGate) for IEC 61162-450 spec navigation equipment as I haven't found one yet.

I do think the address 0.0.0.0 would have worked since this is more or less the same as "read what's on the host" on the UDP port specified.
But...(What I can find out...)
Even though 61162-450 is said to be based on the data part for protocol 61162-1 the messages $GPRMC from your Wireshark capture is not like what's stated in 61162-1.
The message

$GPRMC,000157.00,A,2120.68538,N,08940.60232,W,0.00,169.25,140619,0.4,W,D,S*4B 10 13

has an extra field at the end. ("S"). (But CR LF are there) This is strange since the aim for 61162-450 is that it should be usable in connection with old instrumentation on a ship???

So, even if the massage is received it's not understood by O. Dave's conclusion and forward look out is therefor as usual correct.

Håkan
Edit: Sorry: Not an extra C in the message ID.

[conachair]

Originally Posted by Hakan

The message

$GPRMC,000157.00,A,2120.68538,N,08940.60232,W,0.00,169.25,140619,0.4,W,D,S*4B 10 13

has an extra field at the end. ("S"). (But CR LF are there) This is strange since the aim for 61162-450 is that it should be usable in connection with old instrumentation on a ship???

So, even if the massage is received it's not understood by O. Dave's conclusion and forward look out is therefor as usual correct.

Isn't the ",D,S" extra to the nmea spec?
https://www.trimble.com/OEM_Receiver...sages_RMC.html

Anway, just tried sending "$GPRMC,000157.00,A,2120.68538,N,08940.60232,W,0.0 0,169.25,140619,0.4,W,D,S*4B" with added '\r\n' from node red to openplotter and opencpn put the boat in the Yukatan, so O seems to accept the message?

[bcn]

Originally Posted by Hakan

$GPRMC,000157.00,A,2120.68538,N,08940.60232,W,0.00,169.25,140619,0.4,W,D,S*4B 10 13

has an extra field at the end. ("S"). (But CR LF are there) This is strange since the aim for 61162-450 is that it should be usable in connection with old instrumentation on a ship???

From the 2008 paper about NMEA4.0/4.1:

0183 Advancements for v4.10
 S=Safe
Navigational Status Indicator (IEC 61108)
estimated positioning accuracy (95% confidence)
integrity meets requirements of navigation mode
calculated within 1 s for a conventional craft and 0,5 s for a high speed craft

 C = Caution - integrity is not available

 U = Unsafe
Positioning accuracy below selected accuracy of navigation mode
Integrity exceeds the requirements of navigation mode
Not calculated within 1 s for a craft and 0,5 s for a high speed craft

 V = Navigational invalid, No navigational status indication.

Expanded GNSS Mode Indicator Definition for “P”
 P = Precise - Satellite system used in precision mode.

Precision mode is defined as: no deliberate degradation (such as Selective Availability) and higher resolution code (P-code) is used to compute position fix. P is also used for satellite system used in multi-frequency, SBAS or Precise Point Positioning (PPP) mode

and

0183 Advancements for v4.10
 RMC – Recommended Minimum Specific GNSS data

Expanded Mode Indicator Value (P=Precise)
Additional Navigational Status Indicator field

[rgleason]

This raises some questions. Should o be 4.10 compliant? How many other inst changed?

Should the nema0183 manual be amended if this is implimented?
How many other inst changed?