OpenCPN General

[bdbcat]

JdaleH...


Your account approved and enabled.
Welcome aboard


Dave

[JdaleH]

Thanks, but I still can't get into the android App Support Forum on bigdumboat. Sez I have about 21 hours left in quarantine. I need a password reset or I'll get another 48 hours. Regards, Dale

[bdbcat]

Dale...


email sent to you at: jxx.xxxx.xxxxxn@gmail.com.
Dave

[Gypsylyon]

This summer I sailed with the following setup:
Raspberry 3+ with the Hut Moitesier with OpenPlotter V1.2 as server NMEA183 sentences via WiFi
The Hut Moitesier has GPS, AIS, magnetometer and Gyro.
Raspberry 4 with Raspbian Buster and OpenCPN connected to Raspi3+ via WiFi.
As in the Sailboat I have the wind equipment, velocimeter, depth gauge and fluxgate in SeaTalk, to see the SeaTalk rez in OpenCPN, this is connected to a SeaTalk converter-multiplexer to NMEA183 and NME2000 all duplex. This converter-multiplexer I connected to Raspberry 4 by RS422 to USB converter.
In the Raspi4, in OpenCPN, I have opened a network port to read the Raspi 3+ and a serial port at 4800 bauds to read to the multiplexer with SeaTalk sentences.
I have observed two problems in OpenCPN.

One of the problems was the next.
Since both SeaTal and the Raspberry 3+ send magnetic compass information, openCPN selects the serial sentences and rejects the Raspberry sentences via WiFi. This way, OpenCPN only reads the SeaTalk Flux Gate information.
While Navigating, data entry through the RS422-USB converter has failed, disappearing the magnetic rumb information.
Although the Raspberry 3+ connection still worked, OpenCPN did not read the magnetic compass data sent by the Raspi 3+ via WiFi.
To receive this data, I had to reset OpenCPN.
I can understand that OpenCPN, select a source of information when the sentences are repeated to avoid conflicts. But it is logical that when the preferred source fails, the second one is automatically activated, so that there is no loss of information, without having to reset OpenCPN.
I have repeated this situation and it has always happened the same as I have exposed.
I don't know if this problem is known by the developers of OpenCPN or someone else has observed it.
If I have a redundant system of two magnetic compasses, so that in the event that one fails, the other can continue sending data, and that way, the electronics of the ship continues to work, in this case the autopilot,
I have tried changing the priority of the ports but the failure has remained

My question is, if there is any way to get that in case of a redundant system, if the priority source OpenCPN fails can read the secondary ?
And, if it can't be done, could a function like this be implemented in the next OpenCPN updates?

The second problem I encountered was that the WiFi connection between the Raspi 4 and the Raspi 3+ failed, ceasing to receive GPS data. At that time I was navigating with the autopilot in track mode.
When I went down to check how long it was for the next WP, notice that the icon of the ship in OpenCPN had not advanced and was about 6 NM behind the actual position.
That is to say, I had navigated 6NM, in Autopilot in Track form without the GPS information.
I have repeated this failure with OpenCPN in Raspberry, as in the android handy as in the laptop under Windws10.
In all cases OpenCPN sends the sentences to the autopilot when the track is activated without receiving GPS data.
I find this a serious bug in OpenCPN, that can put the vessel in dangerous situations and which should be corrected. I think that if no GPS data is received, the track should not be able to be activated or if it is activated, it should be automatically deactivated.

[jmh2002]

Originally Posted by Gypsylyon

This summer I sailed with the following setup:
Raspberry 3+ with the Hut Moitesier with OpenPlotter V1.2 as server NMEA183 sentences via WiFi. The Hut Moitesier has GPS, AIS, magnetometer and Gyro. Raspberry 4 with Raspbian Buster and OpenCPN connected to Raspi3+ via WiFi...

Thank you for your interesting post

[rgleason]

Gypsylyon,
I think you should make a new thread of your own for this, titled as you wish.
Just copy your original post to start it. (I know it is against the forum recommended practices, but this will be better. This will be a long thread I believe.)

Originally Posted by Gypsylyon

This summer I sailed with the following setup:
Raspberry 3+ with the Hut Moitesier with OpenPlotter V1.2 as server NMEA183 sentences via WiFi
..with wind equipment, velocimeter, depth gauge and fluxgate in SeaTalk, ..using converter-multiplexer to NMEA183 and NME2000 all duplex connected to Raspberry 4 by RS422 to USB converter.
.. Raspi4, in OpenCPN, I have opened a network port to read the Raspi 3+ and a serial port at 4800 bauds to read to the multiplexer with SeaTalk sentences.

I have observed two problems in OpenCPN.

...If I have a redundant system of two magnetic compasses, so that in the event that one fails, the other can continue sending data, and that way, the electronics of the ship continues to work, in this case the autopilot,
I have tried changing the priority of the ports but the failure has remained

The second problem I encountered was that the WiFi connection between the Raspi 4 and the Raspi 3+ failed, ceasing to receive GPS data. ..[when] navigating with the autopilot in track mode, .. [noticed] that the icon of the ship in OpenCPN had not advanced and was about 6 NM behind the actual position.

In all cases [android, win10, rasp] OpenCPN sends the sentences to the autopilot when the track is activated without receiving GPS data.
I find this a serious bug in OpenCPN, that can put the vessel in dangerous situations and which should be corrected. I think that if no GPS data is received, the track should not be able to be activated or if it is activated, it should be automatically deactivated.

Gypsylyon, I think you should try to simplify your setup if possible and test again.
1. For the backup GPS by setting priority, is there a way to setup two different GPS signals going to Opencpn more directly, and then test? This is necessary to isolate what may be wrong.
2. I don't have any ideas about the autopilot issue at the moment.



Can anyone else confirm these two potential bugs?

[P_Dub]

Dual Equipment has brought problems ever since electronic charting started.
It is most likely the cause of it. In this case 2 magnetic compass.

[Hakan]

Originally Posted by Gypsylyon

............
I find this a serious bug in OpenCPN, that can put the vessel in dangerous situations and which should be corrected. I think that if no GPS data is received, the track should not be able to be activated or if it is activated, it should be automatically deactivated.

My view:
I can possible agree an active route would deactivate if no position is received. But to describe it OCPN causes a dangerous situation I do not agree:
If the route is deactivated the AP would go from Nav into Auto mode and keep follow the last course. It may sound a short alert though. But if you not notice that either there will be no difference if O stop sending nav-data.
OCPN is an aid for navigation and if you haven't noticed a GPS failure for an hour or so depending of your speed don't blame OCPN.

If you'd like more automated alerts the plugin Watchdog can offer a sound alert if no active NMEA-XXX for xx seconds or a Deadman alert if you haven't touched the screen for xx minutes. Unfortunately no alert if the PC hangs though. For that case an old fashion egg-clock may do.

Håkan (Hopefully not a grumpy impression. That's not my aim. I that case only bad English.)

[Gypsylyon]

Originally Posted by Hakan

My view:
I can possible agree an active route would deactivate if no position is received. But to describe it OCPN causes a dangerous situation I do not agree:
If the route is deactivated the AP would go from Nav into Auto mode and keep follow the last course. It may sound a short alert though. But if you not notice that either there will be no difference if O stop sending nav-data.
OCPN is an aid for navigation and if you haven't noticed a GPS failure for an hour or so depending of your speed don't blame OCPN.

If you'd like more automated alerts the plugin Watchdog can offer a sound alert if no active NMEA-XXX for xx seconds or a Deadman alert if you haven't touched the screen for xx minutes. Unfortunately no alert if the PC hangs though. For that case an old fashion egg-clock may do.

Håkan (Hopefully not a grumpy impression. That's not my aim. I that case only bad English.)

Thank you very much for your comments.
Of course the duplication of inputs is a problem. In fact, I assume that openCpn has a filter mounted for these cases.
What I have observed is that, so say, once activated the filter is no longer deactivated when the situation has changed. In this case when the selected source stops sending data, OpenCPN does not look for an alternative source.
The reason I report this bug is that I haven't seen it mentioned in the manual.
If you know this problem, you can proceed accordingly. In this case, connecting only one compass sure that it does not stop sending data.
Another alternative, in order to have a redundant system with OpenCPN, is to write an intermediate script, which performs the function of monitoring, filtering and selection, returning the data to a TCP or UDP port, so that OpenCPN can read it.

At the moment in my ship I carry 2 GPS antennas (NMEA183) and Hut Moitesier of the RAspberry) and the two compasses (Flux Gate of Autopilot Raymarine IMU of the Hut Moitesier of Raspi). I plan to mount a second wind sensor (which will be ultrasonic). That's why I'm interested that these redundant systems work because I have planned for next year the crossing of the Atlantic.
That's why I've asked the developers if it's something I've only observed, if not if it can be corrected in the next update can be corrected and improved.

[Gypsylyon]

Originally Posted by Hakan

My view:
I can possible agree an active route would deactivate if no position is received. But to describe it OCPN causes a dangerous situation I do not agree:
If the route is deactivated the AP would go from Nav into Auto mode and keep follow the last course. It may sound a short alert though. But if you not notice that either there will be no difference if O stop sending nav-data.
OCPN is an aid for navigation and if you haven't noticed a GPS failure for an hour or so depending of your speed don't blame OCPN.

If you'd like more automated alerts the plugin Watchdog can offer a sound alert if no active NMEA-XXX for xx seconds or a Deadman alert if you haven't touched the screen for xx minutes. Unfortunately no alert if the PC hangs though. For that case an old fashion egg-clock may do.

Håkan (Hopefully not a grumpy impression. That's not my aim. I that case only bad English.)

Thank you for your comment. You can be sure that I do not interpret it as a bad grumpy answer.

Your proposal with Watchdog I have already applied it and it works to my complete satisfaction.

I understand that the developers want to make it clear that OpenCPN is an aid to navigation and that we should not consider it as a tool. Precisely to avoid responsibilities for possible failures of OpenCPN that may cause the use of OpenCPN in navigation.

For the record, I see OpenCPN as a great navigational aid. What I want with my contribution, is that OpenCPN improves and is more secure.

That does not change, that the failure to continue sending data to the Autopilot, when OpenCPN does not receive GPS data, if we are using OpenCPN as a navigation aid, if it can cause dangerous situations.
Independently that the captain of the ship is responsible and not OpenCPN, but imagine that we are sailing alone. We can't be awake 24 hours a day every day. You have to rest and sleep from time to time. If this malfunction occurs while sleeping, we will not be able to monitor possible malfunctions. This could cause a great deviation of the route. Or a motor boat that has much more speed.

I have already detected this fault in OpenCPN, what I'm looking for now are solutions. Thank you for your proposal with Watchdog, I have applied it and solve the problem at the moment. But it would be good if the developers corrected the problem. As soon as the Autopilot stops receiving data, the alarm goes off and it doesn't stop until I correct it manually, either by pressing Autopilot or by carrying the boat manually.

[Gypsylyon]

Originally Posted by Gypsylyon

Thank you very much for your comments.
Of course the duplication of inputs is a problem. In fact, I assume that openCpn has a filter mounted for these cases.
What I have observed is that, so say, once activated the filter is no longer deactivated when the situation has changed. In this case when the selected source stops sending data, OpenCPN does not look for an alternative source.
The reason I report this bug is that I haven't seen it mentioned in the manual.
If you know this problem, you can proceed accordingly. In this case, connecting only one compass sure that it does not stop sending data.
Another alternative, in order to have a redundant system with OpenCPN, is to write an intermediate script, which performs the function of monitoring, filtering and selection, returning the data to a TCP or UDP port, so that OpenCPN can read it.

At the moment in my ship I carry 2 GPS antennas (NMEA183) and Hut Moitesier of the RAspberry) and the two compasses (Flux Gate of Autopilot Raymarine IMU of the Hut Moitesier of Raspi). I plan to mount a second wind sensor (which will be ultrasonic). That's why I'm interested that these redundant systems work because I have planned for next year the crossing of the Atlantic.
That's why I've asked the developers if it's something I've only observed, if not if it can be corrected in the next update can be corrected and improved.

I'm sorry, the answer was for rgleason.

[Gypsylyon]

Originally Posted by rgleason

Gypsylyon,
I think you should make a new thread of your own for this, titled as you wish.
Just copy your original post to start it. (I know it is against the forum recommended practices, but this will be better. This will be a long thread I believe.)





Gypsylyon, I think you should try to simplify your setup if possible and test again.
1. For the backup GPS by setting priority, is there a way to setup two different GPS signals going to Opencpn more directly, and then test? This is necessary to isolate what may be wrong.
2. I don't have any ideas about the autopilot issue at the moment.



Can anyone else confirm these two potential bugs?

Thank you very much for your comments.
Of course the duplication of inputs is a problem. In fact, I assume that openCpn has a filter mounted for these cases.
What I have observed is that, so say, once activated the filter is no longer deactivated when the situation has changed. In this case when the selected source stops sending data, OpenCPN does not look for an alternative source.
The reason I report this bug is that I haven't seen it mentioned in the manual.
If you know this problem, you can proceed accordingly. In this case, connecting only one compass sure that it does not stop sending data.
Another alternative, in order to have a redundant system with OpenCPN, is to write an intermediate script, which performs the function of monitoring, filtering and selection, returning the data to a TCP or UDP port, so that OpenCPN can read it.

At the moment in my ship I carry 2 GPS antennas (NMEA183) and Hut Moitesier of the RAspberry) and the two compasses (Flux Gate of Autopilot Raymarine IMU of the Hut Moitesier of Raspi). I plan to mount a second wind sensor (which will be ultrasonic). That's why I'm interested that these redundant systems work because I have planned for next year the crossing of the Atlantic.
That's why I've asked the developers if it's something I've only observed, if not if it can be corrected in the next update can be corrected and improved.


Answering your questions, the bug is reproducible, as I commented in my post, I have tried at home with different entries and always repeats.
OpenCPN stays as hooked only to the data source it has prioritized. Although the device still sends data OpenCPN ignores them.

I have also tested it with the NMEA183 chromium simulator, in the same Rp4 that runs OpenCPN giving compas data together with Raspi3 with the Hut Moitesier via WiFi and via RS422 and always reproduces the problem.
Now I have another Rp4 but with 4GB (the other with 2GB) and I will do the tests again.

My autopilot is a Raymarine Typ 100 12V. The sentences are received via SeaTalk, because the electronics I have works via SeaTalk
The NMEA sentences generated by OpenCPN when Track is activated, are translated by the SeaTalk-NMEA183 duplex converter.
I don't use the NMEA1183 input of the autopilot, because I would have to install a new cable from the cockpit to the autopilot. It has been easier to use the converter. On the other hand all the SeaTalk bus information is converted to NMEA183 so that OpenCPN can visualize the data of wind, speed, depth, water temperature, GPS and rudder angle.

[bdbcat]

Gypsylyon...


This may be a legitimate bug.
If entered into Flyspray Bug Tracker, we can discuss there, and keep all the information for reference.


Thanks
Dave

[SeattleJew]

Err ahh

New to this forum.
I currently am using coastal explorer but Open Captain has been recommended because of I want to be able to interface radar with my nav SW.

Problem is, I can not find anyone who supports OC! So if I bet a radar and interface it, where do I go for support?

[Hakan]

Err well
About Open Captain I know nothing but strongly recommend OpenCPN being the best navigation aid for serious cruising. Beyond all other features it supports some radars, that's correct. See more for example here: http://www.cruisersforum.com/forums/...ml#post2857741
In general I recommend you to start here: https://opencpn.org/wiki/dokuwiki/do...pn_user_manual
Welcome to a society I find most generous and knowable.