OpenCPN IC-M510E AIS

[Larfalitl]

Hi All,
Yesterday bought an ICOM IC-M510E AIS, that has the integrated AIS receiver, and WiFi. My hope was I could get it to pass the AIS data over WiFi to OCPN on an Android tablet. Ultimately it works, but there are some oddities. My ICOM has firmware 1.102 and may not work on older firmware, maybe it can be upgraded though?
In OCPN.
Data Connections, add a Network connection, UDP, NMEA 0183, the IP address of the ICOM and the DataPort set in the ICOM.
In the ICOM, Menu, Settings.
NMEA, Baudrate 38400bps, not sure this is necessary, it may only be for the wired connection.
NMEA over WLAN, function, ON. Destination IP, the IP address of the tablet. Destination Port needed for the above.
Needless to say I had some grief setting this up and ended up using WireShark to see what was going on.

The ICOM can be configured to use a Destination IP of 239.192.0.4, which is a multicast address I found here "https://docs.advancednavigation.com/gnss-compass/Operation/NMEA%200183.htm"
The ICOM will happily send the data to this address & port. But OCPN won't receive it on the tablet. This may be a foible of Android, haven't tried a laptop as yet.
The benefit of using a multicast address is multiple devices can receive the AIS data stream. A laptop at the chart table & a tablet at the helm. Another tablet in the skippers cabin perhaps, or near the sea berth.

Was wondering can anyone shed light on why OPCN doesn't receive the multicast data on an android tablet?

Cheers
Graeme

[wholybee]

Originally Posted by Larfalitl

Hi All,
Yesterday bought an ICOM IC-M510E AIS, that has the integrated AIS receiver, and WiFi. My hope was I could get it to pass the AIS data over WiFi to OCPN on an Android tablet. Ultimately it works, but there are some oddities. My ICOM has firmware 1.102 and may not work on older firmware, maybe it can be upgraded though?
In OCPN.
Data Connections, add a Network connection, UDP, NMEA 0183, the IP address of the ICOM and the DataPort set in the ICOM.
In the ICOM, Menu, Settings.
NMEA, Baudrate 38400bps, not sure this is necessary, it may only be for the wired connection.
NMEA over WLAN, function, ON. Destination IP, the IP address of the tablet. Destination Port needed for the above.
Needless to say I had some grief setting this up and ended up using WireShark to see what was going on.

The ICOM can be configured to use a Destination IP of 239.192.0.4, which is a multicast address I found here "https://docs.advancednavigation.com/gnss-compass/Operation/NMEA%200183.htm"
The ICOM will happily send the data to this address & port. But OCPN won't receive it on the tablet. This may be a foible of Android, haven't tried a laptop as yet.
The benefit of using a multicast address is multiple devices can receive the AIS data stream. A laptop at the chart table & a tablet at the helm. Another tablet in the skippers cabin perhaps, or near the sea berth.

Was wondering can anyone shed light on why OPCN doesn't receive the multicast data on an android tablet?

Cheers
Graeme

What IP address are you entering in the OCPN configuration? It should be the same multicast address.

There are other ways, however. You should be able to in the ICOM enter the network address with the last octet as 255, and it will send to everything on that network. For example, 192.168.1.255 would send to any address that starts as 192.168.1. This is called "Broadcast" instead of multicast.

In OpenCPN, either enter the IP address of OpenCPN(if the ICOM is sending directly to that IP address or the network address), or the multicast IP address if using that. Or, I think 0.0.0.0 will listen to everything (on that port)

You should not need to use Multicast to send to multiple clients. The only real reason to use multicast is if you had multiple sources, and you wanted one source to send to a group of clients, and another source to send to a different group of clients.

[stevead]

Unfortunately Icom don't make it easy to determine whether they transmit NMEA 0183 over WiFi using TCP or UDP. (refer to attached image)

Assuming you have configured the Icom IC-M510E to operate in either Access Point or Client mode and that your Android device is correctly configured and is connected to the correct WiFi network and has a valid IP address.

If you've configured the IC-M510E in Access Point mode, take note of the IP address and Subnet Mask that you have configured.

Take note of your Android device's IP address. Equally unfortunate, I don't believe Android devices display the IP broadcast address, so you have to guess/make assumptions.

For this scenario, lets assume your Icom IP address is 192.168.1.1, your Android's IP address is 192.168.1.21, the subnet mask is 255.255.255.0 and consequently the broadcast address is 192.168.1.255

1. UDP. Unicast (only one device on the same network will receive)
On the IC-M510 NMEA over WLAN, configure the IP address to be 192.168.1.21 (the Android IP address) and port 10110 (the IETF standard port number for NMEA 0183).

For OpenCPN configure a Network NMEA 0183 connection using UDP with 192.168.1.21 for the IP address and 10110 for the port. Using 192.168.1.21 means that the Android device will listen on that interface. Alternatively you could use 0.0.0.0 which means listen on all interfaces.

2. UDP. Broadcast (multiple devices on the same network will receive)
On the IC-M510 NMEA over WLAN, configure the IP address to be 192.168.1.255 (the broadcast address) and port 10110.

For OpenCPN configure a Network NMEA 0183 connection using UDP with either 0.0.0.0 or 192.168.1.21 for the IP address and 10110 for the port.

2. TCP (Only one device will receive)
On the IC-M510 NMEA over WLAN, configure the IP address to be 192.168.1.21 (the IP address of your Android device) and port 10110.

For OpenCPN configure a Network NMEA 0183 connection using TCP with 0.0.0.0 for the IP address and 10110 for the port. For TCP, using 0.0.0.0 means OpenCPN will act as a TCP Server and listen for incoming connections.

3. And as an experiment, Multicast UDP, although in your scenario, unnecessary.
On the IC-M510 NMEA over WLAN, configure the IP address to be 239.192.0.4 (a multicast UDP address) and port 10110.

For OpenCPN configure a Network NMEA 0183 connection using UDP with the multicast IP address 239.192.0.4 and 10110 for the port.

One can only assume that Icom correctly configure the network adapter and "join" the multicast group. The other big assumption is whether the Icom Wireless LAN router, or your own WiFi Router supports IGMP and multicast UDP.

Note that much of this is available in the OpenCPN user manual (not that anyone bothers to read it). And there is a brief discusion about Multicast UDP, albeit in the context of mDNS on another thread

Subtle correction for both you and Warren. The reason for using multicast UDP is that it can traverse networks. It is an efficient mechanism for transmitting data from one to many. On the other hand, Unicast and Broadcast UDP are not transmitted beyond their own network.

[Larfalitl]

Success!!

Thank you both for pointing me in the right direction.

> What IP address are you entering in the OCPN configuration? It should be the same multicast address.
This is correct.

> Unfortunately Icom don't make it easy to determine whether they transmit NMEA 0183 over WiFi using TCP or UDP. (refer to attached image)
No they don't, hence capturing the data in WireShark. I assure you it is definitely UDP


> 3. And as an experiment, Multicast UDP, although in your scenario, unnecessary.
The Icom's IP address is 192.168.8.10.
Set the Icom to send to 192.168.8.109 (the tablets IP) and OCPN to listen on 0.0.0.0 - works
Set the Icom to send to 192.168.8.108 (not the tablets IP) and OCPN to listen on 0.0.0.0 - doesn't work.
Hence this is very necessary. I have more than one device, and only one destination IP address can be set in the Icom, so the other device will not receive AIS data, unless multicast is used.

The solution:-
> On the IC-M510 NMEA over WLAN, configure the IP address to be 239.192.0.4 (a multicast UDP address) and port 10110.
I used address 224.0.0.8, the 224.x.x.x range is non-routable so it can't wander off-network anywhere.
Icom defaults to port 54195, so used that.

> For OpenCPN configure a Network NMEA 0183 connection using UDP with the multicast IP address 239.192.0.4 and 10110 for the port.
yup, in OCPN Connections,
select Network
select UDP
IP Address of 224.0.0.8 (same as is set in the Icom)
DataPort of 54195 (same in Icom).
Can configure this on mutiple devices, each will receive AIS.

Happy days!
Thanks again for your help.

[wholybee]

Originally Posted by Larfalitl

Success!!

Thank you both for pointing me in the right direction.


> 3. And as an experiment, Multicast UDP, although in your scenario, unnecessary.
The Icom's IP address is 192.168.8.10.
Set the Icom to send to 192.168.8.109 (the tablets IP) and OCPN to listen on 0.0.0.0 - works
Set the Icom to send to 192.168.8.108 (not the tablets IP) and OCPN to listen on 0.0.0.0 - doesn't work.
Hence this is very necessary. I have more than one device, and only one destination IP address can be set in the Icom, so the other device will not receive AIS data, unless multicast is used.

Glad you got it working. But for completeness, if you set the icom to send to 192.168.8.255, and OpenCPN to listen to 0.0.0.0, it should work. 192.168.8.255 is the network broadcast address and will send to all IP addresses from 192.168.8.1 to 192.168.8.254

[Larfalitl]

Originally Posted by wholybee

Glad you got it working. But for completeness, if you set the icom to send to 192.168.8.255, and OpenCPN to listen to 0.0.0.0, it should work. 192.168.8.255 is the network broadcast address and will send to all IP addresses from 192.168.8.1 to 192.168.8.254

No, that should definitely not be done.
I'm not saying it won't work, maybe it will. But you can also drive screws with a hammer ( and no, that shouldn't be done either)

Every device on the network will accept and interpret a broadcast packet, greatly increasing their workload and as a consequence slowing down their response. Do you really want your laptop or phone to be any slower than they are already? Flood them with AIS data would be a great start.

The IT community spent a great deal of time and money creating a better way of doing this and it should be used whenever it's needed.

And stop driving screws with a hammer.

[stevead]

Technically correct albeit with one small correction.

I used address 224.0.0.8, the 224.x.x.x range is non-routable so it can't wander off-network anywhere.

Only addresses in the range 224.0.0.1 to 224.0.0.255 are non-routable. Note that most of these are reserved and some are used for important kind of things like exchange of routing information.

All other addresses in the multicast address range are routeable.

Given that the theoretical maximum number of AIS messages is 2250 messages per minute, do you think that the use of UDP broadcast is going to negatively impact the performance of other devices on the network, especially given some of the nuances of UDP multicast on WiFi networks?

[Larfalitl]

Originally Posted by stevead

Given that the theoretical maximum number of AIS messages is 2250 messages per minute, do you think that the use of UDP broadcast is going to negatively impact the performance of other devices on the network, especially given some of the nuances of UDP multicast on WiFi networks?

The more interesting question to me is, what benefit do you see in encouraging others to do it the wrong way and flooding their devices with AIS packets?
Are you concerned entering 224.0.0.8 is that much larger a hurdle than entering 192.168.8.255?

[wholybee]

Originally Posted by Larfalitl

The more interesting question to me is, what benefit do you see in encouraging others to do it the wrong way and flooding their devices with AIS packets?
Are you concerned entering 224.0.0.8 is that much larger a hurdle than entering 192.168.8.255?

Any switch or router that the traffic passes through has to support multicast in order for the subscriptions to work. That isn't universally supported on small unmanaged switches like would be found on a boat. Depending on what switch you have, it likely is broadcasting the UDP traffic to every port anyway instead of handling the subscriptions. The cheapest switches won't recognize or pass the multicast traffic at all.

Also, not every application supports multicast. Most navigation apps I am sure do not. So if you want to add Navionics to the network, it will probably have to be broadcast.

Broadcast will always work. Using UDP broadcast is NOT wrong. It is a simpler protocol for simpler networks and requirements.