Still trouble running NMEA data stream and Radar in parallel. Any help?

[Franziska]

Originally Posted by s/v Jedi

For UDP traffic you also need to define the UDP port which is to be used. The port number must be the same on each device that sends or receives that UDP data.

I don’t understand why this port number isn’t mentioned by anyone?

Port is 10110.


I do receive the stream on my devices, just not when I switch the radar on. Than the stream dies.

[Be Free]

Before we get off track... When you ran the ping command was the Ethernet cable active?

[wholybee]

Originally Posted by s/v Jedi

For UDP traffic you also need to define the UDP port which is to be used. The port number must be the same on each device that sends or receives that UDP data.

I don’t understand why this port number isn’t mentioned by anyone?

It was clear in Franziska's screen shots that the port was set correctly. Her issue is that UDP broadcast from OpenCPN works fine(despite using an obviously incorrect IP address of 192.168.43.152.x.x on the connections tab), until she plugs her radar into the Ethernet port. So trying to get UDP broadcast to work normally with an IP address not appended with .x.x

[Be Free]

Franziska, I think you misread my earlier post. Please try the connection with 192.168.1.255

That will (according to the manual) cause the UDP message to be sent to the network broadcast address. You should not need to change anything on the phones as long as they are hooked to the same WIFI as the PC.

[wholybee]

The following is working on my test system. OpenCPN 5.9.0 so it looks a bit different. The connection to 127.0.0.1 is a SignalK server outputing test data.

[s/v Jedi]

Okay, port is set correctly.

Next thing: who knows something about the radar scanner IP? I kind of think that it will try to find a DHCP server when starting up.

You can simply connect it to a LAN port of the router and give it an address in the same subnet, averting the whole mess about Windows trying to do TCP/IP.

[Be Free]

Jedi, the radar is working properly. The problem we are trying to fix is on the wireless connection to other devices.

[Franziska]

Originally Posted by Be Free

Before we get off track... When you ran the ping command was the Ethernet cable active?

Yes radar was on.

[Franziska]

Originally Posted by Be Free

Franziska, I think you misread my earlier post. Please try the connection with 192.168.1.255

That will (according to the manual) cause the UDP message to be sent to the network broadcast address. You should not need to change anything on the phones as long as they are hooked to the same WIFI as the PC.

Here you go, radar was on:


Microsoft Windows [Version 10.0.19045.4170]
(c) Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Catamaran Lady Rover>ping 192.168.1.255
Ping wird ausgeführt für 192.168.1.255 mit 32 Bytes Daten:
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
Ping-Statistik für 192.168.1.255:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),
C:\Users\Catamaran Lady Rover>

[Be Free]

Were still missing each other (just barely). I need you to put the 192.168.1.255 in the UDP connection on OpenCPN in place of the 192.168.43.152.x.x


On a much lighter note: the ping command in the format you just entered it used to be used for creating a denial-of-service attack a long time ago.

Fortunately (these days) most machines refuse to respond to it by default.

[Franziska]

Originally Posted by Be Free

Were still missing each other (just barely). I need you to put the 192.168.1.255 in the UDP connection on OpenCPN in place of the 192.168.43.152.x.x


On a much lighter note: the ping command in the format you just entered it used to be used for creating a denial-of-service attack a long time ago.

Fortunately (these days) most machines refuse to respond to it by default.

YOU ARE MY HERO!
RADAR & DATA STREAM WORK IN PARALLEL.



THANK YOU SO MUCH ❤️


If you are ever close happy to take you sailing, drinks included ��


Attached the screenshot of the UDP in OpenCPN and a screenshot in the settings of the free Android app NavMonitor.


Click on the images to see them better.

[s/v Jedi]

Originally Posted by Be Free

Jedi, the radar is working properly. The problem we are trying to fix is on the wireless connection to other devices.

I know. There are multiple ways of doing that. Creating two TCP/IP interfaces on a Windows computer, one wired and one wireless, is one option. You can also connect both NMEA and the radar over just one interface, even just the wireless interface if it is fast enough and this is what I would recommend (being a network engineer)

[rgleason]

Well OP and Heros, the manual needs some assistance.
I've reported/written this up Windows Wifi Router and Ethernet with Radar but it is very rough. We need this information to be condensed and polished up and with confirmation as well. Thanks.

Be Free in Post 42 says the manual is "Less than clear" about this.
where in the manual is it unclear about this topic? Please give me the location.

Also it would be helpful if you suggested the clarification wording. Thank you.

[stevead]

Dare I say it, but we may need a "dummies guide to networking".

This is probably, more of a summary of the thread, however in this case, the user needed to know:
1. In general Radars will use a DHCP Server to obtain an IP address. However as the radar was directly connected to the PC, and not via a router with a DHCP Server, or with no DHCP Service running on the PC, both the PC and Radar will use an autoconf address in the range 169.254.0.0 to 169.254.255.255.

2. For receiving or transmitting NMEA 0183 data via WiFi, once the PC has connected to the WiFi Access Point with the correct SSID and Password, the user MUST know the IP Subnet.

On Windows this is easily performed from a command prompt with the ipconfig command, and on Mac OSX and Linux, from a terminal using the ifconfig command.

Most "consumer grade" WiFi Access Points (including those included in marine gateways from Actisense, Yacht Devices, Ship Modul) create a Private Network using IP addresses from the range 192.168.0.0 to 192.168.255.255.

Let's say for example the output from ipconfig indicates that the PC's IP address is 192.168.1.104 and the Subnet Mask is 255.255.255.0. This infers that addresses will be allocated from the range 192.168.1.0 to 192.168.1.255, although 192.168.1.0 is usually not assigned and 192.168.1.255 is reserved as the broadcast address.

In this specific example, the user wanted to transmit NMEA 183 data from OpenCPN to another device using UDP. It was just a matter of configuring an OpenCPN outbound connection, using the broadcast address (in this case 192.168.1.255) and a port number, ensuring the same port number is used by the other devices. Port 10110 is the default port number for NMEA 183.

The last thing to note is that for most devices, if receiving data via UDP, an IP address 0.0.0.0 means that the device will listen on all of its network adapters.

What exacerbated the problem was two things.

Firstly that Windows 10, automagically disconnected the Wifi when an Ethernet connection existed. While the user did change the VLAN & Priority setting via Group Policy, Group Policy changes are not automatically applied. They are only applied if the user logs on, the machine restarts or a specific time period has elapsed. To force an immediate update of Group Policy, from a command prompt run the command gpupdate /force.

Secondly the information the French guide "Pratiques et Techniques" is patently wrong in depicting an incorrect IP address format.

In reality, OpenCPN should have checked that a valid IP address was entered and not blindly accept an address of the form 192.168.43.152.x.x.

[s/v Jedi]

Originally Posted by stevead

Dare I say it, but we may need a "dummies guide to networking".

This is probably, more of a summary of the thread, however in this case, the user needed to know:
1. In general Radars will use a DHCP Server to obtain an IP address. However as the radar was directly connected to the PC, and not via a router with a DHCP Server, or with no DHCP Service running on the PC, both the PC and Radar will use an autoconf address in the range 169.254.0.0 to 169.254.255.255.

2. For receiving or transmitting NMEA 0183 data via WiFi, once the PC has connected to the WiFi Access Point with the correct SSID and Password, the user MUST know the IP Subnet.

On Windows this is easily performed from a command prompt with the ipconfig command, and on Mac OSX and Linux, from a terminal using the ifconfig command.

Most "consumer grade" WiFi Access Points (including those included in marine gateways from Actisense, Yacht Devices, Ship Modul) create a Private Network using IP addresses from the range 192.168.0.0 to 192.168.255.255.

Let's say for example the output from ipconfig indicates that the PC's IP address is 192.168.1.104 and the Subnet Mask is 255.255.255.0. This infers that addresses will be allocated from the range 192.168.1.0 to 192.168.1.255, although 192.168.1.0 is usually not assigned and 192.168.1.255 is reserved as the broadcast address.

In this specific example, the user wanted to transmit NMEA 183 data from OpenCPN to another device using UDP. It was just a matter of configuring an OpenCPN outbound connection, using the broadcast address (in this case 192.168.1.255) and a port number, ensuring the same port number is used by the other devices. Port 10110 is the default port number for NMEA 183.

The last thing to note is that for most devices, if receiving data via UDP, an IP address 0.0.0.0 means that the device will listen on all of its network adapters.

What exacerbated the problem was two things.

Firstly that Windows 10, automagically disconnected the Wifi when an Ethernet connection existed. While the user did change the VLAN & Priority setting via Group Policy, Group Policy changes are not automatically applied. They are only applied if the user logs on, the machine restarts or a specific time period has elapsed. To force an immediate update of Group Policy, from a command prompt run the command gpupdate /force.

Secondly the information the French guide "Pratiques et Techniques" is patently wrong in depicting an incorrect IP address format.

In reality, OpenCPN should have checked that a valid IP address was entered and not blindly accept an address of the form 192.168.43.152.x.x.

Exactly, thanks for writing all that, I couldn’t bring myself to it (again). If the router can set fixed DHCP address allocations so that the PC and the radar always get the same address, then the whole Ethernet interface on Windows with all it’s problems could be avoided as everything would run over wifi.