Beta Test / Technical

[AedanC]

It’s !AIVDO. AIS message are prefixed with ! Rather than $.

[yachtvalhalla]

Originally Posted by AedanC

It’s !AIVDO. AIS message are prefixed with ! Rather than $.

Thanks for the correction. My bad.
Terry

[Tehani]

Originally Posted by Tehani

Well, if tactics has no influence on that RMB field, I think it's better to leave it empty.

Sorry, I meant APB, not RMB.

I was already tired.

[rgleason]

Tehani,


Tactics_pi is structured and very similar codewise to Dashboard, which does not create Nmea0183 sentences. It just uses the data available and calculates and displays. Therefore I believe it does not create RMB, it uses similar data however for its calculations and display.



It would be possible to have tactics create it but that might result in conflicts. ---><---


These statements should be checked and verified, or confirmed.

Originally Posted by Tehani

Sorry, I meant APB, not RMB.

I was already tired.

[rgleason]

Dashboard Plugin Nmea0183 Recognized sentences.

Ok, that is all very helpful. Summary of changes to make.

What should I prefix the other sentences with?
And should I show those prefixes?
Or just make a statement that "AIS is prefixed with! and the others with $" ?
Tehani

In ZDA, It can be clearer like this:
5 - Local zone description, 00 to + - 13 hours (- means East longitude)
6 - Local zone minutes description, 00 to +-59 (- means East longitude)

Tehani

RMC in a sentence created only by the GPS (Or position system) based on the data received only by the receiver. There is no waypoint or route information. COG and SOG should appear here.
RMB in a navigation sentence that combines GPS information with the coordinates of the Waypoint. The data it contains are the result of these calculations on the line that joins the position of the ship and the Waypoint. VMG is the right thing to do. VMG = SOG * cos (COG - BRG). It does not make sense to put the SOG in its place.

Hakan

TTM and TLL are sent by the Radar (ARPA / MARPA), not by AIS
Correct, but all code are in the AIS_Decoder and ARPA targets are handled in the same way as an AIS target so the position of the descriptions are in the right place.
AIVDO wouldn't be listed as a Dashboard message.

Ok, aivdo is an OpenCPN supported sentence, will move up.

Aedan

It’s !AIVDO. AIS message are prefixed with ! Rather than $.

[rgleason]

Originally Posted by rgleason

Dashboard Plugin Nmea0183 Recognized sentences.

Ok changes made. Please check what I did is ok. Made a general statement about prefixes at the top. Thank you all.

[Tehani]

Forgive my insistence with the ruling APB. I'm trying to find the light at the end of the tunnel ...

Textual definition of NMEA:
APB - Heading / Track Controller (Autopilot) Sentence "B"
Commonly used by autopilots, this sentence contains navigation receiver warning status flag, cross-trackerror, waypoint arrival status, initial bearing from origin waypoint to the destination, continuous bearing from the position to destination and destination heading-to-steer to destination waypoint for the activate navigation leg of the journey.

Surely I have problems with the nuances of the language, I am not english native, but
this is what I understand when following a route formed by several waypoints:
1- "Initial bearing from origin waypoint to the destination": Angle from the initial position of the trip to the last point of the route, or destination point. I understand that it is the final objective of the trip. (Field 8 of the sentence).
2- "continuous bearing from present position to destination": Angle from the current position of the ship to the last point of the route, or destination point. I understand that it is the final objective of the trip. (Field 10 of the sentence).
3- "heading-to-steer to destination waypoint for the active navigation leg of the journey": Recommended route to the active waypoint of the route.
(Notice that there is a subtle difference between "destination" without more and "destination waypoint" ...)

I am doing simulations by injecting a log to OCPN with GPS data exclusively during a trip, and I have O generate the XTE, RMB and APB sentences to follow a 3-point route. (initial, intermediate and final).
My opinion is that the results do not match the definition of NMEA:
For point 1 (Field 8), O inserts the Bearing from the initial point to the intermediate point, which is the intermediate waypoint, not to the final destination.
For point 2 (Field 10), OCPN inserts the Bearing from the current position of the ship to the intermediate point, not to the final destination.
Point 3 (Field 12). This is subject to the interpretations that I mentioned earlier in the thread. The Bearing can be placed up to the active intermediate point with or without correction by the current (It is a recommendation data).

When the route consists of only two points (origin and destination), the data matches those sent by O.

In short, seeing that this definition of the NMEA seems to be the result of a night of drunkenness on the bridge of a merchant, I think it is safer not to use APB in our navigation. It does not provide anything useful that already contains RMB, and its data is confusing as we have seen.
I recommend that O have no option to be sent or processed. I guarantee that it does not work, I have previously sailed only with XTE and RMB guiding the pilot many miles without any problem.

On the other hand, I think there is a very relevant data that HSC delivers. That's the course the autopilot is really following when in AUTO / TRACK / WIND or NO DRIFT mode. This statement is not processed by O, but the Seatalk Pilot plugin with its equivalent datagram. Obviously in magnetic, it's about Ray ...

[Tehani]

BOD - Bearing - Origin to Destination
Bearing angle of the line, calculated at the origin waypoint, extending to the destination waypoint from the
origin waypoint for the active navigation leg of the journey.

It is in tune with the twisted handling of the language that NMEA does in APB.

I believe that the content of this sentence should coincide with field 11 of RMB. It is logical that OCPN does not use it, since it is irrelevant if it already sends RMB, which is more common and recommended.

[nohal]

Tehani...

I'm missing one important piece of information: What are we going to do with all the autopilots that do not work at all if the APB sentence is not what they receive? Should we tell everybody to replace them (remember they worked just fine for their owners until you came with this brilliant idea and we implemented it) with something less broken?

Pavel

[Tehani]

Originally Posted by nohal

Tehani...

I'm missing one important piece of information: What are we going to do with all the autopilots that do not work at all if the APB sentence is not what they receive? Should we tell everybody to replace them (remember they worked just fine for their owners until you came with this brilliant idea and we implemented it) with something less broken?

Pavel

There is no need to answer with these manners.
If you know, tell me what pilots are. I am also going to look for documentation. As you can see, I am at least as interested as you are.
I want to find a solution for this because I also manufacture devices that handle this information.
So far I had done it that way, but I've noticed that some pilots in N2k (specifically Ray) are having problems of incompatibility with N2k plotters that are not theirs, nor do they work in TRACK mode when only XTE, RMB and APB are translated to N2k. I think they lack more route data to work in that mode and, it can also be some stupid PGN of identification. I am completing N2k documentation on those pilots.

We must go to the future even if we do not like it too much. You just have to find the way those old pilots work too. I am already identifying each pilot in their native network, and then, I speak their language. That can not be done O.

[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.

[nohal]

Tehani...

Yes, we must go to the future. That future is not NMEA 0183. And that future is not perfect, there is nothing you can do about the existence of APs that work in a way you personally consider broken, neither can we. We have found the way the old pilots work, long time ago, and that is why we send them what we do send them, now. Same we will do for APs that work differently.

So maybe start with a simple explanation of what you are trying to achieve here and what exactly does it have to do with OpenCPN, in a way even I could understand if possible, please.

Pavel

[rgleason]

I think we need to consider the schema the person is working in. It is a good question to ask - What will happen to autopilots without APB sentence? It will also break a couple of autopilot plugins, but probably not Sean's because he has several options! I am sure Tehani has figured this out already. I think he's trying to optimize the OpenCPN communications line first.

We need to keep in mind Tehani is looking at the big communication picture here. My impression is that he is quite well versed in this and I have learned quite a lot about Opencpn through his discussion. He already has some interesting devices that do a great deal, Ocenav and is considering how to solve these problems for Opencpn users in a reasonable way (without total rewrite) using Opencpn's Fast Nmea0183!

Right now I think he is trying to optimize the flow of data to and from O to improve upon O's new fast nmea0183 so that it does not get bogged down. Perhaps he is thinking about a form of universal communication that will ultimately solve these problems.

I am very open to his "out of the box thinking" and hardware - software based solution! Perhaps as he thinks of it "Olink" - Opencpn, fast nmea0183 optimized, UART Hub + computer, N2k, Seatalk, Canbus, wifi, maybe with some limited added engine data too. Designed to connect O to the world, simple and cost effective. Possibly using u-blox, uart, rpi.

It is a great deal to figure out, so I hope everyone will help him as much as possible.

So perhaps my imperfect explanation will help with Pavel's request?

So in short, maybe he is considering reconstituting APB on the other side of the Hub so old autopilots will work?
So maybe start with a simple explanation of what you are trying to achieve here and what exactly does it have to do with OpenCPN, in a way even I could understand if possible, please.

Originally Posted by nohal

Tehani...

Yes, we must go to the future. That future is not NMEA 0183. And that future is not perfect, there is nothing you can do about the existence of APs that work in a way you personally consider broken, neither can we. We have found the way the old pilots work, long time ago, and that is why we send them what we do send them, now. Same we will do for APs that work differently.

So maybe start with a simple explanation of what you are trying to achieve here and what exactly does it have to do with OpenCPN, in a way even I could understand if possible, please.

Pavel

[stevead]

The continuing saga compiling the TwoCan plugin under Linux.

OS:Linux raspberrypi 4.19.25-v7+ #1205 SMP Mon Feb 25 18:19:20 GMT 2019 armv7l GNU/Linux

Compiler:g++ (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516
wxWidgets: Version 3.0.4, Config:gtk2-unicode-3.0

Following Error linking the plugin.

/usr/bin/ld: /usr/local/lib/libwx_baseu-3.0.a(baselib_threadinfo.o)(.text+0x4a0): R_ARM_TLS_LE32 relocation not permitted in shared object
/usr/local/lib/libwx_baseu-3.0.a(baselib_threadinfo.o): In function `wxThreadSpecificInfo::ThreadCleanUp()':
threadinfo.cpp:(.text+0x4a0): dangerous relocation: unsupported relocation
/usr/bin/ld: /usr/local/lib/libwx_baseu-3.0.a(baselib_threadinfo.o)(.text+0x90c): R_ARM_TLS_LE32 relocation not permitted in shared object
/usr/local/lib/libwx_baseu-3.0.a(baselib_threadinfo.o): In function `wxThreadSpecificInfo::Get()':
threadinfo.cpp:(.text+0x90c): dangerous relocation: unsupported relocation
collect2: error: ld returned 1 exit status
CMakeFiles/twocan_pi.dir/build.make:259: recipe for target 'libtwocan_pi.so' failed
make[2]: *** [libtwocan_pi.so] Error 1
CMakeFiles/Makefile2:131: recipe for target 'CMakeFiles/twocan_pi.dir/all' failed
make[1]: *** [CMakeFiles/twocan_pi.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

Seems like a wxWidgets lib is statically linked ?
Thoughts and possible solutions ?

[nohal]

Originally Posted by stevead

The continuing saga compiling the TwoCan plugin under Linux.

OS:Linux raspberrypi 4.19.25-v7+ #1205 SMP Mon Feb 25 18:19:20 GMT 2019 armv7l GNU/Linux

Compiler:g++ (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516
wxWidgets: Version 3.0.4, Config:gtk2-unicode-3.0

Following Error linking the plugin.

/usr/bin/ld: /usr/local/lib/libwx_baseu-3.0.a(baselib_threadinfo.o)(.text+0x4a0): R_ARM_TLS_LE32 relocation not permitted in shared object
/usr/local/lib/libwx_baseu-3.0.a(baselib_threadinfo.o): In function `wxThreadSpecificInfo::ThreadCleanUp()':
threadinfo.cpp:(.text+0x4a0): dangerous relocation: unsupported relocation
/usr/bin/ld: /usr/local/lib/libwx_baseu-3.0.a(baselib_threadinfo.o)(.text+0x90c): R_ARM_TLS_LE32 relocation not permitted in shared object
/usr/local/lib/libwx_baseu-3.0.a(baselib_threadinfo.o): In function `wxThreadSpecificInfo::Get()':
threadinfo.cpp:(.text+0x90c): dangerous relocation: unsupported relocation
collect2: error: ld returned 1 exit status
CMakeFiles/twocan_pi.dir/build.make:259: recipe for target 'libtwocan_pi.so' failed
make[2]: *** [libtwocan_pi.so] Error 1
CMakeFiles/Makefile2:131: recipe for target 'CMakeFiles/twocan_pi.dir/all' failed
make[1]: *** [CMakeFiles/twocan_pi.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

Seems like a wxWidgets lib is statically linked ?
Thoughts and possible solutions ?

The obvious one: Do not use your local build of wxWidgets, but the normal packages delivered with the OS.
The more complicated one: Build shared wxWidgets (I never had reason to do that on Linux, but probably you can simply do the same as on macOS)

In any case, get rid of those statically linked WX libs in /usr/local.

If you do have correct wx shared libs somewhere else on your system, you may sure have a look at https://github.com/OpenCPN/OpenCPN/b...i_build.sh#L13 as last option.

Pavel