UDP in/out connection bug

[Corsair-63]

Raspberry Pi 5 - 8GB
Enclosure Neo with NVME SSD connected to PCI connector.
Windows 11 ARM64 up and running ver 22631.3527
O Version 5.9.0-0+10912b6 Build 2024-04-26

no problem with LAN (via USB adaptor) and another devices.

setup the data connection via UDP with the multiplexer, received all data.

also tried to make in/out the connection as my other computer but not able to set both at the same time.
when I click on input the output comes off, viceversa when I click on output the input comes off, could not have both at the same time, and immediately the IP changes to 0.0.0.0

Why the "N" before the 0183? "N" of network?

Also tried in same O version but windows 11 x64, same behaviour.

but in another computer that was set previously of this O version the up/down is available, same os and OCPN (same version and architecture ARM64) with the computer on board Apcsilmic (Qualcomm PC for Windows, 8 GB RAM too).
Up/Down enable without any problem.

[Hakansv]

when I click on input the output comes off, viceversa

"It's not a bug it's a feature" The radio button was implemented to not allow the risk for a endless feedback.

N0183 is a obviously a abbreviation for NMEA 0183. Like N2000 is for NMEA 2000 or N2k. Lack of space and meaning the may be clear in this context.

[leamas]

No bug to be found here, but perhaps some misunderstandings. Converting to discussion

[Corsair-63]

How is not a bug when I cannot setup the NMEA string output in the same device that there are the inputs, how would be controlled e.g. the autopilot, or send information to another devices??

Why I cannot have in the same connection for input/output like in previous versions of OCPN and already setup in one of my computer in previous version of OCPN.

[bdbcat]

You might consider to use another connection for output, using UDP or TCP.
If UDP broadcast output is required, suggest you setup output filters carefully to avoid a feedback loop.

[Corsair-63]

My multiplexer (Shipmodul MiniPlex-3E N2K + 0186) has the option of making either TCP either UDP.

the connection via UDP is done correctly with the autopilot.

5.8.4 allows the bidirectional connection on UDP either TCP, and previous versions of 5.9.0 too but since some versions ago it doesn't.

why I'm not using TCP and using UDP instead, as far as I know TCP only accepts one device connected, when in the boat just in case I could connect at least two at the same time if needed, the computer on board and the tablet.

at home I have no problem of connection being unidireccional because I have no data to send but I need the UDP connection because I have as test at least three computers using the same data stream, so, UDP connection is not a problem being for input only.

but on board I do need because of the afore mentioned possibility of two computers at the same time. also, the multiplexer has data filtering itself to avoid redundant connections and data priority too.

I'm trying not using then simultaneously but for testing purposes of data input, connection quality, etc. I do.

just for clearing the data stream:
data up/down via UDP to multiplexer.
the data in cuestión is received in in/out#1 as SeaTalk from autopilot.
the output data is sent via UDP to multiplexer in/out#1 converted from NMEA to SeaTalk by multiplexer and filtered in OCPN with only EC sentences to autopilot.
and filtered in the multiplexer that only accepted EC sentences from computer to in/out #1 SeaTalk to autopilot.
in/out#1 of Multiplexer is filtered for input as 2nd priority below GNSS receiver.

[nohal]

UDP is a connectionless protocol, there is not a connection between a server and a client.
What the mutliplexer or alike device does is broadcast data without caring whether someone listens for them or not, to the whole network.

In OpenCPN this scenario is usually represented by an incoming UDP connection with address 0.0.0.0 (= listen for any broadcast received on any interface)

Sending data targeting the autopilot out of OpenCPN is a different, independent, task, which should usually be an unicast (= sent to only one receiver, in your case the multiplexer).

In OpenCPN, this would be represented by an outgoing UDP connection with the multiplexer's IP address.

In OpenCPN versions up to 5.8, we took a shortcut by doing a broadcast when the connection was, strictly technically speaking, "misconfigured" to be both input and output. This of course worked and was hiding many types of common misconfigurations. At a price of making some people furious because "it was wrong". So it is not wrong anymore, you need to create two connections, one to receive the broadcasts and one to send the unicasts, and configure them right.

[Corsair-63]

Sending data targeting the autopilot out of OpenCPN is a different, independent, task, which should usually be an unicast (= sent to only one receiver, in your case the multiplexer).

In OpenCPN, this would be represented by an outgoing UDP connection with the multiplexer's IP address.

If I understand what you tell me, I have to do one connection for input and another one for output, this is not possible with the multiplexer because they uses to have one network connection active at a time, I mean if I use the UDP in one port I cannot use another connection and another port in the multiplexer.
I don´t know if will work, but not sure it does, to make a connection UDP for input and make another UDP connection for output with same port, I guess that this won't be accepted by OCPN nor O.S. neither Multiplexer neither Router.

and another question, maybe I could sacrifice the multidevice connection (UDP) and doing a TCP/IP connection but would this be bidirectional or unidirectional?

before the UDP bidirectional connection was working in my computers.

[nohal]

There is no connection with UDP, it is a connectionless protocol. It is absolutely OK and the correct thing to do to configure two UDP connections with the same port number in OpenCPN, the input one to receive the broadcasts from the multiplexer and the output one to transmit the unicast to it.

[Corsair-63]

Thanks, I'll try and revert with findings.

Sometimes only accepted one connection per peer with UDP, but I´ll try.

[rgleason]

I don't think this is a bug. Why not make two UDP connections, one in and one out.

[Corsair-63]

Done this afternoon the test on board.

I had in my computer on board the UDP connection for in/out and it was working.

but at the time I setup as only input, I couldn´t recover as input/output, but this is not the matter.

created another output UDP connection on the same port for controlling the autopilot filtering to accept only EC sentences.

activate one route and with the autopilot control of OCPN itself, looking at NMEA debug window and all the $EC sentences for output in red (rejected) and not following the track in the autopilot. of course, receiving all data from multiplexer.

made another option, input UDP for data and enable the COM port connection with autopilot (I have such connection in spare but before removed from OCPN) now setup again and it works.

Where is the fault of UDP, when before I was able to do in/out in the same connection and the autopilot control worked??

[Corsair-63]

I must remark too, that this afternoon while the test with two UDP connections, one for input and other for output in the same port, I've lost the data input while those two connections were activated. 😵‍💫

[bdbcat]

1. Confused here:
   "created another output UDP connection on the same port for controlling the autopilot filtering to accept only EC sentences."
   On the output port, you should be configured to transmit only EC. Is that what you mean?

2. "I've lost the data input while those two connections were activated."
   Lost ALL data input, or just some data? Any filters active on the input connection?

[Corsair-63]

1. Confused here:
   "created another output UDP connection on the same port for controlling the autopilot filtering to accept only EC sentences."
   On the output port, you should be configured to transmit only EC. Is that what you mean?
2. "I've lost the data input while those two connections were activated."
   Lost ALL data input, or just some data? Any filters active on the input connection?

1. I wrote up it wrongly, yes, transmit EC sentences only.
2. All data, no filter applied for input. but this happened once, I'll have to investigate further to know the source of such data missing.

[rgleason]

Corsair, you must write completely descriptive sentences otherwise your statements can be misunderstood.

[Corsair-63]

Sure, but you must understand that my mother tongue is not the Shakespeare one and could be some gap in my sentences, but I tried and will try to be as much technical as I'll can. 👌😥

[rgleason]

Well, I think you are doing a great job, anyway, and I am sorry to have made that comment. I really appreciate your digging into this. The manual will be better for it.

[Corsair-63]

I take criticism with the greatest sense of humor possible and constructive way.
(I'm getting old and wise) 🤣

[Hakansv]

For a Input connection you can use default address 0.0.0.0 or localhost or 127.0.0.1
For the output you must use a broadcast or specific address. Examples: 192.168.1.255 or 192.168.x.255
And when using the same port in and out you must use filter on both to avoid a feedback loop that will "choke" the system.

See my example where I've noted each filter as comments:

[Corsair-63]

I did right the opposite:
input with multiplexer address 192.168.1.2 port 10110, no filtering.
output 0.0.0.0 port 10110 filtering to send only EC sentences.

I'll try yours and revert with findings.

[rgleason]

Hakan, shouldn't this be in Autopilot page? Looks good.

[Hakansv]

@bdbcat
Maybe connected: When adding a new network UDP connection set to output the default address is still 0.0.0.0. That will not work and may confuse?

[Corsair-63]

I followed your instructions to do a test at home, because it doesn't matter if would be autopilot or not in first instance but to know if proper output would be as $EC signal.

• input data as UDP from GPS/AIS receiver with address 0.0.0.0 and port 10001, filtered to reject in input EC sentences.
• output data as UDP to GPS/AIS receiver with it address (192.168.0.2) and port 10001, filtered to send only EC sentences.
• activated one route and opened the NMEA debug window.

with the result of:

for the time being there are successful sentences sent.

during the test I haven't seen loss of data.

next step to check on board with same parameters and test if controlling the autopilot in real.

[Corsair-63]

I'm really missing to have one quick access to the NMEA debug window instead of going to settings - connections -... 🙄

[rgleason]

@Corsair-63 Agreed. Carmelo. We do need a shortcut key #3097
@Hakansv I put your screenshot and details under Autopilot FIXME https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:manual_basic:set_options:connections:autopilot

[Corsair-63]

From my side no problem, just let me know if I can do another screenshot of any situation I can test, and I'll try to do it.

bear in mind I'm using windows 11 mostly ARM64, at home one with w11x64 and randomly one Raspi4 with Raspbian, but not very confident with that o.s.

[Corsair-63]

Tested on board as per above message:

• input data as UDP from multiplexer with address 0.0.0.0 and port 10110, filtered to reject input EC sentences.
• output data as UDP to multiplexer with its address (192.168.1.2) and port 10110, filtered to send only EC sentences.
• these sentences are translated in the multiplexer to SeaTalk for autopilot.
• activated one route and opened the NMEA debug window.
• the autopilot in Track mode points to the waypoint.
• I´m quite some minutes with everything activated and there are no loos of input data 👌

I guess that sailing will follow it, that would be tested when I'll sail with the boat.

thanks a lot for your advises and support in the matter.

[rgleason]

Great report. Can we use the image in the manual? See the bottom https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:manual_basic:set_options:connections:autopilot

[Corsair-63]

Hi Rick, for sure you can.

[Hakansv]

192.168.1.2 can work to a specific receiver. Using 192.168.1.255 works to all on the 192.168.1 segment listening to "localhost" ( or 127.0.0.1 or 0.0.0.0)

[rgleason]

Thanks added that clarification.

[rgleason]

Can we please close this now. Thanks.

[Corsair-63]

Great support from the Team