OpenCPN Version 4.0 Released

[rgleason]

Muttnik, did find code here
https://github.com/vyacht/nmea/blob/...32Iso-v1.2.sch
you can register an account for free if you want.

[muttnik]

Originally Posted by rgleason

Muttnik, did find code here
https://github.com/vyacht/nmea/blob/...32Iso-v1.2.sch
you can register an account for free if you want.

I think those are the schematics for the hardware. I do have a github account (couldn't contribute to OpenCPN without it :-) but it was the location I think was the problem: I'm perusing the link RhythmDoctor just gave now.

Originally Posted by RhythmDoctor

All I know is that it's complicated, and that's why there are not a whole bunch of simple solutions for Seatalk where you can just hook up a serial-USB converter to listen to the thing.

I know, I've coded for it :-)

The "ninth bit" used to flag a command byte is easy enough for people doing bit banging with microcontrollers. It's also generally reflected in the parity bit of most UARTS (cribbed from Thomas Knauf's go-to document for seatalk)
All good if you have direct access to the parity bit. Trickier from Linux user space. You can, however, play Stupid Parity Tricks: you can set SPACE parity on your serial input. If a parity error is flagged, you know you've got a command byte. Depends however on your serial driver supporting space parity and also your serial-usb thingy correctly handling parity errors. A surprising number don't, including the startech one I was trying to use for development.

Reviewing Thomas Knauf's doc, seatalk variation is a single *signed* byte with positive values being west, negative east, so 0x01 is 1 degree west, 0xff is one degree east which is (I think) counter intuitive. I'm guessing what's happening is that in the conversion a signed byte is being treated as unsigned and positive values are being treated as east. So 1 degree west is 0x1, or +1 which is being converted to 1E. 1 degree east in the seatalk would be -1, or 0xff as a signed byte, which is +255 if treated as unsigned, or 255E. Thanks for the new code link: if I get a chance later I'll take a look to confirm.

Originally Posted by RhythmDoctor

Also this directory has a bunch of files whose names begin with "st" (Seatalk?). It's just a guess on my part, though.

I think "STM32" is a type of microcontroller but there's doubtless a lot of interesting stuff in there...

[NahanniV]

Originally Posted by bdbcat

NahanniV...

The CMake patch should be applied if you see the lines about GLES in the cmake output.

"Found OpenGLESv2" or "Found OpenGLESv1"

If you don't see those lines, then all is well.

Good Luck
Dave

Removing the opencpnUSE_GLES definitions broke OpenGL support on my ARM platform (A20 Debian Wheezy). It did not fix any problems that I had previously, plus the display was corrupted in many instances. Also texture compression caching was not available.

Log file after building with ADD_DEFINITIONS (-DopencpnUSE_GLES) commented out:

11:04:17 EST: OpenGL-> Renderer String: Mali-400 MP
11:04:17 EST: OpenGL-> Version reported:  1.4 glshim wrapper
11:04:17 EST: OpenGL-> Texture rectangle format: de1
11:04:17 EST: OpenGL-> glGenerateMipmap unavailable
11:04:17 EST: OpenGL-> Using Vertexbuffer Objects
11:04:17 EST: OpenGL-> Framebuffer Objects unavailable
11:04:17 EST: OpenGL-> Using Stencil buffer clipping
11:04:17 EST: OpenGL-> Using Scissor Clipping
11:04:17 EST: OpenGL-> No Useable compression format found
11:04:17 EST: OpenGL-> Not Using compression
11:04:17 EST: OpenGL-> Minimum cartographic line width:  1.0
11:04:17 EST: OpenGL-> Minimum symbol line width:  1.0

Normal Build:

12:47:56 EST: OpenGL-> Renderer String: Mali-400 MP
12:47:56 EST: OpenGL-> Version reported:  1.4 glshim wrapper
12:47:56 EST: OpenGL-> Texture rectangle format: de1
12:47:56 EST: OpenGL-> glGenerateMipmap unavailable
12:47:56 EST: OpenGL-> Using Vertexbuffer Objects
12:47:56 EST: OpenGL-> Framebuffer Objects unavailable
12:47:56 EST: OpenGL-> Using Stencil buffer clipping
12:47:56 EST: OpenGL-> Using Scissor Clipping
12:47:56 EST: OpenGL-> Using oes etc1 compression
12:47:56 EST: OpenGL-> Compressed tile size: 128kb (6:1)
12:47:56 EST: OpenGL-> Minimum cartographic line width:  1.0
12:47:56 EST: OpenGL-> Minimum symbol line width:  1.0

Whatever was being removed for WRONG needs to be more closely excised.

Cheers,
JM.

[Opie91]

Originally Posted by RhythmDoctor

I got to the boat tonight and was able to access the autopilot controls. It was set properly (12° W variation), but the NMEA feed definitely says 12° E. I am almost certain that the problem is NOT the Raymarine firmware. They're too careful to make a mistake like that. I believe it is the Seatalk-to-NMEA translation in the vYacht router that's generating the error. I'm going to contact the guy and ask for his assistance.

Here are some of my surprising findings:

Set autopilot variation to 12°W:
$GPHDG,231.50,,,12.00,E*03 (should be west, but it's east)

Set autopilot variation to 6°W:
$GPHDG,232.50,,,6.00,E*35 (should be west, but it's east)

Set autopilot variation to 0°:
$GPHDG,233.50,,,0.00,W*20 (looks OK, except it's not the correct variation for my area)

Set autopilot variation to 12°E (hoping it's just a negative sign issue):
$GPHDG,234.00,,,244.00,E*32 (yes, that's 244°!!!)

Set autopilot variation to 1°E (wondering if the error is linear):
$GPHDG,232.50,,,255.00,E*31 (yes, that's 255°!!!)

Here's my guess: I read somewhere that SeaTalk is difficult to translate because it uses a 9 bit word. That's why you can't just hook it up to a RS232 port and listen to the ASCII codes. The fact that this guy's translation table goes from 0 to 255 (for a 360° compass) indicates that he may not be seeing all 9 bits. Or, his calculation is just flawed.

I'm not a programmer, so I can't dive into his C code. If any of you are curious, you can find his firmware code here:

https://github.com/vyacht/nmea
vYacht Yacht automation

Obviously, no change to OpenCPN should be considered for this, because broadcasting incorrect GPHDG will only lead to problems with other programs. The fix needs to be at the root cause, which I believe (but have not proven) is in the vYacht router.

Rhythm Doctor,

I had some really weird things going on with a Brookhouse MUX and OpenCPN. Boiled down to I was taking stuff from Seatalk, translating it to NMEA 0183 via the Mux sending it to O. O was 2 way talking (NMEA0183) with a Garmin 740 which sent it back to the Mux via NMEA 0183.

I got all kinds of strange data including crazy heading information. What cured it was shutting off the output from O to the Garmin. I am sure it could have been filtered to solve the problem, but there was no real need for O to talk to the Garmin other than transfer of routes. When I wanted to do that the port output was turned back on for the transfer and then shut off again.

Maybe not your issue, just wanted to let you know.

[RhythmDoctor]

Originally Posted by Opie91

Rhythm Doctor,

I had some really weird things going on with a Brookhouse MUX and OpenCPN. Boiled down to I was taking stuff from Seatalk, translating it to NMEA 0183 via the Mux sending it to O. O was 2 way talking (NMEA0183) with a Garmin 740 which sent it back to the Mux via NMEA 0183.

I got all kinds of strange data including crazy heading information. What cured it was shutting off the output from O to the Garmin. I am sure it could have been filtered to solve the problem, but there was no real need for O to talk to the Garmin other than transfer of routes. When I wanted to do that the port output was turned back on for the transfer and then shut off again.

Maybe not your issue, just wanted to let you know.

Thanks for the warning - it is food for thought.

My Garmin GPS puck communicates one-way into O via a COM port. The wire going the other direction is not connected to anything at this time. In normal use, the computer's TX wire is connected to the autopilot's NMEA input terminals to send O's route information (BTW, DTW, SOG, etc.), but it is definitely disconnected right now. I will have to worry at some point about O looping the autopilot's Seatalk output back into its NMEA input terminals. But that's down the road, and I disconnected the wire to eliminate that complication for now.

The other similar issue is the possibility of a UDP multicast sending the router's data (TCP port 2947) back to the router on another port (UDP port 10110). I've disabled the UDP port to avoid that for now, but I'll have to look into that in the future, since I'd like to share the GPS/AIS data coming in via COM ports with other computer(s) on the boat - or other instances of O running on the same computer.

One thing that I would like Dave and team to consider is the overall issue of O taking magnetic variation from multiple (possibly conflicting) sources. If the GPS is putting out a value (12.1° W) that is more precise and reliable than the one I manually input into the autopilot (12° W, with no option for a decimal), then O should pick one over the other based on the priority settings (just like it currently does for GPS coordinates from two GPS sources). This is more nuanced than the GPS, because in that case O is ignoring the whole sentence from the lower priority source. Here I am suggesting just ignoring the redundant (and, in my case, incorrect) variation from $GPHDG, but using the remaining non-redundant data from the $GPHDG sentence.

Also, I think there needs to be some thought to the manually input "assumed magnetic variation." Should this override the values that come in from the NMEA stream, or should it only be used if there is no NMEA stream available? (I think it should be the latter.)

Finally, Dave and Pavel should note that there appears to be an error in the dialog text for assumed magnetic variation. I think conventional notation is to write 12W as -12, as Dave mentions here:

Originally Posted by bdbcat

The variation at Philly is -12, or 12W.

But the Options dialog clearly contradicts this:

[cagney]

RD

I agree about the magnetic variation. That's why I had to write

Assumed Magnetic variation.
This value will be used if variation is not available through the GPS or the WMM plugin.
The default value is 0°. As usual, positive values are also called "easterly variation" , and negative values are also described as "westerly variation".
(+W,-E) this is just a reminder that the program will reverse the signs you entered, as a conversion from "true" to "magnetic" course takes place

in the documentation.

Thomas

[RhythmDoctor]

I am glad the documentation is correct. I still think that the dialog is misleading. Ideally it should be clear without referring to the documentation. Just my opinion, FWIW.

Speaking of confusing negative signs, I found this in the Thomas Knauf documents:

Com Att Dat Dat... 
 99  00  XX        Compass variation sent by ST40 compass instrument 
                     or ST1000, ST2000, ST4000+, E-80 every 10 seconds 
                     but only if the variation is set on the instrument 
                     Positive XX values: Variation West, Negative XX values: Variation East 
                     Examples (XX => variation): 00 => 0, 01 => -1 west, 02 => -2 west ... 
                                                 FF => +1 east, FE => +2 east ... 
                   Corresponding NMEA sentences: RMC, HDG

I think it is interesting that a POSITIVE number in Seatalk (such as 01) results in an NEGATIVE correction (-1 west), yet a value of FF results in a +1 east correction.

[Rik-lu]

Originally Posted by nohal

No downgrading, the only way is forward
Just today I found a bit of time to add the supplementary utilities (libbsb, imgkap and mc2bsbh) into the OpenCPN PPA.
So to get it, just do

sudo apt-get update
sudo apt-get install libbsb

Or install it from the Software Center.

Pavel

I am to dumb to understand this Pavel ....
hope this will be included in version 4.01 for windows?
I would like to see this patagoniacharts in the new version too.
thx in advance
Rik

[Opie91]

Originally Posted by RhythmDoctor

Thanks for the warning - it is food for thought...........



But the Options dialog clearly contradicts this:

Why manually enter the variation? Do you have the WMM plug in? It figures out the variation automatically (at least it seems to) when you check the box.

[nohal]

Rik...
You can get the Windows version of the utilities from Download libbsb - read/write/convert BSB images from SourceForge.net

These charts are broken, it is better to fix them...

Pavel

[RhythmDoctor]

Originally Posted by Opie91

Why manually enter the variation? Do you have the WMM plug in? It figures out the variation automatically (at least it seems to) when you check the box.

I had manually entered the variation in many months ago, but don't use it (hence the unchecked box).

Now I realize that I have variation coming in once every second from the GPS on $GPRMC and once every second from the autopilot on $GPHDG (incorrect, but will be fixed). So with all that information on variation coming in, I don't think I need WMM plugin.

[cagney]

Originally Posted by Rik-lu

I am to dumb to understand this Pavel ....
hope this will be included in version 4.01 for windows?
I would like to see this patagoniacharts in the new version too.
thx in advance
Rik

The chart that needed a dosage of "bsbfix" to work, was broken an no OpenCPN version will display it correctly.
Charts having "GD=" are also broken, but in line with other charts with similar errors the should be shown, using "GD=WGS84" with a warning.
Take the warning seriously, there are charts out there in cyberspace with large errors - like 2 M.
Any chart with "GD=" , "GD=UNKNOWN" or similar garbage should really be properly fixed by finding the geodetic datum used for the chart.
Similar arguments apply to charts were no projection is stated.
Go through your charts before setting off sailing. Check what the opencpn.log says about the charts. Read the
Chart Conversion Manual | Official OpenCPN Homepage, to learn more about bsb charts and how to fix them. This is the price we pay for using old charts that have not been properly converted from chart-picture to a raster-chart.

Thomas

[ngux]

Originally Posted by Rik-lu

I am to dumb to understand this Pavel ....
hope this will be included in version 4.01 for windows?
I would like to see this patagoniacharts in the new version too.
thx in advance
Rik

If you talk about "my" Patagonian Charts, they are all fixed with bsbfix. You should not have problems for displaying them.

[seandepagnier]

Originally Posted by NahanniV

Removing the opencpnUSE_GLES definitions broke OpenGL support on my ARM platform (A20 Debian Wheezy). It did not fix any problems that I had previously, plus the display was corrupted in many instances. Also texture compression caching was not available.

Yes, well the two possibilities are using opengles which should always accelerated if supported and opengl which may not be accelerated and usually isn't on arm. Before, by default it would attempt to use opengles on arm platforms if available which is maybe not complex enough logic.

I would like to know about the case using opengles doesn't work on arm and why it was disabled. Is glshim built and used? Why would you want to use software rendering when hardware acceleration is available? What is the problem and how can we fix it? If we can't fix it, how can we detect systems that can't handle hardware acceleration in the cmake file?

[NahanniV]

Originally Posted by boat_alexandra

Yes, well the two possibilities are using opengles which should always accelerated if supported and opengl which may not be accelerated and usually isn't on arm. Before, by default it would attempt to use opengles on arm platforms if available which is maybe not complex enough logic.

I would like to know about the case using opengles doesn't work on arm and why it was disabled. Is glshim built and used? Why would you want to use software rendering when hardware acceleration is available? What is the problem and how can we fix it? If we can't fix it, how can we detect systems that can't handle hardware acceleration in the cmake file?

In my case both OpenGL and OpenGLESv2 are found.

WRONG and BDCAT found some problem that was resolved by disabling opencpnUSE_GLES. BDCAT suggested it be disabled, so I tried it, but it obviously broke OpenGL support.

Perhaps a naive question, but would it be possible to detect this stuff at runtime ?

Cheers,
JM.

P.S. I tried this change in the hopes that it might resolve a problem with CM93 charts on ARM with OpenGL (see messages from GHAMMOND on ARM thread) . It happens on all the systems I have tried, where other problems seem to be system dependent.