Feature Requests

[goboatingnow]

He’s running a server based system and accessing it by web browsers over a ship board wifi system

[Franziska]

Originally Posted by goboatingnow

He’s running a server based system and accessing it by web browsers over a ship board wifi system

Thanks. Much easier to understand.

Does that mean you can call up and interact with a single OpenCPN installation from any web browser capable device if this is implemented ?

[sparticle]

Originally Posted by Franziska

Actually most people here are not electronic engineers or computer specialists and it is all but clear to us dummies.
Wingsail, and myself are puzzled as are many others likely too.

So if you have a great understanding of it, maybe you can explain the posts meaning in few short simple layman terms, so we can also understand the general drift of its meaning without the need to dive deep into the subject.

Thank you.

To all interested.

I am also not an electronics engineer, however I have been in IT for almost 30 years and been building low power marine computers for years. Sometimes we forget the breadth of reach these type of forums have and write in short form, for that I apologise.

We have been using OpenCPN for as long as we can remember. Using RPI's for almost 10 years and Ubuntu for longer than that.

In recent years with the advent of the RPI4 and other very capable and powerful very low cost and very low power SBC (Single Board Computers) using the ARM chip platform. This coupled with the free and Open Source mainstream Operating Systems for these platforms like Ubuntu LTS (Long Term Service) operating systems that run perfectly on these devices. We can have a low cost fully capable desktop system onboard. I am a FOSS advocate and contribute ideas and money to various opensource projects. OpenCPN is one of them.

Currently thanks to the amazing work of the team of developers (I am not a modern day developer) all of my hacking was in the 80's and early 90's on mainframes and client server systems in esoteric languages like Cobol, Fortran and Pascal and BCPL.

Back to the present day. We have and currently run OpenCPN on multiple yachts. We have been limited in our ability to proliferate OpenCPN across the yacht. Chart Table, Helm Station, Saloon etc. We have gone through various iterations using various remote desktop protocols like VNC. None have been a great experience.

The challenge is that OpenCPN is an applicaiton that expects local resources, screen, Keyboard, Mouse. Yes you can run it on a tablet, the paid for Android application is less than perfect, but the central issue is there is no concept of master and slave versions. So for instance the master OpenCPN application running at the chart table on our RPI4 4GB Ubuntu desktop is the primary for all navigation. If we want say a tablet at the Helm station to see exactly what is on the Nav Station OpenCPN then we can use Remote Desktop Sharing. Slow and clunky at the best of times.

Or, we can copy some OpenCPN application files from the nav station computer to the helm station computer and the helm station computer will now have the same route we have at the chart table with the same objects. We can use the power of OpenCPN to send all the navigation NMEA data to the Helm computer using a network by configuring a network out port on the Nav station OpenCPN and sending out all the NMEA data. This is clunky and easy to get wrong and has to be repeated every time we might make a route change.

Onboard our Yacht a Beneteau Oceanis 411 Celebration we have an onboard wired and wifi network. There is a small network POE switch that powers the external QUSpot that houses a Teltonika RUTX11 4G Router this provides a local 2.4 and 5Ghz Wifi Network connection. We have full time Internet whenever we are in range of a provider network like 3 etc. When not connected to the internet the LAN functions like any other LAN. Connected to the switch are the RUTX11 the Nav Station RPI4, Another custom RPI4 that we call a PINAS and as its name suggests it is a NAS server for the boat. It has 4TB of SSD storage that has all of our digital life, it is a repository for the security cameras and pictures we take. It has all of our music (150GB we digitised all of our CD collections years ago) movies, TV Shows, Documentation for all on board devices, manuals etc. etc.etc. It runs an EMBY server and shares various folders it all serves the onboard TV's which all have Amazon Fire TV sticks via a media application called EMBY. Worth saying all devices on board are 12V, the TV's are natively 12V the PINAS also and the 5V Rpi's and Amazon Fire TV's are powered by regulated 12V to 5V adaptors.

Then we have the AVNAV Server RPI4 also connected to the switch wired in a totally headless (No Monitor, Keyboard, Mouse) configuration it was previously connected via WIFI. This provides a full navigation service and is currently connected via USB ports to the onboard marine devices. It receives GPS and AIS data via a Digital Yacht AIT5000 dedicated AIS Transponder. It also receives Boat Data via a Digital Yacht USB to NMEA interface that is connected to a Raymarine E85001 Seatalk 1 to NMEA bridge. It also has a Digital Yacht USB to Seatalk 1 adaptor also connected to the Seatalk 1 network.

It uses the USB to NMEA adaptor to send out Autopilot and other GPS information to the Seatalk 1 network as we now use the DY AIT5K as the primary GPS data source and have gotten rid of the very old Raystar GPS device.

This headless AVNAV server is able to operate as a charplotter. Displaying full chart information and AIS targets in realtime. We use o-charts officially derived ENC charts for our charting. These are inexpensive being a few tens of pounds per chart area. We access the chartplotter using a simple Chrome browser from a variety of devices, the Nav Station Computer, the Helm Station Android Tablet via Wifi, mobile phones. We can even access it via the TV's.

This device also provides a data feed onto the network of all of the navigation data that can easily be consumed by another application. Like for instance Navionics boating application.

The benefit of this type of approach is that there is always only one source of the truth. All devices accessing the AVNAV navigation service are seeing the same route and navigation information. It is not screen sharing. It is a navigation service being rendered in the client browser that is accessing it. A collaboration with the very gifted developer of AVNAV (https://www.wellenvogel.net/software...g.html?lang=en) would seem to me to be a very valuable thing for the future of OpenCPN and the dedicated OpenCPN users out there.

I have suggested to the gods of OpenCPN that this is the future of OpenCPN and if OpenCPN were to adopt this type of Client Server approach and bring all the richness of the OpenCPN ecosystem it would be a truly future-proofed way to go and an awesome evolution. It is the direction almost all the manufacturers are going. Except their devices are proprietary and cost many thousands of pounds and are limited to the functionality they choose to release.

So that is what we do, we have gotten to this position after many many years and countless iterations of devices and operating system variants.

Every device connected to the AVNAV server can be a navigation station. As a skipper I can see what's going on from my bunk easily. The navigator can work from the large screen at the nav station, the helmsman can see all the relevant navigation data and instrumentation all with the confidence nothing is out of sync and the latest course corrections are showing in realtime.

Happy to provide more detail on the specific stuff we use if of interest. I hope this inspires others and helps in the understanding of what is possible.

Please forgive any typos or grammar.

Cheers
Spart

[Franziska]

Originally Posted by sparticle

To all interested.



I am also not an electronics engineer, however I have been in IT for almost 30 years and been building low power marine computers for years. Sometimes we forget the breadth of reach these type of forums have and write in short form, for that I apologise.



We have been using OpenCPN for as long as we can remember. Using RPI's for almost 10 years and Ubuntu for longer than that.



In recent years with the advent of the RPI4 and other very capable and powerful very low cost and very low power SBC (Single Board Computers) using the ARM chip platform. This coupled with the free and Open Source mainstream Operating Systems for these platforms like Ubuntu LTS (Long Term Service) operating systems that run perfectly on these devices. We can have a low cost fully capable desktop system onboard. I am a FOSS advocate and contribute ideas and money to various opensource projects. OpenCPN is one of them.



Currently thanks to the amazing work of the team of developers (I am not a modern day developer) all of my hacking was in the 80's and early 90's on mainframes and client server systems in esoteric languages like Cobol, Fortran and Pascal and BCPL.



Back to the present day. We have and currently run OpenCPN on multiple yachts. We have been limited in our ability to proliferate OpenCPN across the yacht. Chart Table, Helm Station, Saloon etc. We have gone through various iterations using various remote desktop protocols like VNC. None have been a great experience.



The challenge is that OpenCPN is an applicaiton that expects local resources, screen, Keyboard, Mouse. Yes you can run it on a tablet, the paid for Android application is less than perfect, but the central issue is there is no concept of master and slave versions. So for instance the master OpenCPN application running at the chart table on our RPI4 4GB Ubuntu desktop is the primary for all navigation. If we want say a tablet at the Helm station to see exactly what is on the Nav Station OpenCPN then we can use Remote Desktop Sharing. Slow and clunky at the best of times.



Or, we can copy some OpenCPN application files from the nav station computer to the helm station computer and the helm station computer will now have the same route we have at the chart table with the same objects. We can use the power of OpenCPN to send all the navigation NMEA data to the Helm computer using a network by configuring a network out port on the Nav station OpenCPN and sending out all the NMEA data. This is clunky and easy to get wrong and has to be repeated every time we might make a route change.



Onboard our Yacht a Beneteau Oceanis 411 Celebration we have an onboard wired and wifi network. There is a small network POE switch that powers the external QUSpot that houses a Teltonika RUTX11 4G Router this provides a local 2.4 and 5Ghz Wifi Network connection. We have full time Internet whenever we are in range of a provider network like 3 etc. When not connected to the internet the LAN functions like any other LAN. Connected to the switch are the RUTX11 the Nav Station RPI4, Another custom RPI4 that we call a PINAS and as its name suggests it is a NAS server for the boat. It has 4TB of SSD storage that has all of our digital life, it is a repository for the security cameras and pictures we take. It has all of our music (150GB we digitised all of our CD collections years ago) movies, TV Shows, Documentation for all on board devices, manuals etc. etc.etc. It runs an EMBY server and shares various folders it all serves the onboard TV's which all have Amazon Fire TV sticks via a media application called EMBY. Worth saying all devices on board are 12V, the TV's are natively 12V the PINAS also and the 5V Rpi's and Amazon Fire TV's are powered by regulated 12V to 5V adaptors.



Then we have the AVNAV Server RPI4 also connected to the switch wired in a totally headless (No Monitor, Keyboard, Mouse) configuration it was previously connected via WIFI. This provides a full navigation service and is currently connected via USB ports to the onboard marine devices. It receives GPS and AIS data via a Digital Yacht AIT5000 dedicated AIS Transponder. It also receives Boat Data via a Digital Yacht USB to NMEA interface that is connected to a Raymarine E85001 Seatalk 1 to NMEA bridge. It also has a Digital Yacht USB to Seatalk 1 adaptor also connected to the Seatalk 1 network.



It uses the USB to NMEA adaptor to send out Autopilot and other GPS information to the Seatalk 1 network as we now use the DY AIT5K as the primary GPS data source and have gotten rid of the very old Raystar GPS device.



This headless AVNAV server is able to operate as a charplotter. Displaying full chart information and AIS targets in realtime. We use o-charts officially derived ENC charts for our charting. These are inexpensive being a few tens of pounds per chart area. We access the chartplotter using a simple Chrome browser from a variety of devices, the Nav Station Computer, the Helm Station Android Tablet via Wifi, mobile phones. We can even access it via the TV's.



This device also provides a data feed onto the network of all of the navigation data that can easily be consumed by another application. Like for instance Navionics boating application.



The benefit of this type of approach is that there is always only one source of the truth. All devices accessing the AVNAV navigation service are seeing the same route and navigation information. It is not screen sharing. It is a navigation service being rendered in the client browser that is accessing it. A collaboration with the very gifted developer of AVNAV (https://www.wellenvogel.net/software...g.html?lang=en) would seem to me to be a very valuable thing for the future of OpenCPN and the dedicated OpenCPN users out there.



I have suggested to the gods of OpenCPN that this is the future of OpenCPN and if OpenCPN were to adopt this type of Client Server approach and bring all the richness of the OpenCPN ecosystem it would be a truly future-proofed way to go and an awesome evolution. It is the direction almost all the manufacturers are going. Except their devices are proprietary and cost many thousands of pounds and are limited to the functionality they choose to release.



So that is what we do, we have gotten to this position after many many years and countless iterations of devices and operating system variants.



Every device connected to the AVNAV server can be a navigation station. As a skipper I can see what's going on from my bunk easily. The navigator can work from the large screen at the nav station, the helmsman can see all the relevant navigation data and instrumentation all with the confidence nothing is out of sync and the latest course corrections are showing in realtime.



Happy to provide more detail on the specific stuff we use if of interest. I hope this inspires others and helps in the understanding of what is possible.



Please forgive any typos or grammar.



Cheers

Spart

Spart. Thanks for the expansive post.
Maybe I did not understand everything.

What happens if two or more people move way points around or create routes at the same time on their various interfaces linked to the same server?
Who has preference? Or is there a kind of login which only the captain has to prevent the others from messing it up?

[goboatingnow]

Originally Posted by Franziska

Thanks. Much easier to understand.

Does that mean you can call up and interact with a single OpenCPN installation from any web browser capable device if this is implemented ?

Yes correct

[wingssail]

Originally Posted by sparticle

...I have suggested ... that this is the future of OpenCPN and if OpenCPN were to adopt this type of Client Server approach and bring all the richness of the OpenCPN ecosystem it would be a truly future-proofed way to go and an awesome evolution. It is the direction almost all the manufacturers are going. Except their devices are proprietary and cost many thousands of pounds and are limited to the functionality they choose to release.

So that is what we do, we have gotten to this position after many many years and countless iterations of devices and operating system variants.

Every device connected to the AVNAV server can be a navigation station. As a skipper I can see what's going on from my bunk easily. The navigator can work from the large screen at the nav station, the helmsman can see all the relevant navigation data and instrumentation all with the confidence nothing is out of sync and the latest course corrections are showing in realtime.

Happy to provide more detail on the specific stuff we use if of interest. I hope this inspires others and helps in the understanding of what is possible.

Please forgive any typos or grammar.

Cheers
Spart

Thank you for the details and the link to Wellenvogel-AvNav. I like this approach and while I would prefer a simple version such as shown in the Wellenvogel web page running on my single WinPC as the server rather than multiple RPI etc etc I think this approach would be excellent to have onboard my boat and would be the biggest step into the future for O since it was first released. It would solve several issues for us (access on deck being the big one). goboatingnow, please don't answer this.

[goboatingnow]

Originally Posted by wingssail

Thank you for the details and the link to Wellenvogel-AvNav. I like this approach and while I would prefer a simple version such as shown in the Wellenvogel web page running on my single WinPC as the server rather than multiple RPI etc etc I think this approach would be excellent to have onboard my boat and would be the biggest step into the future for O since it was first released. It would solve several issues for us (access on deck being the big one). goboatingnow, please don't answer this.

Why not.

[sparticle]

Originally Posted by Franziska

Spart. Thanks for the expansive post.
Maybe I did not understand everything.

What happens if two or more people move way points around or create routes at the same time on their various interfaces linked to the same server?
Who has preference? Or is there a kind of login which only the captain has to prevent the others from messing it up?

You can create as many routes as you like there is only one active route. So you could copy the current route edit it and save it as a new route then load it and activate it as the new route.

I am sure there is more planned for AVNAV, our onboard network is as secure as we can make it and only people with training would be editing routes etc. For the rest just viewing is interesting. There are also fully customisable instrument panels that can also be displayed by any device. Including having your own preference of displays on your client. A default are provided to get you started.

Like I said it is not perfect but the immediate benefit of fully cross platform access from a browser is an awesome step forward.

With the dev capabilities of the OpenCPN devs and the fully working AVNAV solution, a collaboration would be amazing. I can see a future where all of the plugins for OpenCPN would be available rendered via browser. No more remote access and navigation object copying challenges across the network.

A server based approach would solve a lot of problems. BTWit already has N2K and full Signal K integration. We can see all of our boat data in Signal K.

I have included screeshots of the AVNAV display from the RPI4 Ubuntu Nav Computer these are in Chrome.

Cheers
Spart

[wingssail]

Originally Posted by goboatingnow

Why not.

In normal conversation when one person is responding directly to another person it is considered impolite for a third person to butt in and especially aggravating if that third person's comments are generally unhelpful, arrogant, and irritating.

So I politely asked you to be quiet.

[sparticle]

Just for those wondering about power consumption.

With the full Raymarine instruments on, 2 TV's and Amazon Fire TV's streaming movies, the PINAS serving, the AVNAV serving, The Nav Station desktop typing this message and displaying the current active route. and various other boat systems on.

We are using approx 11.1 amps. or 125W total.

We have a Rutland 1200 Wind Turbine and are in the process of investing in a permanently mounted 240W Solar Panel.

So we believe our endurance will be good, not that all that stuff is on most of the time.

I will stop now as this may be offtopic and boring for others.

Cheers
Spart

[goboatingnow]

There are endless to and fro arguments over a web client server solution or distributed master systems.

Given the hardware is now cheap , I’d be a fan of distributed hardware based master systems networked together.

The web server style solutions has a lack of integral redundancy which would be worrying especially in a larger distributed multi station system.

Hence multi station is best served in my opinion by multiple master units each capable of standalone ( or near standalone ) operation .

Yes this means sharing certain common information has to be considered and interlocking multiple users doing different things has to be conducted. But these are common software issues and stock solutions are available.

[wingssail]

Originally Posted by sparticle

Just for those wondering about power consumption.

With the full Raymarine instruments on, 2 TV's and Amazon Fire TV's streaming movies, the PINAS serving, the AVNAV serving, The Nav Station desktop typing this message and displaying the current active route. and various other boat systems on.

We are using approx 11.1 amps. or 125W total.

We have a Rutland 1200 Wind Turbine and are in the process of investing in a permanently mounted 240W Solar Panel.

So we believe our endurance will be good, not that all that stuff is on most of the time.

I will stop now as this may be offtopic and boring for others.

Cheers
Spart

It seems to me that this amount of power will not be supported by the Rutland and 240w panel. Your system as described above will require probably an average of 5 amps 24 hours a day, so 125AH. You probably have refrigeration which will be another 80 AH or more. Plus lights, whatever. Your total usage might be around 210 AH per day, or more.

The 240W panel will probably give you less than 10amps (actual) for six hours per day, or 60AH per day (more or less).

To supply the 150AH difference with the Rutland you need 80 watts continuously for 24 hours, or over 10 knots of wind, probably about 12-15.

For us we'd have to down scale the number of components, particularly the number of LCD screens, to stay within our daily 150 AH budget. On ocean passages, when the loads are greater because instruments etc are on 24 hours per day, we even put the Laptop to sleep and monitor AIS on the VHF radio to reduce power requirements. But then we only have a simple boat and a simple system.

[sparticle]

Originally Posted by goboatingnow

There are endless to and fro arguments over a web client server solution or distributed master systems.

Given the hardware is now cheap , I’d be a fan of distributed hardware based master systems networked together.

The web server style solutions has a lack of integral redundancy which would be worrying especially in a larger distributed multi station system.

Hence multi station is best served in my opinion by multiple master units each capable of standalone ( or near standalone ) operation .

Yes this means sharing certain common information has to be considered and interlocking multiple users doing different things has to be conducted. But these are common software issues and stock solutions are available.

I am not aware of the 'endless to and fro arguments over a web client server solution' the lack of redundancy is common to all single machine application stacks. Unless we are getting more complex with realtime filesystem syncing between disparate network nodes. As you say hardware is cheap it is a <5 min job to fully replace the server with another from the cupboard as it is a headless RPI4 with on my boat 3 USB connections an ethernet cable and a power cable. I can image the server easily every week or month or day! Technically you don't need the ethernet cable as you can use the RPI4 Wifi but we have it so use it. We store all routes, Grib files and other data on the PINAS.

If my Raymarine rudder sensor breaks I have to get a new one and replace it. I am suggesting OpenCPN server would be part of the fabric of the boat like any other marine device. Classic SaaS evolution. Clients are ad hoc and require only a browser and a connection to the boat network!

Engineered simplicity should be a principle in play here. Concentrate all engineering efforts on making the best marine server out there. Consume it with anything.

Simplified maintenance and development pipelines, lower costs, higher quality are all benefits of this type of approach.

Multiple master units is a contradiction in terms. However, using your thinking then any client is a master unit! Or could be. All of us have smartphones all with GPS in them. We all have multiple redundant GPS devices on board most of the time in the event of a serious failure.

We went sailing the other week and worked out between us we had 8 GPS devices onboard! 3 of them fully waterproof.

Cheers
Spart

[AKA-None]

Actually multiple masters equals a cluster

But more power usage obviously

[ZagsAtCF]

Is it possible to show if an approaching boat will pass in front or behind you in the AIS closest approach dialog?