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

[Franziska]

Thanks network gurus.


From the viewpoint of a normal user (myself) the above is super complicated and daunting. No chance I could have followed all this.

Instructions would really need to be dummy proof and step by step a Rick has written.



Don't try to teach the USER network knowledge in the manual. Just keep it as stupid simple as possible.



Not criticising the experts just making aware of normal USER needs.



Very grateful for BeFree's assistance. Glad it is working now here.

[wholybee]

Originally Posted by 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.

https://opencpn.org/wiki/dokuwiki/do..._and_multicast

It isn't so much that it isn't clear, but it's buried in an advanced section, amongst more confusing multicast information, with no pictures. It's easy for a beginner to miss that or get lost. I am willing to bet that most users don't know what broadcast or multicast mean or even look down there.

Adding the screenshots that myself or Franziska posted in this thread somewhere not in the advanced section is probably all you need. Maybe several screenshots, showing TCP/IP, UDP unicast, and UDP broadcast examples. UDP multicast could be forgotten or kept in the advanced section. Anyone wanting or needed that probably has the background to not need the manual anyway.

[Be Free]

Originally Posted by Franziska

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.

I'm really glad that the problem is resolved. I could not have done it without Warren (Wholybee) pointing out the correct value from his settings.

[Franziska]

Thanks Wholybee too!!!!

[s/v Jedi]

Originally Posted by Franziska

Thanks network gurus.

From the viewpoint of a normal user (myself) the above is super complicated and daunting. No chance I could have followed all this.

Instructions would really need to be dummy proof and step by step a Rick has written.

Don't try to teach the USER network knowledge in the manual. Just keep it as stupid simple as possible.

Not criticising the experts just making aware of normal USER needs.

Very grateful for BeFree's assistance. Glad it is working now here.

It’s virtually impossible because the instructions are different for each brand/type of router used. Maybe someone could write instructions for a specific, popular router so people can buy it and copy the setup. Unfortunately the gear I use isn’t suitable for configuration at novice level at all.

[rgleason]

Well thank you for your responses and in particular SteveAD.
Now I am left with several questions.

In the Broadcast and Multcast section
What screenshots from this thread would you put where? Or even just provide a link to the post and say what would apply.

Isn't Broadcast the same as UDP? so then is Multicast TCP (one to one?)?
We cannot put all this in the main page, it is overwhelming to new users.

In the main Connections page we have Protocol Choices: TCP, UDP or GPSD
which covers it nicely. What kind of a screenshot are you suggesting? Examples using the 5.9 new interface will be accepted willingly, here as uploads.

Now we have to deal with my lousy summary of what happened.
Steve has provided an excellent overview, with additional wisdom provided by others.
This is a good detailed intro "Networking for Dummies", and put it in the "Advanced" section? What an oxymoron.

What should we do about this case? Whittle it down to the essence and use it as an example? (Just one configuration, of several possible ones.)?

...And what should we do about the poor Newby User who is challenged at every small step?
Well, after burning out routers every 5 to 7 years, I've found Asus routers have great software and easy installation, so I know it can be done.

Would some Diagrams of typical situations be helpful?
1. Opencpn computer wifi + wifi router connected to n0183/n2000 or Vesper wifi + radar Ethernet hardwired to wifi router.
2. Opencpn computer wifi + wifi router connected to n0183/n2000 or Vesper wifi + radar Ethernet direct to Opencpn computer.
3. Opencpn computer ethernet to router + router connected to n0183/n2000 or Vesper wifi + radar ethernet direct to router.
4. any others?

Then just list the typical connections for each setup with a brief explanation of what is being done?

[Be Free]

Rick,
I was pretty sure you would chime in at some point if I mentioned a problem with the manual.

I'll be glad to help but I'm at a bit of a disadvantage since I'm not sure what the original writers were trying to say.

If you want to move this part of the discussion to another thread it might be appropriate. It's going to get a little technical.

This is the section I was working from:

UDP

A method of transmitting data as simple “datagrams” without negotiating a connection between two endpoints. It involves no detection and retransmission of data lost in the network. Within a small home/boat network such data loss should not normally occur and in any case, NMEA data is generally updated by “talkers” on a regular basis. Unlike TCP which involves a connection between two endpoints, UDP data may be received by many “listeners”.

• For UDP input no IP is required. Try just going with the port. 0.0.0.0 :1456
• For UDP NMEA senders if you make the last octet of the IP address 255 then messages should go to all devices on that subnet. In OpenCPN the address should be 0.0.0.0 (don’t care) and the port number must match the sending port number. Also, any router in between the sender and O must be configured to not block the assigned port number. Sometimes a really high port number (like 10110) will not be blocked.

I think that the main confusion was that the section lumped together instructions for the UDP sender with the instructions for the corresponding receiver if it happened to be on OpenCPN. I was able to filter through the obviously extraneous information but the remaining instructions were confusing. In hindsight, knowing the right answer, I can see that the instructions were correct, but they were ambiguous.

Assuming I'm somewhat correct in my understanding, I'd recommend something more like this:
Items in italics are my notes. They are not part of the manual entry.

UDP

A method of transmitting data without negotiating a connection between two endpoints. UDP data may be received by many “listeners” simultaneously.

Even this is probably more information than the average users will be interested in. The main point is that TCP is primarily a unicast packet and UDP is better suited for multicast (broadcast) uses.

• If you select Receive Input on this Port then the connection will listen for another device on the network. This is the default UDP connection setting.
• For UDP input no IP is required. The default Address entry of 0.0.0.0 will usually be correct. You will need to enter the DataPort that is used by the sender.

Please verify that this is the case. There is a difference between "no IP is required" and "the address field is ignored". Is the Address field used for a UDP input connection?

Note: Address is capitalized because that is the name of the field on the Connection window. Likewise DataPort is the UDP port number on the same window. Being consistent in this manner will help new users navigate these unfamiliar waters.

• If you uncheck Receive Input on this Port then you are setting up a UDP output connection.
• If you want to send data to a particular device then enter the IP address of the device in the Address field along with the DataPort you want the receiver to listen on.
• If you do not know which device(s) will be listening you can make the data available to all of the devices on your network simultaneously. To do this enter the first three parts of your IP address followed by 255. For example, if the IP address of your computer is 192.168.0.33 then you would enter 192.168.0.255. As before, you will also enter DataPort you want the receiver to listen on.

If unicast transmission is not possible you can eliminate the second point and slightly reword the third point.

I did not explain how to find out what the computer's IP address is because I feel that would be better explained in another section.

I'm only giving an example for a class C network because that is the one that most consumer grade routers will use. If anyone is using a more complex addressing scheme then they probably already know how to find the broadcast address for their network.

I've also removed all of the oblique references to routing and firewall problems. Those would also be better addressed in a dedicated entry.

I did not want to get too deep into the formatting but having a subsection for UDP input, UDP output, and UDP in NEMA repeater mode would probably help.

Also, the screenshots in the manual are from multiple releases and don't always match the accompanying text (but you already knew that).

[rgleason]

Please see this new Thread
https://www.cruisersforum.com/forums...ml#post3885496


Bill, you devil. I could not resist trying to get into this as we are working on this page of the manual right now.


UDP (User Data Protocol) is capable of Broadcast. --They are not the same.
UDP is a connectionless protocol, which sends messages without a handshake connection first. So it is suitable for broadcast to multiple devices at once. Data transmission is a simple transaction oriented protocol suitable for prompt delivery, does not quarantee delivery, preseves packets, and protects from duplicates, which means it is faster and less reliable than TCP.

[Be Free]

Originally Posted by rgleason

Well thank you for your responses and in particular SteveAD.
Now I am left with several questions.

In the Broadcast and Multcast section
What screenshots from this thread would you put where? Or even just provide a link to the post and say what would apply.

Isn't Broadcast the same as UDP? so then is Multicast TCP (one to one?)?
We cannot put all this in the main page, it is overwhelming to new users.

In the main Connections page we have Protocol Choices: TCP, UDP or GPSD
which covers it nicely. What kind of a screenshot are you suggesting? Examples using the 5.9 new interface will be accepted willingly, here as uploads.

Now we have to deal with my lousy summary of what happened.
Steve has provided an excellent overview, with additional wisdom provided by others.
This is a good detailed intro "Networking for Dummies", and put it in the "Advanced" section? What an oxymoron.

What should we do about this case? Whittle it down to the essence and use it as an example? (Just one configuration, of several possible ones.)?

...And what should we do about the poor Newby User who is challenged at every small step?
Well, after burning out routers every 5 to 7 years, I've found Asus routers have great software and easy installation, so I know it can be done.

Rick,
Most of the screenshots I used were related to the specific problem of Windows disabling a WIFI connection when a wired connection is activated. That is probably best addressed in another part of the manual. It's a problem that will come up again.

Broadcast and UDP are very different.

UDP is simply a "connectionless" method where data is put on the wire without out knowing or caring what happens to it. This is in contrast to TCP where every connection is negotiated and checked for errors all along the way.

Briefly: In both TCP and UDP you can have a unicast, multicast, or broadcast message. Unicast messages are directed to a specific recipient. Multicast messages are directed to a specific group of recipients. Broadcast messages are directed to an entire network (or subnet). That is an extremely simplified explanation.

I agree that we don't need to make the manual a networking primer. A brief introduction along with a high level explanation of when to use each type of connection is all that is needed for the average user. The section we are looking at is unnecessarily complicated for the average user and confusing to the professional.

GPSD is not technically a protocol like TCP or UDP. It is a program (Global Positioning System Daemon). It (like the NMEA UDP repeater) is a specific tool that will our users will commonly use. GPSD is just TCP on port 2947 with some very useful information in it. The fact that the manual lumps it in as a "Protocol Choice" is inaccurate.

If I were starting from scratch on the manual I'd be looking at a couple of targets. The manuals need to be useful, usable, and maintainable.

Useful is the easiest. That's what we have now. Almost everything that anyone would want is in the manual (somewhere) and in some form.

Usable is a little harder. That takes consistency, care, and above all a ruthless willingness to trim the fat. Layout, formatting, and typography need to be consistent. Writers and editors must be careful to remove jargon, spelling errors, and English specific phrasing. Keep those non-native speakers in mind. Finally, everything has to stay on topic. Every word, every idea, every image has to support the goal of the current manual and the current topic in the manual. If it's not on topic it needs to go somewhere else (or maybe just go).

Maintainable is the hardest. Writing a manual is hard. Keeping it updated is often harder. Unless a concerted effort is made to keep the documentation in line with the current state of the program the documentation will quickly fall behind and just as quickly become useless (or even worse, harmful). If there were some way to tie the source code to the documentation so that when a feature is added or significantly changed that a corresponding commit would update the documentation or at least raise an issue that a change in documentation is needed that may decrease the gap between the new code and the outdated documentation.

Personally, I may be open to helping clean up or even rewrite the manual(s) but only once. If there is not a way to keep the documentation creep from coming back I'm not sure I want to put the effort into cleaning up the existing problem.

Now, regarding manuals...

First, I would say we need a basic, stripped down, install it and get it working manual. This would go along with a basic, stripped down, install it and get it working configuration of OpenCPN. The goal is to have a learning environment where the user can be introduced to the interface and the more common features. This is a sandbox that can easily be reset to a known configuration if something goes wrong. Maybe a small set of charts and a GPS feed that can move a boat around on it.

Next would be a beginner's guide. That would take the previous install and add the goal that the user be able to use OpenCPN to read a chart, plan a trip, and follow a route. Think weekend coastal sailor with very limited navigation or planning needs.

Intermediate guide introduces the idea of chart groups, GRIBS, AIS, some of the simpler plugins. The goal is for the user to be able to use OpenCPN in a more complex external environment and to begin integrate some of the other devices on the boat. This user is out for maybe a week or so at a time but still not full-time or going more than a few hundred miles per trip.

Advance guide introduces the more complex plugins. I'm defining "complex" as niche use, poor documentation, or hard to implement. These are the things that would be more appropriate to a full-time or long distance sailor. The hobbyist, tinkerer, and envelope-pushers might also need things in here.

As many stand-alone manuals as needed. Obviously plugin manuals go here. This is also where you would put all of the tutorial, training, and all of that obscure background information that we all love to include in our posts. Rick, you could even copy whole threads and post them here if they were useful.

This is all just off the top of my head. Comments and constructive criticism welcome.

[Be Free]

Originally Posted by rgleason

Please see this new Thread
https://www.cruisersforum.com/forums...ml#post3885496


Bill, you devil. I could not resist trying to get into this as we are working on this page of the manual right now.


UDP (User Data Protocol) is capable of Broadcast. --They are not the same.
UDP is a connectionless protocol, which sends messages without a handshake connection first. So it is suitable for broadcast to multiple devices at once. Data transmission is a simple transaction oriented protocol suitable for prompt delivery, does not quarantee delivery, preseves packets, and protects from duplicates, which means it is faster and less reliable than TCP.

Rick,
I'll follow the link a little later. I just finished a very long post to the last thread (where I just saw this). My wife just wandered through (honey-do list in hand) and said, "Are you still talking to your sailing buddies?"


We're celebrating 45 years of marriage in a couple of months. I want to make it to at least 46. Be back later.

Bill

[rgleason]

@Be Free Bill your thoughts with mine in between.
I agree with much of what you say, and we need a much better manual(s)

1. We've moved Plugin documentation to github using ascii/doc. That helped a lot but distanced those manuals from user editing.
2. We've tried to split the manual into "User Manual Basic" and "User Manual Advanced"
3. I've recently been working on the first page of "User Manual Basic" to create "Quickstart" for the new user. It uses "Basic" but some pages are different.

Most of the screenshots I used were related to the specific problem of Windows disabling a WIFI connection when a wired connection is activated. That is probably best addressed in another part of the manual. It's a problem that will come up again.

I'll find them and try to get them in place.

Broadcast and UDP are very different.

UDP is simply a "connectionless" method where data is put on the wire without out knowing or caring what happens to it. This is in contrast to TCP where every connection is negotiated and checked for errors all along the way.

Yes

Briefly: In both TCP and UDP you can have a unicast, multicast, or broadcast message. Unicast messages are directed to a specific recipient. Multicast messages are directed to a specific group of recipients. Broadcast messages are directed to an entire network (or subnet). That is an extremely simplified explanation.

Maybe we can clarify this somewhere appropriate.

I agree that we don't need to make the manual a networking primer. A brief introduction along with a high level explanation of when to use each type of connection is all that is needed for the average user. The section we are looking at is unnecessarily complicated for the average user and confusing to the professional.

Agreed

GPSD is not technically a protocol like TCP or UDP. It is a program (Global Positioning System Daemon). It (like the NMEA UDP repeater) is a specific tool that will our users will commonly use. GPSD is just TCP on port 2947 with some very useful information in it. The fact that the manual lumps it in as a "Protocol Choice" is inaccurate.

Maybe we could move it to the right place?

If I were starting from scratch on the manual I'd be looking at a couple of targets. The manuals need to be useful, usable, and maintainable.

Useful is the easiest. That's what we have now. Almost everything that anyone would want is in the manual (somewhere) and in some form.

Usable is a little harder. That takes consistency, care, and above all a ruthless willingness to trim the fat. Layout, formatting, and typography need to be consistent. Writers and editors must be careful to remove jargon, spelling errors, and English specific phrasing. Keep those non-native speakers in mind. Finally, everything has to stay on topic. Every word, every idea, every image has to support the goal of the current manual and the current topic in the manual. If it's not on topic it needs to go somewhere else (or maybe just go).

Maintainable is the hardest. Writing a manual is hard. Keeping it updated is often harder. Unless a concerted effort is made to keep the documentation in line with the current state of the program the documentation will quickly fall behind and just as quickly become useless (or even worse, harmful). If there were some way to tie the source code to the documentation so that when a feature is added or significantly changed that a corresponding commit would update the documentation or at least raise an issue that a change in documentation is needed that may decrease the gap between the new code and the outdated documentation.

Personally, I may be open to helping clean up or even rewrite the manual(s) but only once. If there is not a way to keep the documentation creep from coming back I'm not sure I want to put the effort into cleaning up the existing problem.

Now, regarding manuals...

First, I would say we need a basic, stripped down, install it and get it working manual. This would go along with a basic, stripped down, install it and get it working configuration of OpenCPN. The goal is to have a learning environment where the user can be introduced to the interface and the more common features. This is a sandbox that can easily be reset to a known configuration if something goes wrong. Maybe a small set of charts and a GPS feed that can move a boat around on it.

Agreed. Works "out of the box" so to speak, if possible. QuickStart, but GPS is a hangup and sample charts could be improved.

Next would be a beginner's guide. That would take the previous install and add the goal that the user be able to use OpenCPN to read a chart, plan a trip, and follow a route. Think weekend coastal sailor with very limited navigation or planning needs.

I can agree with this. It does change the basic thing we have been doing which is following the menu structure of the program.

Intermediate guide introduces the idea of chart groups, GRIBS, AIS, some of the simpler plugins. The goal is for the user to be able to use OpenCPN in a more complex external environment and to begin integrate some of the other devices on the boat. This user is out for maybe a week or so at a time but still not full-time or going more than a few hundred miles per trip.

Yes

Advance guide introduces the more complex plugins. I'm defining "complex" as niche use, poor documentation, or hard to implement. These are the things that would be more appropriate to a full-time or long distance sailor. The hobbyist, tinkerer, and envelope-pushers might also need things in here.

User Manual Advanced

As many stand-alone manuals as needed. Obviously plugin manuals go here. This is also where you would put all of the tutorial, training, and all of that obscure background information that we all love to include in our posts. Rick, you could even copy whole threads and post them here if they were useful.

Plugins
Development


This is all just off the top of my head. Comments and constructive criticism welcome.


This is all supposed to be Fun, in your own time frame!!!

[stevead]

From the viewpoint of a normal user (myself) the above is super complicated and daunting. No chance I could have followed all this.

This should not be hard, as other than entering an IP address (which can be copy-n-pasted from elsewhere), it is little different to setting up a home network and connecting your phone, tablet or Smart TV. That being said, the manual could be simplified.

Given that most boat networks are small and simple, and that marine data is sent frequently, most OpenCPN users don't need to know the difference between TCP and UDP, unicast, multicast or broadcast and that in most cases UDP provides sufficient reliability together with easier configuration.

Rick, I'm happy to write the simplified network connections section similar to what I wrote for the SignalK. If users can send some screenshots of the following, that would be most helpful.

Setup page that shows the network configuration for Actisense, Yacht Devices, ShipModul gateways and Vesper, Yacht Devices, Quark or other AIS transceivers that incorporate a WiFi Access Point.

[rgleason]

Steve and Bill,


I really appreciate your help!!! I've edited and updated the screenshots in
Connections
Advanced

There is still a lot of editing and we need to reduce unnecessary text and whittle these documents so they are focused, as Bill suggests.

Bill poses some questions and has some topics that should be treated elsewhere.

Steve, I think that comment was from Francizka and is probably right.

I like your idea of a "New User" "Simple Network Connections" page just to handle a very simple network. I understand you need some screenshots of devices that incorporate a wifi Access Point.

• Actisense,
• Yacht Devices,
• ShipModul gateways
• Vesper,
• Yacht Devices,
• Quark
• other AIS transceivers

I will make a new page "Wifi Networks" (if that is ok) for that and let you know where it is. This is wise as it is the direction boaters should be headed.

If you guys could take a look at the GNSS Setup page
to see if it can be improved and simplified, I would really appreciated it.

Also we have a connections thread we should probably be using now O5.9 Connections

[wholybee]

Drawing from my experience with UDP unicast, multicast, and broadcast with other products, maybe there could be an UI change on the connections dialog that will prevent common errors. The following is commonly used with professional video equipment I have used.

What I have seen before:
A radio button to select between Unicast, Multicast, and Broadcast. There is a brief definition of each (transmit to one device, several devices, or the whole network). The UI will then change to reflect different options, while the networking code is unchanged.

If the receive button is checked:

If the Unicast button is selected:

IP address field is removed, 0.0.0.0 default is assumed.

If the Multicast button is selected:

IP address is populated with a sensible default, such as 224.0.0.78 (78 is just a number I made up, we can choose anything for the 4th octet as our default)
A note is displayed to explain that the multicast address is NOT the IP address of the other machine, and it can be left as default unless the user is advanced and knows why it is being changed. (conflicts with some other multicast device-highly unlikely on a boat.)

If the broadcast button is displayed:

IP address is hidden, and a default value of 0.0.0.0 is used.

If the transmit button is selected:

If the unicast button is selected:

IP address field is available, and blank. A note states it should be the IP address of the receiving device.

If the multicast button is selected:

IP address is populated with a sensible default, such as 224.0.0.78 (78 is just a number I made up, we can choose anything here as our default)
A note is displayed to explain that the multicast address is NOT the IP address of the other machine, and it can be left as default unless the user is advanced and knows why it is being changed. (conflicts with some other multicast device-highly unlikely on a boat.)

If broadcast is selected:

The IP address is populated with the correct value, by querying the OS for the machines IP address and netmask. A note will state that this value is probably correct, but might need adjusted for advanced configurations with multiple network interfaces.

Selecting both transmit and receive on UDP should be prohibited, and TCP should be advised. While I believe it is technically possible, it introduces complications, what happens when multiple devices are transmitting on the same broadcast or multicast? Maybe it could be allowed with UDP/Unicast, but mostly I think that for bidirectional communication TCP should be preferred. Maybe an "I know what I am doing" checkbox to allow it.

Also, FWIW, previously I have been unable to get Multicast to work at all with OCPN. It might have been an error in my setup at the time, since I easily got broadcast to work I didn't pursue it further. But, someone should confirm that it actually works if it is going to be documented.

[rgleason]

Warren, I added your comment to the ongoing discussion on github. If you have a free github account (available for opensource) then you could participate in that discussion.


https://github.com/OpenCPN/OpenCPN/i...ent-2028821801