OpenCPN General

[bcn]

On macOS 13.x

[uneven_sailor]

Originally Posted by Hakan

Now I don't have a Mac so I can't see what's available for that, but just to be sure: You did use the button "Update Plugin Catalog: master" Right?

Sorry for my delay here in replying -- thanks for your responses!

Confirming, I did refresh the catalog by clicking that button and am still not seeing it...

Not sure if this is related or not, but I am noticing something else now as well -- when I go to Settings>Display, I'm also noticing that the list of configurable options is fairly limited compared to what I see in the manual...might this be related to the Squidd.io plugin issue as well? Or is this something else?

Thanks all for reading my posts and chiming in! The program is amazing (and powerful!) and it's a huge help to have some support to figure out the details to get it up and running just right. Thanks.

[uneven_sailor]

Originally Posted by bcn

On macOS 13.x

Thanks -- I should also mention that I'm running MAC v. 10.15.7...I don't think I can update to v13 because my laptop is too old

That may also be part of the problem?

[wleiden]

I’ve been using OpenCPN for several weeks, but yesterday, something happened to change the color scheme on me (on my Mac). The dialogue Bo’s that comes up when you hover on a course or bearing is now a dark olive green, and I can barely make out the range and besting text. How do I get back to an easy to read background color? Thanks.

[wholybee]

Originally Posted by wleiden

I’ve been using OpenCPN for several weeks, but yesterday, something happened to change the color scheme on me (on my Mac). The dialogue Bo’s that comes up when you hover on a course or bearing is now a dark olive green, and I can barely make out the range and besting text. How do I get back to an easy to read background color? Thanks.

Press the "C" key a few times. It will change color each time until it gets back to normal.

It is intended as a night mode. If your eyes are adjusted to being in the dark, those other colors are readable without affecting your night vision.

[JD2E]

To control my Raymarine EV1 (autotrack) I need the following information according to Raymarine:

- BTW= Bearing to Waypoint
- DTW= Distance to Waypoint
- WPID= Waypoint ID (waypoint number)
- XTE= Cross Track Error

Can anyone help this dumbass get the OpenCPN (version 5.8.0.0) equivalents with exception of XTE?

Thanks in advance.

[nohal]

You can't do this with bare OpenCPN, which produces only the standard XTE/APB sentences. There is a plugin for Raymarine EVO autopilots (https://opencpn-manuals.github.io/ma...ine/index.html), but connected via NMEA2000, not NMEA0183.

[JD2E]

Unfortunately I use a Macbook instead of a Windows PC.
Sentences are translated from 0183 to 2000 by means of a WiFi gateway from Yacht Digital (YDWG).
The thing is that Autopilot functioned once and the next time, after I switched of the Mac, the gateway led blinks two times green, once red, once green. Which means that he is not receiving information although a route is activated. When I switched of the GPS, I had 4 green blinks. Nasty but without a position it is hard to navigate :-) GPS is connected normaly via a COM-port and the Autopilot via UDP network of the WiFi gateway with correct URL (192.186.4.1) and port 1456. If it worked once, why doesn't it work after the Mac has been switched off? Gremlins?

[wholybee]

Originally Posted by JD2E

Unfortunately I use a Macbook instead of a Windows PC.
Sentences are translated from 0183 to 2000 by means of a WiFi gateway from Yacht Digital (YDWG).
The thing is that Autopilot functioned once and the next time, after I switched of the Mac, the gateway led blinks two times green, once red, once green. Which means that he is not receiving information although a route is activated. When I switched of the GPS, I had 4 green blinks. Nasty but without a position it is hard to navigate :-) GPS is connected normaly via a COM-port and the Autopilot via UDP network of the WiFi gateway with correct URL (192.186.4.1) and port 1456. If it worked once, why doesn't it work after the Mac has been switched off? Gremlins?

Autopilot will only work via TCP. It will not work via UDP. UDP is unidirectional, meaning that the YDWG can send data to your Mac, but can not receive data from your mac. So make sure your connection in OpenCPN is TCP, not UDP.

The 3rd red blink means that there are no TCP connections to the YDWG, but there might be a UDP connection. It has nothing to do with any data being sent or not. Just that the TCP connection has not been made.

First, the Mac needs to connect to the YDWG wireless network. Then, OpenCPN makes the TCP connection to port 1456.

I have at times had my YDWG fail to accept connections and require a reset. There is a little hole and you reset it via a paperclip. There are 2 levels or resetting it. The full reset requires holding for 5 or 10 seconds, I forget.

And of course, the OpenCPN connection needs to be set to both send and receive data, and the YDWG needs to be set to enable autopilot control.

I suggest using a GPS on your NMEA network, and not a GPS plugged into your Mac.

[wholybee]

Originally Posted by nohal

You can't do this with bare OpenCPN, which produces only the standard XTE/APB sentences. There is a plugin for Raymarine EVO autopilots (https://opencpn-manuals.github.io/ma...ine/index.html), but connected via NMEA2000, not NMEA0183.

OpenCPN works fine with the EV1 without any plugins and without NMEA2000. I've been doing that for some time. Any commercial NMEA0183-2000 gateway (actisense/yacht devices/etc) handles the translation fine. Hence, I don't understand what that plugin is needed for. Maybe some peculiar connection type?

The only thing it can't do is start the autopilot (engage "auto"). Even that, the YDWG-02 will optionally do when it receives the APB sentence.

[JD2E]

Ok I will try again with TCP although the YDWG is set to UDP both directional. I will also disable the autopilot plugin. Will see what happens. Thank’s for the advise.

[nohal]

Originally Posted by wholybee

Hence, I don't understand what that plugin is needed for. Maybe some peculiar connection type?

Yes, one called NMEA2000... It implements the Raymarine proprietary PGNs, so no device doing translation, like the YDWG, is needed.

[wholybee]

Originally Posted by nohal

Yes, one called NMEA2000... It implements the Raymarine proprietary PGNs, so no device doing translation, like the YDWG, is needed.

Yeah, but that plugin was released in 2020, 3 years before OpenCPN supported NMEA2000. In 2020, you *had* to have a device that made a conversion, because a pure n2k device would not work with OCPN. And with that device, the plugin isn't needed.

Now that OCPN supports NMEA2000, I hope adding the Raymarine PGNs are on the short list (after fixing known bugs).

[nohal]

Adding any proprietary PGNs of a single vendor is not on any list for the core application, that's exactly where plugins like this one have and should have their place.
The only difference with O5.8 is we take care of the connection to the NMEA bus for them.

[wholybee]

Originally Posted by nohal

Adding any proprietary PGNs of a single vendor is not on any list for the core application, that's exactly where plugins like this one have and should have their place.
The only difference with O5.8 is we take care of the connection to the NMEA bus for them.

The required PGN's (except for the one that sets auto mode) are not proprietary and should work with any autopilot manufacturer. I have no argument about using a plugin for a "raymarine remote" that implements changing modes, adjusting course, etc. That is fine. But the PGN's for supporting track mode are standard and should be in the core, just as the equivalent NMEA0183 sentences are included.

And of course, I know that you have put a hell of a lot of work into this, and those things don't all come at once.

129284 0x1F904 Navigation Data
129285 0x1F905 Navigation — Route/WP information
129283 0x1F903 Cross Track Error
130066 0x1FC12 Route and WP Service — Route/WP— List Attributes
130067 0x1FC13 Route and WP Service — Route — WP Name & Position
130074 0x1FC1A Route and WP Service — WP List — WP Name & Position