Choosing a gateway ?

[petit bateau]

I'd appreciate thoughts as to which is the best way of organising wireless networks on the boat. Please bear in mind that the boat is 2,000 miles away and it is a lot easier for me to buy the kit now, before driving to the boat. Upthread I chose to go with the Actisense W2K-1 as a wireless gateway between NMEA and OpenCPN/etc.

Now the decision is regarding how best to organise the wireless network. I think there are two options

A) Everything via one common WiFi router, per diagram below



B) Separate Leisure & Navigation networks



At least I think these are the two basic options (am I missing anything ?); and I think both can be done using the Actisense W2K-1 (have I got that right ?).

Do folk have any advice or thoughts as to which is the better way to go, or reasons for choosing between one or the other ?

[petit bateau]

OK, I am now on the boat so I can try this in practice. I didn't receive any comments from anybody re network option A vs option B. So I've gone with option A for now. And of course there are problems ..... so advice/comments/etc is welcome.

I've installed the Actisense W2K-1 gateway onto my fairly basic NMEA2000 (STng) network, and got it communicating per option A in the diagram above, i.e. to a WiFi router that in turn can communicate with a variety of other devices. I've tested the gateway with a Windows 10 laptop, an Android tablet, and an Android phone per below.

I used the NMEA 0183 format, set up for bidirectional use. That is what is currently in the Actisense setup guide "Using OpenCPN with the Actisense W2K-1". I don't understand why OPCN 5.8.4-0 is still preferring NMEA 0183 format, rather than NMEA 2000 format. That is a genuine question, I'm guessing that for now the documentation and debugging has yet to catch up. Maybe I'm a live debugger, of the newbie flavour.

For all of these devices I can acess the web-config-tool of the Y2K directly, initially in access point method and then (once configured) in wifi client method - that works OK, so it proves the Y2K is there and happy on the wifi network. I can also call up the router web-config-tool and see the Y2K gateway established on the wifi network, and I can identify the IP address etc OK.

For the Android devices I can then (one at a time) check that I can access the NMEA data OK by using the NMEA Dashboard app from Sankey. Interestingly, and perhaps relevantly, that crashes if I simultaneously access from both Android devices. But at least that proves I can get all the existing NMEA data out of the Wifi gateway.

https://play.google.com/store/apps/d...nmea_dashboard

Then - and this is of course the point of the exercise - I connected the Win10 PC via WiFi and could see messages in the debug window. I think that the colour coding indicates that the messages are OK, i.e. “accepted” though the colour code key is the reverse of what I would have expected.



As you can see in that screengrab I do not have a SOG or COG, as I am in the yard out of water. As yet the position is also wrong, just driven by the cursor.

BIG QUESTION(s)
How long would you expect the debug window to stay running before crashing ? Ordinarily when I run a debug window in something (which I try to do very infrequently, that is not the sort of engineer I ordinarily am) I expect it to stay running indefinitely. However in OCPN it seems to crash within a minute or so. I have to reboot OCPN to get it running again. By the way if I have any of the Android apps running NMEA Dashboard that also seems to provoke a OPCN debug crash. What I am unsure about is what is going on, though I have theories. But I figure now is a good moment to ask for thoughts as to how stable a system I ought to expect with this overall set up.

*** Any answers / thoughts / comments ? ***

(I suspect this goes back to the option A vs option B question I asked a few weeks ago)

(I have also tested ‘casting’ the OCPN screen from the Win10 laptop to the Android tablet using the Google Remote Desktop app, and that seems to go OK. It is however a one-way ‘cast’.)

(Oh for a reference installation document or three, for newbies like me on Win / Pi / Android so that we can at least have stable known systems to work from. When -if - I get mine running I’ll be writing it up and putting it online. Hopefully that will be a write up of a working and stable install.)

[bdbcat]

petit...


First, thanks for the detailed discussion.


1. Your target setup is reasonable, well within the capabilities of OCPN networking, as designed.


2. Regarding the stability: We are shortly going to start Beta testing for OpenCPN V5.10. We have made significant updates to the communication stack, mainly focused on NMEA2000 interfacing and general performance and stability. If you would like to test the pre-Beta code in you current setup, you may experience better results. And you would help us greatly in validating the new code base.


You may download the pre-Beta release from here:



https://dl.cloudsmith.io/public/davi...E3MTI1Mzg5ODU.


Thanks
Dave

[petit bateau]

Originally Posted by bdbcat

petit...


First, thanks for the detailed discussion.


1. Your target setup is reasonable, well within the capabilities of OCPN networking, as designed.


2. Regarding the stability: We are shortly going to start Beta testing for OpenCPN V5.10. We have made significant updates to the communication stack, mainly focused on NMEA2000 interfacing and general performance and stability. If you would like to test the pre-Beta code in you current setup, you may experience better results. And you would help us greatly in validating the new code base.


You may download the pre-Beta release from here:



https://dl.cloudsmith.io/public/davi...E3MTI1Mzg5ODU.


Thanks
Dave

That is helpful to know. Let me focus on getting out the yard and into the water and around to a safe place (on paper charts ) and then I'll try that beta. Unless rain stops play in which case I'll download it faster. I should be able to comment within about a week.

regards, pb

[petit bateau]

Just a quick update before I forget some stuff that may be relevant to others. I'll try to put enough info in that search engines will be able to find it if others are lost.

I am connecting a Standard Horizon GX2400GPS to a NMEA 2000 network, specifically the SeatalkNG version (STng). So the GX2400 has a network cable with a DeviceNet connector on one end and a STng connector on the other end. The STng network operates fine on its own before plugging together. The GX2400 seems to work fine when powered up out of the box, i.e. AIS, GPS, and VHF all function.

After switching off the annoying AIS alarms, it then becomes clear that the STng network is not seeing the GX2400 at all. Looking in the GX2400 manual is no help. This post by Kimolaoha on thehulltruth contains the answer.

https://www.thehulltruth.com/marine-...0-network.html

So go to p95 (section 15.3 and 15.4) in the GX2400 manual, and set DEVICE NUMBER to 009 rather than the factory default 000. I then cycled the power on both the STng network and the GX2400 and then I could see that the GX2400 was then present on the STng network. To observe this I looked on my Actisense Y2K under the Home/Actisense-i/Network report and I could see the Standard Horizon GX2400 listed. I guess you can see the device by other means, but that is the means I used.

I hoped that would lead to a flood of AIS-GPS-VHF.DSC data coming through onto NMEA2000 / STng, but it does not.

This post by Jim_Arndt on thehulltruth contains the answer

https://www.thehulltruth.com/marine-...dopters-3.html

The underlying issue is that Yaesu/Standard Horizon have taken some shortcuts in their firmware for the GX2400 and seemingly repurposed the NMEA 0183 menu etc to also control the NMEA 2000 configuration. At least that is if I understand what is going on.

So turn to p117 (s19.9.2) and p118 (19.10) and p121 (s19.11) in the manual. What I have done so far is to both turn ON the OUTPUT SENTENCE fot DSC/DSE and also I have changed the POS DATA OUTPUT toggle for NMEA 2000 from OFF to ON.

That then brings GPS Lat and Long data flooding through to the various STng NMEA2000 screens. It may also bring VHF-DSC position info through to plotters but since I don't have a conventional plotter I don't know.

However that did not bring position data through to OpenCPN. There I observed that the OpenCPN NMEA debug window had crashed. So I closed down OCPN and restarted it, and bingo the ship's actual lat/long were then correctly showing and the ship magically moved 50-miles to its real position in the yard.

I have also simplified the wifi system on the boat so as to try to eliminate one reason for system crashes. I have closed down the 'ship-guest' wifi network and consolidated all devices onto the one "ship" wifi network. That way there is less chance of crashes caused by hopping. Too early to tell if that has made a change. Not ideal from a security perspective mind you as it gives guests access to more controls.

I would like to report that the NMEA Dashboard android app is behaving well. Unfortunately whilst it is intermittently useful it does crash occasionally - black screen of death is the latest. I am taking the precaution of only running it on one device (my phone) to again minimise reasons for crashes, but that doesn't seem to be helping. It would be real nice if OCPN could have an equivalent function built in, that ought to be an easy code port for someone. Anyway it is already useful a second opinion when trying to minitor data flows.

The AIS data also seems to be coming through onto the STng i70 5" displays but being in the yard the max targets is coming up. Also the AIS data is coming through from the GX2400 via STng/NMEA2000 to OCPN which is nice.

It may be that others figure out better settings for the GX2400 to integrate as the AIS / GPS source for NMEA2000 and OCPN in which case please let me know. I am by no means sure I have found all the relevant settings.

I have yet to do the OCPN beta software test. Too much other stuff going on at present.

[petit bateau]

Originally Posted by bdbcat

petit...


First, thanks for the detailed discussion.


1. Your target setup is reasonable, well within the capabilities of OCPN networking, as designed.


2. Regarding the stability: We are shortly going to start Beta testing for OpenCPN V5.10. We have made significant updates to the communication stack, mainly focused on NMEA2000 interfacing and general performance and stability. If you would like to test the pre-Beta code in you current setup, you may experience better results. And you would help us greatly in validating the new code base.


You may download the pre-Beta release from here:



https://dl.cloudsmith.io/public/davi...E3MTI1Mzg5ODU.


Thanks
Dave

1. It is really helpful to know that my proposed set up is realistic.

2. I've downloaded the pre-beta. Thank you for the offer. The install went fine.

I shut down my running OCPN 5.8.x before installing the pre-beta. Post install the taskbar icon was still showing OCPN 5.8.x and I was unsure where that was in reality pointing, but I clicked it anyway and something launched. I killed it almost immediately when I realised that the NMEA debug screen was frozen.

At that point I did a full machine reboot and opened to a clean desktop, where I noticed a shortcut to OCPN 5.9.0 that had been placed placed on my (Win10-PC) during the update. So I launched that and subsequently observed that the taskbar icon updated to 5.9.0.

There is not much I can see in 5.9.0 that is different, nothing really. When I open the NMEA debug window it is running without crashing for approx 20-minutes now, whereas with 5.8.x it was crashing within a few minutes.

What is your expectation of stable run duration of the debug window please ? For that matter what is your expectation of the stable run duration of OCPN please ? (many weeks hopefully).

When the debug window freezes (aka crashes) I suspect that OCPN is itself freezing - at least as far as being a dependable plotter is concerned. However the GUI still stays responsive if one wishes to interact with it, so this type of crash is quite insiduous. Since I am sitting in the yard there is not much that ought to be changing onscreen, and so the way I observe the crash is either/or by noting that the NMEA debug window has frozen, or by noting that AIS data has disappeared. If the vessel were navigating without much on screen one might not realise that a crash has occurred, which is why I term this to be insiduous.

My Win10 laptop is a Asus laptop that was bought about 6-years ago and has been absolutely rock solid apart from one Windows update that bricked it in 2021. We did a Windows reinstall and since then it has continued to be rock solid. So I'm quite happy with the machine and it is my reliable daily driver. I'm only using it now for OCPN as I am testing out whether OCPN is dependable before installing a dedicated ship's device of some sort. I mention this because I am reasonably confident that my laptop is not itself the cause of any OCPN crashes. That is not to say that something may be going on with my laptop that I do not realise, so if I am wrong please say so.

Does having the debug window running have any impact on underlying OCPN stability ?

----------

It would be a nice feature if OCPN were to be able to view all attached network instruments/data. As far as I can see the various plug-ins for that (i.e. Dashboard SK) have had no attention for ?? 18-months. *

Preferably I'd like to be able to flip to a second screen showing everything that is on the NMEA bus, much as one ought to be able to do in the Android app by Jody Sankey"NMEA Dashboard", or the "NMEAremote" by zapfware on Apple.

https://apps.apple.com/us/app/nmearemote/id412806204

https://play.google.com/store/apps/d...rd&hl=en&gl=US

There are multiple reasons I suggest this. Firstly if I've got a big screen it would be handy to be able to use it without toggling to a different app. Secondly the more you (OCPN) get folk used to - and wanting to - use OCPN as their normal tool, the more you will get the adoption loop running. Thirdly in my particular instance of yard testing I would be looking for something variable (like wind instrument info) to be able to recognise whether OCPN itself has crashed, so tools like this can be useful for debugging.

--------
Anyway, let me know if any of this is useful, and if you'd like any more info or have any more questions. Otherwise I'll report back when I get to sea.



* I'll go and try that DashboardSK in due course, but it does have an abandoned project look about it.

** Next job to figure out how to get the OCPN system clock reading from GPS time as opposed to PC time, or at least be sure what is going on.

(you may have seen that in my previous post I put up some configuration info re the Standard Horizon GX2400 GPS-AIS-VHF, hope that helps anyone writing manuals.)

(I have raised the vector chart update issue with Greek authorities, since O-charts don't seem interested (presumably O-charts monitor here, or do they have another presernce on Cruisers Forum etc ? ) but the reaction from the Greek authorities was not encouraging ..... )

Hope this helps,

regards, pb

[petit bateau]

Yes, when the debug window crashes, then subsequentlu OPCN itself also crashes. What the time interval between th etwo crashes is I do not know as yet.

The only reason I can detect that OCPN has crashed is by noticing that AIS data disappears.

It would be really handy if there was something visual in all the default OCPN screens to indicate it was alive and healthy. A rotating earth (a la the old netscape logo) or something similar. Or a in-screen display of OCPN system-time (as distinct from the computer's time) in hh.mm.ss so that one could observe the mm.ss updating as a visual cue.

I ordinarily have chrome and maybe outlook running simultaneously, plus some messengers (WhatsApp, Messenger, Telegram). I'll experiment with whether closing all these makes any difference.

[Hakan]

Originally Posted by petit bateau

something visual in all the default OCPN screens to indicate it was alive and healthy.

There is although not very distinct. When O has a position update the lower left screen corner sign, /-\, before " Ship...." is changing. That's is not happening if O is hanged.
btw: your problem with NMEA Debug window I can't reproduce on my W10. I have all kind of Nav-data and hundreds of AIS targets.

[petit bateau]

Originally Posted by Hakan

There is although not very distinct. When O has a position update the lower left screen corner sign, /-\, before " Ship...." is changing. That's is not happening if O is hanged.
btw: your problem with NMEA Debug window I can't reproduce on my W10. I have all kind of Nav-data and hundreds of AIS targets.

Hakan - Thank you, that is useful. I will carry on testing. I have also downloaded the Android version to a tablet to do a compare and contrast of what occurs.

[petit bateau]

Hmmmm .... does anyone know if the Android version of OpenCPN can read NMEA 2000 ? or can it only read NMEA 0183 ?

[Hakan]

I've not yet tested and I'm not at home to be able to do that for the moment.
But if you can connect serial to a Actisense or Yacht Device -USB device and connect that to your Android it would work. A USB-A to USB-C adapter may be needed.

A network-wifi connection would work as well.

[petit bateau]

OK, a few updates.

I have now been able to get stable connections and runtimes with both OCPN-Android and OPCN-Windows, but the journey is by no means over.

For the OPCN-Android it is running on a Lenovo M10 tablet, using the paid Dave Register version (though I believe he doesn't get any $$ from it, the $$ go to Google for Android store subs). I haven't been able to get access to the Android support forum, though I have asked for it. Might be logon ID issues, but they do a 48h lockout over there so could be a slow trouble shoot ......

https://bigdumboat.com/aocpn/forum/portal.php

For the OPCN-Windows it is running on a fairly old Asus laptop using 5.9.0-beta'ish in Win10.

Pretty much the only reasons I have the Android running is as a cross-check on the Windows version; to assist in troubleshooting; and because 'mirroring' of screens between two devices to cater for inside/outside device locations is less than ideal in OPCN.

I've been able to import/export/peer-share routes and tracks between the two devices using the "share to peer" function in Route And Mark Manager. That has gone really well. Which is fortunate really as the user-interface experience in the Android version is not perfect. So it is a lot easier to set up stuff in the laptop inside and then share it to the tablet outside.

In order to become stable I have put the Actisense W2K-1 WiFi Gateway into Access Point Mode, and pointed both devices at that alone. At one point I had the gateway running in WiFi Client Mode but that experience at the time was unstable, and so far I have only tested that on the laptop. I suspect that the laptop was trying to hop between wifi networks and that was causing the crashes. Now both devices are running stably in Access Point Mode using TCP and I'm set to bidirectional comms as ultimately I'd like to get waypoints etc into the autopilot. Although my STng network is of course running NMEA 2000 through it, the WiFi Gateway default is set to NMEA 0183. The Actisense product literature has yet to catch up with 2000 so the set up guide doesn't talk about that .... something to explore there.

But at least this way I can see the NMEA debug window running and comms looking healthy. Very occasional message glitches but nothing to get upset over imho.

Running in Access Point Mode is not my preference for multifunction devices like these as it means I have to disconnect from the gateway, and connect to whatever other comms I have (dock wifi, cell phone) to do other stuff. That makes troubleshooting tedious if nothing else. However I can see that it would be a way to a walled garden situation if I had dedicated devices.

Getting the gateway into WiFi Client Mode is a real PITA as one has to solve both ends in strict sequence. And of course the devices one is trying to set up for OPCN are also the devices one is trying to to do the router configuration and gateway configuration with. Argh. I've stumbled into managing that on one occasion (at least I think I did) but the other 999 occasions went wrong somewhere. In due course I'll try again. Did I say before that a reference configuration would be real handy for newbies like me .....

I can see on the OPCN Facebook page https://www.facebook.com/groups/2405863179652854 specifically at https://www.facebook.com/groups/2405...3621644543662/ that others are also struggling with the amount of network knowledge required to achieve this feat. Well documented reference configurations would be a real help for lots of people ......

A real doozy came up at the end of the day today, which I still have not solved. Once I got the OPCN devices operating the AIS alarms on the Raymarine i70s display went bonkers. Up until that point the AIS CPA alarms had been silent, even though the NMEA 2000 / STng network had been operating for hours with GPS and AIS data flowing through it. My AIS feed comes out of the combi-VHF-GPS-AIS radio (Standard Horizon GX2400) and I had previously disabled the CPA and TCPA alarms in the GX2400 as I was in yards (and am now in harbours) and didn't want to be told I was going to be hit every 5-minutes due to yachts being moved around for launching.

I suspect that the AIS-configs in the OPCN devices had flowed through to the i70s and overridden the simple "alarm-off" toggle in the GX2400. So my first thought was to go to the AIS config panels in the two OPCN devices and to try to kill the alarms that way. No joy, so whatever I was doing was not sufficient. I checked that the GX2400 was still toggled to alarms off, and indeed it was. Trying to go into the Raymarine i70s itself to disable the alarms was a no-starter. The i70s would allow me to acknowledge an alarm, but not to disable alarms. Interestingly the i70s would not give me access to any AIS alarm set up pages at all.

The ship causing the CPA alarm is a yacht about a 100-metres away that thinks it is doing 0.9 knots. It is firmly tied up alongside. Either its speed sensor is goosed, or they are running the engines and are in gear and have propwash over the log. Regardless getting an alarm every minute was a bit wearing so I finally decided to kill the alarm my turning off the GX2400, and thereby getting rid of the AIS feed. Unfortunately that did not work and the i70s kept on alarming on CPA ...... very annoying. Quite what was the AIS input information causing it to think that a close-approach might occur is anybody's guess, because I couldn't figure it out. So in the end I turned the entire set of instruments off and wrote up this little note.

I wonder if having two OPCN devices running simultaneously on the network causes problems ?

By the way I noted that in the OPCN > Options > Connect dialog box there is an NMEA 0183 talker ID. In both the Android and the Win devices this seems to default to the same two-letter pair, either AP or EC. What is the significance of this ? And should one overwrite it with someting and what ? especially if two different OPCN devices are present on the same network. ? I can envisage an AIS racetrack occurring for CPA parameters, or many other nav parameters for that matter.

So ..... enough for today. Any thoughts welcome as I slog through this ....

[petit bateau]

Hmmmm ...... I have now found and disabled the i70s alarms on each individual i70s display. But I still have no ides where the AIS data was coming from during the period the GX was switched off.

[petit bateau]

Hmmmm ...... another gotcha.

Today I kept getting alarms from the Raymarine i70s screens saying "FIX LOST". And indeed when I glanced at the GX2400 VHF-AIS-GPS the date/time and positions had all gone to 00000000. Most odd. The weather is fine, plenty of satellites in the sky, so what was going on.

I eventually traced this to the Android tablet being on, and moving it downstairs into the saloon where I was trying to get the anchorwatch plugin to work (not a great piece of plugin software on Android, I've ended up removing the plugin as being the only way I could figure out to turn it off), and reading manuals on the laptop at the same time. Going below was enough for the tablet to drop its GPS fix.

Unfortunately the GX2400 does not have the capability to set its own internal GPS receiver as the highest priority GPS source. The relevant extract from p115 (section 19) of the GX manual is,

"the internal GPS receiver is always set as the lowest priority" and there is only the possibility to toggle between NMEA 2000 and NMEA 0183 as being the highest priority.

My issue is that the GX is my only 'normal' GPS receiver. Except of course for the one in the tablet which gets picked up on the NMEA network via the Actisense gateway. So when the tablet is switched on and taken below it loses its GPS fix, the NMEA 2000 network is then carrying 0000 DTG and LAT LONG data, and the GX picks that up and follows it to 00000 and of course the i70s then also go into alarm.

Hmmmmm....... one option is to disable the GPS in the tablet. Another option is to not use the tablet below. Another is to put a pukka GPS receiver on the NMEA 2000 network. I don't seem to have any configuration options anywhere to force the GX's GPS to top priority.

It would be real nice if the Actisense Y2K-1 wifi gateway also had a USB port and an ethernet port in it. That would make it an absolutely fantastic piece of kit as opposed to merely a very good one. I could put a USB GPS puck into it, and a ethernet cable to the main router, and it would give flexibility to solve a lot of problems.

Hmmmm..... did I ever say some known functioning reference system designs would be real helpful for utter newbies ......

[stevead]

A few observations/questions.

There are two sources of GPS position data:
1. Standard Horizon GX2400 built-in GPS
2. Android tablet running OpenCPN.

When the Standard Horizon detects an external GPS source over either NMEA 2000 or NMEA 0183 it gives that source a higher priority than its internal GPS

When the Android tablet is taken below, it loses its GPS fix causing the following:
1. The Standard Horizon GX2400 loses its GPS fix (Doesn't display position or date/time).
2. The Raymarine I70s displays display a Lost GPS Fix alarm


I'm assuming you have connected OpenCPN on the Android Tablet to the Actisense W2K-1 using NMEA 0183 over TCP. (From the Actisense manual it appears as though the W2K-1 does not receive over UDP)

First thing is to filter out Position Messages emitted from OpenCPN on the Android tablet to prevent them from appearing on the NMEA 2000 network.

Either set an outbound filter in OpenCPN for the NMEA 0183 TCP network connection.
a. For the "Transmit" option set a filter "Drop Sentences" for GLL, GGA, RMC, GSV, GSA. (You may want to confirm exactly which sentences are being generated by OpenCPN from the NMEA Debug Window.)

Or set a Rx filter in the Actisense W2K-1 to filter out the conversion of the NMEA 0183 position sentences (use the same sentences as above). Alternatively set a Tx filter for the NMEA 2000 messages, 129025, 129026, 129029 & 129540.

You can also set a Data Source option on the I70s displays, I'm guessing it's currently set to Auto. If both the GX2400 and OpenCPN are providing position data, the i70s should show the presence of two sources of NMEA 2000 position data; the GX2400 and the W2K-1 and you should select a preference for the GX2400.

All of this being said, it seems like there are potentially a few bugs or at least some unexpected behaviour. I thought it would be reasonable to expect that if the GX2400 and i70s, when two sources of GPS data are available, if one source (the Android tablet) lost its fix, that they would switch to the other source. Perhaps contact Standard Horizin and Raymarine and ask about that behaviour, although I would tend to guess that they would suggest that your boat needs a stable GPS position source.

Regarding AIS Alarms being displayed on the i70s when the GX2400 is switched off, this makes absolutely no sense. For the instruments to display an alarm, there must be AIS messages floating around from somewhere. You need to identify that source.