Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 21-01-2015, 07:20   #181
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,407
Re: OpenCPN Version 4.0 Released

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

__________________
rgleason is offline   Reply With Quote
Old 21-01-2015, 08:01   #182
Registered User

Join Date: Oct 2012
Location: Brighton, UK
Boat: Westerly Oceanlord
Posts: 374
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by rgleason View Post
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.

Quote:
Originally Posted by RhythmDoctor View Post
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.

Quote:
Originally Posted by RhythmDoctor View Post
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...
__________________

__________________
muttnik is offline   Reply With Quote
Old 21-01-2015, 11:27   #183
Registered User
 
NahanniV's Avatar

Join Date: Mar 2011
Location: On the Boat
Boat: Finnsailer 38
Posts: 1,144
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by bdbcat View Post
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:
Code:
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:
Code:
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.
__________________
NahanniV is offline   Reply With Quote
Old 21-01-2015, 12:58   #184
Senior Cruiser
 
Opie91's Avatar

Join Date: Apr 2009
Location: CT
Boat: C&C 34
Posts: 811
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by RhythmDoctor View Post
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 12W:
$GPHDG,231.50,,,12.00,E*03 (should be west, but it's east)

Set autopilot variation to 6W:
$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 12E (hoping it's just a negative sign issue):
$GPHDG,234.00,,,244.00,E*32 (yes, that's 244!!!)

Set autopilot variation to 1E (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.
__________________
Opie91 is offline   Reply With Quote
Old 21-01-2015, 14:20   #185
Registered User

Join Date: Jan 2011
Posts: 571
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by Opie91 View Post
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:

Quote:
Originally Posted by bdbcat View Post
The variation at Philly is -12, or 12W.
But the Options dialog clearly contradicts this:




__________________
RhythmDoctor is offline   Reply With Quote
Old 21-01-2015, 14:33   #186
Registered User

Join Date: Dec 2005
Location: WNA
Boat: Dufour 35
Posts: 3,249
Re: OpenCPN Version 4.0 Released

RD

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

Quote:
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
__________________
cagney is offline   Reply With Quote
Old 21-01-2015, 15:35   #187
Registered User

Join Date: Jan 2011
Posts: 571
Re: OpenCPN Version 4.0 Released

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:

Code:
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.
__________________
RhythmDoctor is offline   Reply With Quote
Old 21-01-2015, 17:24   #188
Registered User
 
Rik-lu's Avatar

Join Date: May 2010
Location: Luxembourg
Boat: HR40
Posts: 196
Images: 2
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by nohal View Post
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
Code:
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
__________________
Hi from Rik
Rik-lu is offline   Reply With Quote
Old 21-01-2015, 17:40   #189
Senior Cruiser
 
Opie91's Avatar

Join Date: Apr 2009
Location: CT
Boat: C&C 34
Posts: 811
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by RhythmDoctor View Post
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.
__________________
Opie91 is offline   Reply With Quote
Old 21-01-2015, 17:40   #190
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,019
Re: OpenCPN Version 4.0 Released

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
__________________
nohal is offline   Reply With Quote
Old 21-01-2015, 20:29   #191
Registered User

Join Date: Jan 2011
Posts: 571
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by Opie91 View Post
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.
__________________
RhythmDoctor is offline   Reply With Quote
Old 22-01-2015, 11:13   #192
Registered User

Join Date: Dec 2005
Location: WNA
Boat: Dufour 35
Posts: 3,249
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by Rik-lu View Post
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
__________________
cagney is offline   Reply With Quote
Old 22-01-2015, 12:46   #193
Registered User

Join Date: Nov 2014
Posts: 7
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by Rik-lu View Post
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.
__________________
ngux is offline   Reply With Quote
Old 23-01-2015, 00:43   #194
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 2,816
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by NahanniV View Post
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?
__________________
boat_alexandra is online now   Reply With Quote
Old 23-01-2015, 06:22   #195
Registered User
 
NahanniV's Avatar

Join Date: Mar 2011
Location: On the Boat
Boat: Finnsailer 38
Posts: 1,144
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by boat_alexandra View Post
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.
__________________

__________________
NahanniV is offline   Reply With Quote
Reply

Tags
enc, lease, opencpn

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenCPN Beta Version 3.1.814 Released bdbcat OpenCPN 185 14-09-2012 08:43
OpenCPN Beta Version 3.1.802 Released bdbcat OpenCPN 158 14-08-2012 11:07
OpenCPN Beta Version 3.1.714 Released bdbcat OpenCPN 91 01-08-2012 18:08



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 21:48.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.