OpenCPN Beta Version 3.1.1206 Released

[Gilletarom]

Hello Dave,

It's been two days that I fencing to improve the translation into French of two item general language file.

This concerns the tab "Connection" from the "Toolbox".

1°
There is a small bug. The words "In" and "Out" are taken into account correctemlent if no filter is created. But if a filter is created, then these two item are not translated. See screenshot.

2°
For all filters, there are four cases:
- Input: NMEA sentences accepted
- Input: NMEA sentenses rejected
- Output: NMEA sentences sent
- Output: NMEA sentences unsent

To translate "Accepted", "Rejected", "sent" and "unsent", there are only two items "All but" and "Just".

I can translate "All but but" by "Tout mais" and "Just" by "Seulement". These translations are not adapted to the four cases in French. I've tried other translations ... this is even worse.

The various possible translations of these two items do not make clear the four situations.

Is it possible to have four items instead of two items?

Thank by advance.

Gilletarom.

[Gilletarom]

Hello Dave,

Not very important :

I have two connections.
With the first, the nmea sentences are received from GPS. This first connection is SERIAL with port com 5
With the second, the NMEA sentences are transmitted to an external user (Here NavMonPc for test) on port com 7

When I display the NMEA debugging window, I see that the sentences "out" are before the same NMEA sentences "in". This can disturb the users.

See screen copy

[Gilletarom]

Hello,

Tab connection of Toolbox :

Please excuse this question if it is absurd, but with no hardware furuno, I prefer to learn.

Two kinds of material are treated in a particular : Garmin and Furuno.

Why furuno item on the tab is visible in the two cases of serial and network connections while both Garmin items are only visible to serial connection only?

B.R.

Gilletarom.

[nohal]

Gilletarom...
In case of a Garmin, the whole serial protocol is different, but it has nothing to do with networking where the hardware is ethernet. In case of a Furuno, the NMEA sentences sent while uploading a route are different than usually, so it can be applied even in case they are transmitted over the network.

Pavel

[bdbcat]

cagney, etc...

I am seriously WiFi challenged this week, so I will try to keep up as best I can.

Thomas, I have no trouble with auto route creation on MOB. Works fine for me. Makes a route that is 1 NM along the last COG.

???
Dave

[sy_gilana]

Originally Posted by MQVirtual

Hello S/Y Gilana,

Encountered the same issue and spent hours trying to isolate, turned out, for us anyway, that OpenCPN was not the issue. SSD becoming corrupted was. For us removed SSD and reinstalled all software and lo and behold have had a stable system for over 6 months now, we reboot only after update Tuesdays.

ASUS G73jh
8GB RAM
Win 7 64
VMWare for OpenCPN but on host as well
Was a 256GB Kingston SSD

Hello and thank you for your input. Sorry I have been quiet, we have just arrived in the Canaries from Gibraltar. Once again I feel this is the incorrect thread to discuss crashes, however, I want to give some feedback, and ask for ideas. I sincerely hope its not the SSD as we have, over 14 years had many hard drives pack up completely due to gyroscopic precession causing head collisions. The SSD is the intended solution to that.

Attached is a reliability report, as can be seen, the day that OpenCPN was installed, I also installed the ATEN UC232A drivers. Since then the computer has been unstable. I thing OpenCPN is NOT at fault here, but I think its something to do with WIN7 and ATEN and MS BALLPOINT MOUSE.

Win7 recognizes the ATEN as a mouse. The computer crashed blue screen about 40 times in the last week at sea. It does so especially if O is running and any other mouse intensive activity like Solitaire.

If anybody has come across this please post, and I will not mention this crashing again as it is NOT an OpenCPN issue.

Thanks in advance...

[cagney]

Originally Posted by bdbcat

cagney, etc...

I am seriously WiFi challenged this week, so I will try to keep up as best I can.

Thomas, I have no trouble with auto route creation on MOB. Works fine for me. Makes a route that is 1 NM along the last COG.

???
Dave

Dave

Back to testing MOB, and it works!
My bad, I tested on the wrong assumption. I need to RTFM !!

Thomas

[sinbad7]

Since installing the latest v. 3.1.1206 I have not been able to receive/view AIS messages from my antenna. My SR162 receiver shows green light indicating data arrival but nothing is received in my USB port converter.
I have tried both port 6 and 10 which are the options and set the baud rate to 9600.

See attached settings..

Help anybody?

Tore

[Hakan]

Originally Posted by sinbad7

Since installing the latest v. 3.1.1206 I have not been able to receive/view AIS messages from my antenna. My SR162 receiver shows green light indicating data arrival but nothing is received in my USB port converter.
I have tried both port 6 and 10 which are the options and set the baud rate to 9600.

See attached settings..

Help anybody?

Tore

Tore. My AIS use 38400 and I think that's quite normal

[yachtman]

Originally Posted by sinbad7

Since installing the latest v. 3.1.1206 I have not been able to receive/view AIS messages from my antenna. My SR162 receiver shows green light indicating data arrival but nothing is received in my USB port converter.
I have tried both port 6 and 10 which are the options and set the baud rate to 9600.

See attached settings..

Help anybody?

Tore

isnt ais faster than 9600, but at 38400?

[nohal]

Tore...
As Hakan suggests, the baudrate for AIS is 38400 (even for your unit, as Smart Radio SR162 AIS Receiver confirms) If changing it does not help, please post the logfile from your last run.

Pavel

[bdbcat]

Hakan...

Regarding the errant GPRMC message...

You make a good point. The message is coming from COM16, and the filter is telling OpenCPN not to use that message for navigation. But the message is being echoed to the output port COM11 just the same.

So, the design question is: "If an input message is filtered by OCPN, should it automatically be removed from all output streams as well?"

Never thought about this possibility, myself....
Comments?

Dave

[sinbad7]

Hakan,Yachtman and Nohal..

Of course it is,38400,long time since I used my AIS,how could I forget??

BUT,right clicking only shows AIS target list and not each individual vessel.
Seems you now have to first go to the AIS target list,and then select Target Info.


Thank you all...

Tore

[nohal]

Dave...
my thinking is that we should let the sentences enter the internal MUX regardless of the input filters and remove them just from the output streams where such a filter is set, if we drop them on the base of the input filter already, part of the flexibility will be lost. The downside is that it might increase the confusion for a non-expert user in some cases of course, but at the other hand we will find something on any approach we take...

Pavel

Originally Posted by bdbcat

Hakan...

Regarding the errant GPRMC message...

You make a good point. The message is coming from COM16, and the filter is telling OpenCPN not to use that message for navigation. But the message is being echoed to the output port COM11 just the same.

So, the design question is: "If an input message is filtered by OCPN, should it automatically be removed from all output streams as well?"

Never thought about this possibility, myself....
Comments?

Dave

[bdbcat]

Pavel, Hakan...

I agree with your comment, Pavel. And that is just the way 3.1.1206 works now. (almost, see below).

So, Hakan, if you do not want the errant GPRMC message to be echoed, you need to use 5 character specification on the output filter, instead of 3 characters. The checkbox list only includes the standard 3 character sentence identifiers. But you can "Add" other 2, 3, or 5 character specifications to the list manually.

Maybe just "Include" ECRMB and ECRMC. This will send only the autopilot messages out, and them only when a route is active.

Dave

and the (almost) note above:

3.1.1206 will not echo a message received on (say) port COM1 back out to COM1. I think this is a bug.

        //Send to all the other outputs
        for (size_t i = 0; i < m_pdatastreams->Count(); i++)
        {
            DataStream* s = m_pdatastreams->Item(i);
            if ( port != s->GetPort() ) {
                if ( s->IsOk() )
                    if ( s->GetIoSelect() == DS_TYPE_INPUT_OUTPUT || s->GetIoSelect() == DS_TYPE_OUTPUT ) {
                        bool bout_filter = true;

note the line "if ( port != s->GetPort() )"
Thoughts, Pavel?