OpenCPN Beta Version 3.3.2330 Released

[bdbcat]

Happy...

Here's your problem:

[Settings/GlobalState]
VPRotation=359

Now, how did that get in there? Any ideas? I will investigate?

Should generally be zero, I think.

Thanks
Dave

[HappySeagull]

That's it! Fixed it. I don't know what would change it I think it's fairly new. This ini has been going for a few of the last few betas in a portable folder but I haven't futzed with it except adding the overzoom switch the other day. Til now, that is.

thinking back I had one or two crashes-one sent off to you ... panning and zooming and particular, adjusting fonts while looking for a setting of Depth Units and Overzoom display, Not sure if you got it.
Another more recent time before I noticed this tilt, O just shutdown and no crash report. I have been going a little gentler since but maybe I'll take up the wooden spoon again and make the poor thing howl until she does this again?

[P_Dub]

Dave
I have this one for me i Windows 7.
Regards

[Settings/GlobalState]
VPLatLon=" 46.8172, -71.1903"
VPScale=0.340348
VPRotation=0
OwnShipLatLon=" 46.8131, -71.1939"

[Mollymawk]

Happy...
Isn't this just the chart rotation feature in action?
Rotation left and right with [ and ], reset to vertical with \.

Maybe the rotation should be reset when closing/opening OCPN, rather than being stored in the config.
Caesar

[cagney]

Originally Posted by Mollymawk

Happy...
Isn't this just the chart rotation feature in action?
Rotation left and right with [ and ], reset to vertical with \.

Maybe the rotation should be reset when closing/opening OCPN, rather than being stored in the config.
Caesar

...another way is to tell the user, on screen, if the rotation != 0

Thomas

[mattkab]

Originally Posted by cagney

...another way is to tell the user, on screen, if the rotation != 0

Maybe add a slight blur to the chart?

[Hakan]

Originally Posted by nohal

Hakan...
This ........is a feature
................ I'm already inclined to change what the button does...

Pavel

AIS target persistent track:
Now it's even more a feature! The track is fine and a nice interactive button text as well. The info box will for sure also be appreciated.
Many thanks/
Håkan

[bdbcat]

mattkab...

"Maybe add a slight blur to the chart?"

Not funny. Not.

Grinning...
Dave

[leeward128]

Gentlemen:
I am about to retire my old Nobeltec VNS as soon as I can get the autopilot working with OpenCPN.

OpenCPN 3.3.2330 is almost ready to work with my Robertson AP200DL autopilot.

I analyzed my problem using a second computer running putty.exe to look at the actual data stream coming from the serial port on the computer running OpenCPN. Also used a scope to verify waveform sharpness and full RS232 voltage swing. Also replaced the opto-coupler in the Autopilot and verified its logic output with a scope just to make sure everything was perfect there and rechecked that the Autopilot was still working using my old Nobeltec VNS-4.

OpenCPN Options set as follows:
- Enabled autopilot output.
- Set to 4800 baud.
- Configured to output APB sentence.
- Configured to output Magnetic bearing data.
- APB bearing precision set to x.x

Output from Nobeltec: (works!)
$ECAPB,A,A,0.00,L,N,V,V,199.6,M,001,199.6,M,199.6,M*1C

Output from OpenCPN: (does not work!)
$ECAPB,A,A,0.000,L,N,V,V,199.6,M,001,199.6,M,199.6,M*2D

It appears the only remaining issue is that the cross track data also needs an option to set its precision to 2 decimal places which is precisely what is displayed in the active route display.

Thank you,

Lee

[NahanniV]

I know that ARM is not a supported platform yet, but:

Some change between the release of 3.3.2330 and today seems to have broken OpenGL support on ARM.

My post on the "OpenCPN runs on embedded ARM" thread:

Originally Posted by NahanniV

Rebuilt OpenCPN from the latest source today and it seems to have a problem with OpenGL.

The last version I made was just after 3.3.2330 was released. Raster charts with openGL were basically working with a few problems to be ironed out. CM93 charts Had a few more problems, but were sort of working.

Todays version always ends up with a black screen and sometimes hung whenever OpenGL is enabled.

The older version of OpenCPN was working just before I built the new one. I have not changed anything else I can think of.

?

[HappySeagull]

Originally Posted by Mollymawk

Happy...
Isn't this just the chart rotation feature in action?
Rotation left and right with [ and ], reset to vertical with \.

Maybe the rotation should be reset when closing/opening OCPN, rather than being stored in the config.
Caesar

Good man, Caesar. That's it."Ini " file goes to "VPRotation=359" when I return tilt to what should be 0.

....and that's a feature I vaguely remember and never, ever use. North is up . period. Unless for some reason I want course up (which is never)
Maybe keyboard shortcuts in general should not be persistent without a toolbar button or a toolbox setting.
[q] isn't persistent, for instance.

[rgleason]

I compiled Opencpn 3.3.2330 yesterday. Today I find out that
Options > Charts > Advanced > Graphics OpenGL is Grayed out.

I can no longer used Opengl on the NVIDIA graphics board.
Have I not done something?


Mollymawk

Rotation left and right with [ and ], reset to vertical with \.
= That's it."Ini " file goes to "VPRotation=359

- Why didn't I think of that?

[Mollymawk]

Originally Posted by cagney

...another way is to tell the user, on screen, if the rotation != 0

I think it's obvious that the chart is rotated... the problem is, if the user has accidentally pressed [ or ], how should they know how to get back to "normal", and that the rotation is a 'feature' and not a bug?
If we reset it to 0 when closing, at least a restart of OCPN would be a "clean slate" from this point of view.
I'm not sure what the intended use for arbitrary rotation is... would this interfere with it?

Originally Posted by HappySeagull

Good man, Caesar. That's it."Ini " file goes to "VPRotation=359" when I return tilt to what should be 0.

....and that's a feature I vaguely remember and never, ever use. North is up . period. Unless for some reason I want course up (which is never)
Maybe keyboard shortcuts in general should not be persistent without a toolbar button or a toolbox setting.
[q] isn't persistent, for instance.

Makes me think, O should probably not claim to be in "North Up" mode when the chart is rotated.

We need some brainstorming on the UI here.
At the moment O is always in either North Up or Course Up mode, yet clearly neither is appropriate in this case.

Caesar

[NahanniV]

Originally Posted by Mollymawk

I think it's obvious that the chart is rotated... the problem is, if the user has accidentally pressed [ or ], how should they know how to get back to "normal", and that the rotation is a 'feature' and not a bug?
If we reset it to 0 when closing, at least a restart of OCPN would be a "clean slate" from this point of view.
I'm not sure what the intended use for arbitrary rotation is... would this interfere with it?



Makes me think, O should probably not claim to be in "North Up" mode when the chart is rotated.

We need some brainstorming on the UI here.
At the moment O is always in either North Up or Course Up mode, yet clearly neither is appropriate in this case.

Caesar

I have been in this situation of rotated chart.

Being able to click on the compass to change modes is great.

Rotating the screen with the keys overrides course up mode.

How about making the compass symbol blink when not in north up mode, or at least another colour to differentiate rotated and draw attention to where you can click to change it.

Cheers,
JM.

[bdbcat]

NahanniV...

On the Arm...

If you can, please try to isolate the git commit that broke the arm build.

Thanks
Dave