OpenCPN Beta Version 3.1.1309 Released

[bdbcat]

Ahoy, OpenCPN'ers...

OpenCPN Version 3.1 Beta Build 1309 will soon be available for download from opencpn.org.

Monitor the opencpn.org Downloads page to find and download the latest Beta version binaries.....

Source is available now on github at:
https://github.com/OpenCPN/OpenCPN
Branch: beta31_stable

Changelog:
129. Correct error on consecutive fast serial port write() access.
130. Correct possible serial port read buffer overrun.
131. Correct generic SART target query report.
132. Remove package "libsdl1.2debian" as a dependency for sound.
133. Correct to allow for possible events from deleted datastreams
134. Add Priority change messages to NMEA Debug window
135. Correct Route/Waypoint upload port persistence
136. Set Ownship minumum size (mm) default to 1
137. Remove requirement of active GPS signal for routepoint GPS upload from context menu
138. Allow "Activate" of Routes and Routepoints in layers.
139. Correct Journeyman style pencil icon offset (FS#943)
140. Correct True heading timeout watchdog logic (FS#937)
141. Convert Garmin host mode and Furuno format upload to global options.
142. Correct Dashboard visibility logic persistence.
143. Correct AIVDO processing for invalid lat/lon (FS#935)(FS#936)
144. Improve AIS target query format for n/a fields (FS#934)
145. Correct Options->Charts add/delete/apply logic (FS#944)
146. Correct for build option USE_GARMINHOST=OFF (FS#931)
147. Correct for possible Windows ReadFile() error condition. (FS#947)
148. Correct Mac OSX bahavior on app activate/deactivate (FS#938)
149. Correct shared waypoint visibility selection logic (FS#942)
150. Language update
151. Major update to embedded Users Manual. Many thanks to Thomas (cagney)

Release Beta 3.1.1309


Notes

Getting very close to a Release Candidate. We need the final .po translation files now, as I expect no more changes to translatable strings, bar any obvious omissions.

Please take a good close look at the embedded Users Manual. cagney has done an outstanding job of pulling this together. This is by far the best documented Open Source program I have ever seen. What is truly amazing is that the documentation is current with the Beta. Fantastic!

Please check your Flyspray tasks, and close if satisfied.

Thanks, and Good Luck
Dave

[AISEAG]

Another version.

Thank to every one

[Gilletarom]

Hello Dave,

With 3.1.1309.
I have a GPS ND100 on the PC on the com 4. But, in the connexion tab, all my connexion are out of service.
Then normally, no NMEA sentences are in or out.
In addition, this GPS is not made to accommodate roads. It works like BU 353.

If I try to send a route, me two possibilities are left:
- On the Serial Port: com 4
- On the Serial Port: Garmin

With Series: Garmin, I receive an error message. What seems normal (?)
With Series: Com 4, everything seems to happen as if the road was sent and that all goes well.

I confess I do not understand what happens in the case of Series: Com 4?

B.R.
Gilletarom

[bdbcat]

Gilletarom...

Serial COM4 is apparently the USB adapter for the ND100.

NMEA provides no handshake protocol for Route and Waypoint upload. So, O simply sends the Route/WP information out on the port, without having any way to know if there is actually a device connected to the port.

However, the Garmin protocol does provide handshaking, and so O can be sure that the information is uploaded correctly. The Garmin protocol will fail if the device is not a Garmin.

So, in the case of standard NMEA, the indication "Route successfully uploaded" is not very meaningful. You can say that it just means that a port was found, and writing to that port succeeded.

In the case of "hockey puck" GPS receivers, they probably ignore Route and WP uploads, since there is nothing for them to do with this information anyway.

The key to remember is that Route and Waypoint upload process is completely independent of normal running Datastream operation. Two separate sub-systems.

So, I think all is working as expected, when uploading to a puck-type GPS.

Dave

[Gilletarom]

FS 944 :
2013-01-10: A task closure has been requested. Reason for request: After try, with 3.1.1309, it seem that the problem is solved. Gilletarom

[Gilletarom]

Originally Posted by bdbcat

Gilletarom...

Serial COM4 is apparently the USB adapter for the ND100

---> here YES

Originally Posted by bdbcat

.......
The key to remember is that Route and Waypoint upload process is completely independent of normal running Datastream operation. Two separate sub-systems.

Ok. But it can only seem strange.

The fact that two different structures coexist and operate without interfering with one another and vice versa certainly cause difficulties in understanding users who are not experts

Gilletarom.

[bdbcat]

Gilletarom...

I see your point. However, I hope that it "just works" for most users in an expected way.

By the way, it does no harm to assign the Datastream GPS port as an output and input device together. Some novice users might reasonably expect that this would be required for Route and W/P uploads. Most GPS receivers would ignore input sentences other than Route and W/P uploads anyway.

The correct Route and W/P uploads will still happen independently when user selected.

Possibly we need amplification in the User Manual....

Dave

[bdbcat]

Gilletarom....

As I think more....

The Garmin entry in the drop box appears if the system contains the Garmin USB device driver, even if no Garmin USB device is present. Happens only on Windows, as there is no Garmin USB driver for linux and Mac.

I should be able to test for the Garin USB device, and remove the Garmin entry from the drop box if there is actually no Garmin USB device installed. I think very few people are using Garmin USB connected devices anyway, and it can be confusing if the device is a Garmin serial device.

Is anyone actively using Garmin USB direct connected GPS receivers, i.e. without USB-Serial cable or other such interface? They seem not common in boats, since BU353 style pucks are so cheap.... I have a hockey puck style GPS18, which of course does not support or need uploads. Maybe the Garmin 172?

Dave

[Gilletarom]

Hello Dave,

Thank you for your posts # 4, # 6 and # 7. My question was probably a bit naive about the commande "Send to GPS", but nothing I could understand clearly.

Your posts, will help me develop better quality explanations on the command "Send to GPS" in the website that I try to maintain here in France on OpenCPN.

Let me say two things:
- What I proposed as useful adaptation or that I disagree with in the OpenCPN software, is only my personal opinion and I represent only myself. I should add that I try to respond to non expert thinking (I was one and in many ways, I'm still one).
- I also understand that nothing obliges you to consider my opinion. Either because you do not have time to move, either because you disagree.

I observe that you take into account some of my posts despite my rather poor English. And I thank you.

B.R. Gilletarom.

[Hakan]

Hello. (Dave.. as promised in another thread)

Test report for data communications using two serials and occasionally internal UDP broadcast.
The data send logic is erratic and filters are not working as expected. Data is sent out to ports not chosed for output. The filter rules seems to "leak" from one port to another. It's a bit complicated to describe in details especially in English but a bunch of screen shots can maybe do it. Please see attached printout.
I didn't succeed to receive data in the portable O but didn't care much for the moment. Hopefully the attached doc is clear enough. Otherwise shout and I try again. Thanks

[bdbcat]

Hakan....

That's a bug, all right.

The port name in the output sentences in the NMEA debug window is just wrong when there are multiple streams.. The actual data flow, however, is correct.

I'll commit a fix to github tonight.

Thanks for the good eye. This stuff is complicated to debug....

Dave

[Hakan]

Dave..
A pleasure to serve you as you serve us with the best.
I'll take a new test turn with the UDP internal broadcast next.

[Hakan]

Hello
Are there any considerable changes to "chartsymbols.xml" in this beta? I use to overwrite that file with the "Swedish style" chart symbols and I doubt it's also updated in that case. ( Wiki ref: "opencpn.org/ocpn/vector_palette")

[sailorF54]

Originally Posted by Hakan

Hello
Are there any considerable changes to "chartsymbols.xml" in this beta? I use to overwrite that file with the "Swedish style" chart symbols and I doubt it's also updated in that case. ( Wiki ref: "opencpn.org/ocpn/vector_palette")

I modified mine to the (French) SHOM style this morning, as I noticed that the date had changed from the previous beta...
(Applying this style means modifying 4 lines only)

Now it would be easier to keep track of changes if there was some kind of version number within the file...

[Hakan]

Originally Posted by sailorF54

I modified mine to the (French) SHOM style this

sailor..
Of course. As simple as that.
There where nine rows that didn't equals for the colour schemes between the original and the Swedish style. Easy copied. Thanks for the hint.
And to the Swedish style originator: Gôr bra! Känns som hemma med "rätt" färger.

/håkan