Connection Bug??

[Corsair63]

testing ....

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, network?

[Corsair63]

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.

[bcn]

Perhaps this commit for 5.9.0:
https://github.com/OpenCPN/OpenCPN/c...f8c7631641e040


No simultaneous In/Out on an UPD port....

[Corsair63]

Originally Posted by bcn

Perhaps this commit for 5.9.0:
https://github.com/OpenCPN/OpenCPN/c...f8c7631641e040


No simultaneous In/Out on an UPD port....

Reported in GitHub too, also tested in Windows 11 (x64) with same O version and same behaviour, no way to setup in/out at the same time.

[bcn]

But this was intention of the commit. No In/Out on a UDP port at the same time.

[Corsair63]

Originally Posted by bcn

But this was intention of the commit. No In/Out on a UDP port at the same time.

And how would be performed the output communications with devices??

e.g. autopilots, etc ....

when you have only one mean of comunications like a multiplexer?

[wholybee]

Is TCP an option with this multiplexer?
This was part of trying to make the connection page less prone to errors. Sending and receiving on the same udp connection doesn't work on the gateways I've tested. Actisense even states that in the manual. The ip changes to 0.0.0.0 on receive because it doesn't matter. It will receive UDP data from any IP sending to that port. The IP field only matters as a destination for output.

That could be reverted back if there is some case where it actually works. But i would otherwise recommend TCP for an autopilot.

Does your multiplexer work with UDP in/out on the same connection in 5.8.4? Which is it?

[bcn]

UDP In/Out does work for me with OpenCPN as multiplexer.
192.168.n.255:10110 where "n" is the private subnet.


Does receive AIS targets from a different remote subnet via a VPN, input from a local AIS receiver (N0183, serial), and outputs for the local net. No loop.

[Corsair63]

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.

[wholybee]

So this was my mistake thinking that it could never work. I have submitted a pull request to undo that change.

[bcn]

Perhaps putting a warning in place when selecting that setting? I remember cases of "flooding" reported in the past here. Indeed one has to think twice when using that option.

[Corsair63]

Warren & BCN thanks a lot,

of course, that for us as user we must be careful about the data stream arriving and departing from computer/devices, filtering and minimizing the flooding of data the multiplexer and the navigation software (in this case OCPN).

FTB I'll test to make an UDP connection for input and another one for output with the same port as per Nohal advise and I'll revert with findings, tomorrow that I'll have to do some jobs on board.

[rgleason]

I think it will work with separate UDP in and UDP out.

[Corsair63]

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 input only, 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??

[wholybee]

As I mentioned, the change has been reverted so that both input and output will be available again. However it still needs to be merged into the master branch, and that may take some time.