Beta Test / Technical

[Tehani]

Originally Posted by Hakan

I do agree to Pavel's posting.
Most APs read bearing to destination once when the accept button is pressed. Thereafter only cross tack error until coming to the end of the leg or reception of the messages ends. Then it switches to Auto. Some use RMB, some APB. Have been working for years.

Finally the new pilots are not limited to that. It was an important inconvenience.
Now they can replace the initial Bearing from waypoint to waypoint with the bearing from the current position of the ship. This allows you to resume navigation (after saving an obstacle, for example) without having to restart the route in the plotter. You already know that the old pilots do not optimize the route and take a big turn, reaching perpendicular navigation to get back on the initial line.
It is very likely that the calculation of the XTE is performed by the same autopilot based on the dynamic bearing from ship to destination waypoint, and therefore our XTE does not serve you too much ...

[nohal]

Tehani...

Let's try it this way: Do you have an example of any autopilot that is NOT working with OpenCPN provided data, while it is working with NMEA 0183 data provided by other products, we may study? That might perhaps be a better approach than first breaking the old ones that we do know need APB and then doing something I still fail to understand and could probably also lower the mutual reluctance to understand the arguments...

Pavel

[Tehani]

Originally Posted by nohal

Tehani...

Let's try it this way: Do you have an example of any autopilot that is NOT working with OpenCPN provided data, while it is working with NMEA 0183 data provided by other products, we may study? That might perhaps be a better approach than first breaking the old ones that we do know need APB and then doing something I still fail to understand and could probably also lower the mutual reluctance to understand the arguments...

Pavel

Not in NMEA0183 because RMB and XTE are sufficient.
I hope you understand my approach, what I want to say is that the user must be careful selecting the output sentences because there is a lot of data redundancy and useless communication time consumption.
I'm seeing that there are very experienced users here with the NMEA0183 theme, but they are not the majority of users.
My goal is to simplify things to the maximum for a "normal" sailor.
For example, my gateway does not intentionally process GSV, because I understand that it does not contain data relevant to navigation. The user does not have to configure. He does not know that this happens.
I also perform an automatic routing, seeing what data is sent by each connected device. This prevents loops, and I can switch to the GPS and / or secondary EC to secondary ones when there are timeouts or the data is not reliable.
That time in communications can be used to send or receive other more important data, or with more throughput (heading for example).

[Tehani]

Worse things happen inside Seatalk. They have several datagrams that say the same but with different resolution. A filtering should be done to choose the best data of each one.

In Seatalk yes I have to send in several formats because there are devices that only understand old datagrams.

I explore too the existence of STW in any bus. If not, i replace it with SOG information. Ray caltulates de True wind with STW exclusively. Many users do not like it.

[Tehani]

Originally Posted by nohal

Tehani...

Let's try it this way: Do you have an example of any autopilot that is NOT working with OpenCPN provided data, while it is working with NMEA 0183 data provided by other products, we may study? That might perhaps be a better approach than first breaking the old ones that we do know need APB and then doing something I still fail to understand and could probably also lower the mutual reluctance to understand the arguments...

Pavel

The problem is not unique when moving to N2k:
"No Navigation Data" reported when engaging Track mode - Garmin chartplotter - Printable Version
[CA] No Navigation Data message
Trouble with Sea Talking to Sea Talk Converter - Printable Version
And more...

[nohal]

Tehani...

I will try to ask again: To connect to each of the buses you talk about you need a gateway device, hardware, no way around it. This gateway device must translate the information to the protocol the bus uses and the devices on it understand. Somehow. How is not important for OpenCPN. More than that, all of it is already done - by you, Actisense, Brookhouse, Quark, Digital Yacht, and numerous others. So where is the problem you try to address now and here?

Pavel

[Tehani]

Originally Posted by nohal

Tehani...
How is not important for OpenCPN. More than that, all of it is already done -

Pavel

Do not think so. It is possible that the death of the old AP also killed O slowly. I wish I was wrong.
I think O must evolve. It is never good to look at the navel and conform (as it is said here).
And it's not good that it depends totally on others. I think we must also move in that direction because it is a strategic point for O. At least there should be a very close collaboration.

I will not intervene anymore. I do not want you to waste more time.

[nohal]

Originally Posted by Tehani

Do not think so. It is possible that the death of the old AP also killed O slowly. I wish I was wrong.
I think O must evolve. It is never good to look at the navel and conform (as it is said here).
And it's not good that it depends totally on others. I think we must also move in that direction because it is a strategic point for O. At least there should be a very close collaboration.

I do not understand this logic, sorry. What is depend totally on others here? Using the common protocols that are created by other entities? Or not producing own hardware? Or?
What exactly it is you propose? To work with you, develop "something" doing "something" and then hope that all the industry adopts it as a new standard?
The same industry that is mostly in the NMEA cartel and their business model is not to be interoperable and try to enforce vendor lock-in from the last physical connector and cable all the way to software components, with the more enlightened part moving in the SignalK direction (which is understandable as it is completely open, free, and has a very active community behind it) for the high level communication with clients like OpenCPN, which really have no real reason to talk to the bus directly to keep with their function?

Pavel

[Head Sail]

Really nice work on upcoming 5.0. I like the split screen option. I also like when I first installed and started up with my BU-353 puck, I got error messages that actually told me the commands to enter in /etc/udev/rules.d/70-opencpn.rules. Error messages with solutions are wonderful!. One issue is when using RNC, fathoms is shown on the map even though under setup "feet" is selected. Also, balloon help on tools bar would be helpful at first. Thanks for this great piece of sw!


Mark

[nohal]

Mark...

RNC are raster charts, if the picture contains depths in Fathoms, we tell you about it, there is no way we could modify the bitmap and magically change it to contain different information...


Pavel

[Head Sail]

Originally Posted by nohal

Mark...

RNC are raster charts, if the picture contains depths in Fathoms, we tell you about it, there is no way we could modify the bitmap and magically change it to contain different information...


Pavel

That's what I thought but under settings if could be labeled as ENC Chart Units.

[nohal]

Originally Posted by Head Sail

That's what I thought but under settings if could be labeled as RNC Chart Units.

No it couldn't as it is not what the setting is. It is "depth unit for everything where we have any influence on what is going to be shown".

[Head Sail]

An odd thing happening with the tool bar. If I click on the routing icon (third from top), no dialog comes up but the toolbar collapses. Also, if I make another window active (like Mozilla), the toolbar disappears. If I make Opencpn active, the toolbar reappears. Running 4.99.1508


Okay, I see why the toolbar disapears, it's to make room to draw a route.

[rgleason]

I ran across this old link about n2k ais which might be useful to someome. Perhaps tehani?
http://yachtelectronics.blogspot.com...mands.html?m=1

Also Jose there is a doitall multiplexer that includes signalk here, http://vyacht.net not to discourage your effort at all, but to broaden the discussion. Why would signalk help? Hot topic and it should all be on a different thread. Tehani would you please make a new thread for this discussion? Title it as you think appropriate.

[spithost]

I experiment some with the Android version, using the layers that I create and maintain for https://www.openwaterkaart.nl.
Somehow, I can't get the multi-line texts next to the objects visible.
The first line is visible, but the second and following are not.
As I created (among others) a layer with bridge-info for the inland waters of the Netherlands and only the name of the bridge and VHF-channel is in the first line and the width and hight of the bridge are is the following lines, the users are missing out ;-)
Is this something in the configuration I should change/adapt, or is this something more people experience, and could be a bug?
I have heard of one user having the same problem with the "larger" version of OpenCPN on Windows 10, but that is something I don't experience myself.