1. Your OpenGL config, as reported by log.
2. Lat/Lon of the location. I have no idea where "ksira lostaniah" is.
3. If there are black raster chart tiles in a cm93 quilt, please show some examples, with georef so that they can be reproduced.
If you bring detailed problem reports to this Forum, the problems get fixed. You may study the threads if you have doubts. Anecdotal reports of "it is broken" don't get much attention if we cannot reproduce the problem.
1. Your OpenGL config, as reported by log.
2. Lat/Lon of the location. I have no idea where "ksira lostaniah" is.
3. If there are black raster chart tiles in a cm93 quilt, please show some examples, with georef so that they can be reproduced.
If you bring detailed problem reports to this Forum, the problems get fixed. You may study the threads if you have doubts. Anecdotal reports of "it is broken" don't get much attention if we cannot reproduce the problem.
Thanks
Dave
Thank you, I will find out myself.
The missing lines does not depend on OpenGL.
Black raster charts happens when scale of the cm93 is far away from raster scale. It should only show the outlines of the raster in this case but not a black tile.
Hi,
I have been trying out the new S63 charts in 3.3.1931. The charts now seem to be working fine, however, I have had to stop using this beta as it keeps on loosing connection to my autopilot and windinstruments. Both of these are serial devices and I use Belkin USB to Serial converters. The PC is running Win 8.1 64 bit and is currently fully up to date. When I use 3.2.2 it is all OK, so it appears that the beta version does not handle windows serial ports well.
I have looked through this forum and found similar error messages that I get when I try and restart the serial port,
11:06:08 AM: Closing NMEA Datastream Serial:COM4
11:06:08 AM: Stopping Secondary Thread
11:06:18 AM: Not Stopped after 10 sec.
11:06:18 AM: Opening NMEA Datastream Serial:COM4
11:06:18 AM: Error, comm port open failure, INVALID_HANDLE_VALUE, Datastream skipped.
But this seems to be (?) related to bluetooth which I am not using. There is nothing in the log when the com port stops responding.
Sometimes after about 20mins of not working the beta version crashes (two crash reports have been sent today).
I have attached the current log file which mainly contains the information from running the beta, but it also contains log info from 3.2.2
I have been using 3.2.2 for the last few days with no COM Port issues. With 3.3.1931 I would loose at least one COM Port within about 1-15mins.
Here is a PDF of the COM ports I am using in OpenCPN.
COM6: AIS
COM3: Auto Pilot output and heading input from Auto Pilot
COM4: TackTick (now Raymarine) wireless windinstruments
NET: Output of AIS to send information to internet.
At the time of the errors "NET" was defined but not in use.
PS. I posted this message on the Beta/Technical discussion but I am not sure it is being closely monitored and Hubert suggested that this may have been a better place to post. Sorry about the duplicate.
... I have had to stop using this beta as it keeps on loosing connection to my autopilot and wind instruments
I think this merits an Opencpn Beta Tracker - Bug report. Would you mind registering for Tracker and make a new Task under Opencpn 3.3.x Beta "Bug Report" Titled something like Option Connections - Loss of and describing the details? OpenCPN::Tracker Register new user OpenCPN::Tracker 2 - OpenCPN 3.3.x. Beta: Tasklist
attach any files you want to.
Thank you.
... I have had to stop using this beta as it keeps on loosing connection to my autopilot and wind instruments
I think this merits an Opencpn Beta Tracker - Bug report. Would you mind registering for Tracker and make a new Task under Opencpn 3.3.x Beta "Bug Report" Titled something like Option Connections - Loss of and describing the details? OpenCPN::Tracker Register new user OpenCPN::Tracker 2 - OpenCPN 3.3.x. Beta: Tasklist
attach any files you want to.
Thank you.
I have created a Bug report for this
FS#1476 - COM Port Connections - Loses connection
FS#1478 - Options Display Accelerated Graphics Texture Compr with Cache - Rebuild Texture Cache - Fails and Opencpn crashes (On restart the rebuild picks up where it failed-apparently)
Using an Inspiron XPS 15 Laptop with on board Intel HD Graphics and an Nvidia Geforce 540m (which is the active and enabled board for Opencpn 3.3.2028, the version used for the test above).
With "Smooth pan and zoom" checked and with "Rebuild texture cache" successfully completed, zooming in and out is quite fast, also panning is fast and smooth. Detail charts for harbors seem to appear very quickly when zoomed to the right scale, over zoom to extreme causes all charts to cut out which I can understand why.
There are some detail charts such as ones going up the Connecticut River and ones following the Thames River, which do not seem to be showing up with their detail after several repeated zoom ins. Sometimes when I zoom to just the right scale and after a period of time, the first Thames River or CT River detail chart will show, then I can pan up the river and the other charts appear showing their detail. This seems to be the best way to get these charts to appear. I do not know what is causing this, perhaps these charts were made differently so it also causes a hiccup in the Texture Caching processing as well... hopefully we will learn more about this.
Anyway, for the most part these Opengl features and Texture Caching appear to be working quite well on an NVIDIA Geforce 540M (no longer a current board, as it is 3 years old)).
PS: My experience with my Intel HD Graphics Board enabled for Opencpn 3.3.2028 is not nearly as positive, probably because that board does not implement Opengl as well. I found not using Texture Cache was better when Intel HD Graphics was enabled for Opencpn.
With the latest version pulled from Git (12 UTC aprox.) panning and zooming of vector charts on the A20 ARM has gotten considerably faster. Now at the limit of being usable even without Mali support.
11:06:08 AM: Closing NMEA Datastream Serial:COM4
11:06:08 AM: Stopping Secondary Thread
11:06:18 AM: Not Stopped after 10 sec.
11:06:18 AM: Opening NMEA Datastream Serial:COM4
11:06:18 AM: Error, comm port open failure, INVALID_HANDLE_VALUE, Datastream skipped.
But this seems to be (?) related to bluetooth which I am not using. There is nothing in the log when the com port stops responding.
I can confirm this COM port problem with Win7, 64 bit professional.
I'm not using Bluetooth as well, but it doesn't happen that often, maybe once or twice in 8 h of sailing (O running unattendedly ).
Suddenly the com port is dead and only a reboot will help on my laptop.
I didn't report, as I couldn't figure out the reason why it fails.
And I have no "outbound" connection defined ! So I wasn't sure if it's my laptop, or O.
All I can say is that it started around 3.3.1606.
Could be related to AIS. Whenever the com port dies, AIS was on.
It didn't die with AIS off. But that could be a fluke as well ...
I don't think so. This affects the com port only.
Whereas this "AIS issue" caused full crashes.
O seems to work as normal, I can zoom in/out there's just no more
data coming in.
The com port is completely hung up.
Unplugging etc doesn't work. It's dead. Windows (!) sometimes closes it with errors, but without a specific error code.
Just a full reboot helps ...
I'm still not fully convinced that it is related to O, but if others report the same, we're getting closer ...
I'm not sure if this has been reported, but it looks like the fine zoom using the CTRL key is no longer working. Holding the CTRL key down and using the mouse wheel zooms the same amount as using the mouse wheel without holding down the CTRL key. Same issue if trying to use the + and - keys.