OpenCPN Beta Version 3.1.1206 Released

[nohal]

Dave...
not echoing the sentences back to the input port was intentional when I originally wrote that code for two reasons:
1) Logically, that sentence was created there so whatever resides there already has the info needed.
2) I used a quickly hacked repeat-everything tool to test the code, so you can imagine what happened when the ping-pong game started...

I'm not actually sure at all I would like to repeat the sentences to the input port, but I'm sure under influence of 2...

Pavel

[bdbcat]

Pavel....

Considering point 1:
Ah, but some folks (like me) have a single comm port split, so that input comes from (say) a GPS, and output goes to (say) an autopilot. Saves an extra port, sometimes.... So, if the Autopilot can make use of anything in the input stream (e.g. Variation), then we might want to echo back out the same port.

We have another user in this thread with a similar situation, I think.
http://www.cruisersforum.com/forums/...ml#post1104163

And, considering point 2:
If you have a loopback connector (or active feedback device) installed on the port, you may instantly go critical and explode.....Nice stress test, though

I'm inclined to allow retransmit to the same port if enabled. Could use an output filter if needed....

Dave

[bdbcat]

plang732....

re:
http://www.cruisersforum.com/forums/...ml#post1104089

Regarding inability to see cm93 above 70N latitude: You should rebuild your chart database to enable cm93 coverage to 80N lat.

Thanks
Dave

[nohal]

Originally Posted by bdbcat

Pavel....

Considering point 1:
Ah, but some folks (like me) have a single comm port split, so that input comes from (say) a GPS, and output goes to (say) an autopilot. Saves an extra port, sometimes.... So, if the Autopilot can make use of anything in the input stream (e.g. Variation), then we might want to echo back out the same port.

And, considering point 2:
If you have a loopback connector (or active feedback device) installed on the port, you may instantly go critical and explode.....Nice stress test, though

I'm inclined to allow retransmit to the same port if enabled. Could use an output filter if needed....

Dave

I definitely have no problem with retransmitting the sentences back to the originating port - your I/O aggregation scenario where TX/RX wires lead to different devices is likely to be common.

And yes, explosion is a good term to describe what happens in case messages are fed back through a loopback

Pavel

[Viking Sailor]

Originally Posted by nohal

I definitely have no problem with retransmitting the sentences back to the originating port - your I/O aggregation scenario where TX/RX wires lead to different devices is likely to be common.

And yes, explosion is a good term to describe what happens in case messages are fed back through a loopback

Pavel

Dave,

How about using a unique "talker-ID" ($OCRMC...) for sentences generated (output) by OpenCPN. That way OpenCPN can ignore them on input. This will address the feedback problem.

Paul

[Hakan]

Dave, Nohal,...
I think I agree with the initial thoughts to filter out from navigation but let it be accessible for other use like outputs. Especially for this case where the two RMC sentences have different talker IDs and the filter can use more then three letters for rules. I didn't tried that. Thanks Nohal.
And.. if, for any other future situation, it's still a problem at least I have the possibility to tell the AIS to not broadcast GP... sentences, and that's probably a general AIS functionality.
And..(2). Two different generations of RMC, or other, sentences shouldn't be a problem? I mean even old equipment could or should be prepared for future changes and allow extra fields and if it looks for the check sum do it by locate the "*" instead of implying it to be in a destined field.
I havn't been able to test this case live since there is some 10 centimetres of ice surrounding my boat so navigation possibilities are somewhat restricted. But the Autopilot did at least accept to turn into NAV mode with the two RMC sentences coming in. Turning to and stand in NAV mode it only does when there is an accepted NMEA signal present.

Lots of words but not much said?? My first row is still valid, though.

[Gilletarom]

Hello Dave,

I am currently undertaking various tests to establish connections both input and output, as in "Series" in "Network" and a network that both TCP UDP.

In each case, you must remove the previous trials and possibly still completely redone.

This is not practical.

Is it possible to have a checkbox to activate or stop a connection already created?

A similar system exists in Polar Com. This is very convenient

B.R.

Gilletarom.

[Hakan]

Originally Posted by nohal

I definitely have no problem with retransmitting the sentences back to the originating port - your I/O aggregation scenario where TX/RX wires lead to different devices is likely to be common.

And yes, explosion is a good term to describe what happens in case messages are fed back through a loopback

Pavel

Dave, Nohal.. Yes to have different devices connected to TX/RX on one port is most common and for me it is the only way to get the signal to the Autopilot. (Without cable rearrangement and more USB converters)

[bdbcat]

Pavel, etc...

I think echo-back to the same port only makes sense for Serial type connections. I have been testing UDP broadcast send/receive, and we can get message flooding in this case as well, if we echo the UDP receive message right back out to a UDP broadcast port.

Sound right?

Dave

[Gilletarom]

Hello Dave,

USA ENC S57 :

Here a Beacon which is badly displayed.

B.R.

Gilletarom

[tom_BigSpeedy]

Hi there,

I'm compiling "master" on Win7, 64 bit, following the latest development.
Since about a week or so, I can't replay any more VDR files, which I recorded last summer ...
The VDR seems to run, the green bar is growing, but I have no display on my dashboard instruments nor any movement of ownship, nor AIS targets, etc.
It looks like it wouldn't run at all ...

Am I the only one, or am I doing something wrong ?

It still works with the official beta 3.1.1206

Thomas

[Gilletarom]

hello,

Originally Posted by Hakan

Dave, Nohal.. Yes to have different devices connected to TX/RX on one port is most common and for me it is the only way to get the signal to the Autopilot. (Without cable rearrangement and more USB converters)

Why not a checkbox for Input Yes/NO like the checkbox Output Yes/NO ?

and so the user can choice.

B.R.

Gilletarom.

[bdbcat]

tom_bigSpeedy...

VDR is broken on current master. Should be fixed maybe tonight. Watch for a bunch of new commits....

Thanks for playing
Dave

[bdbcat]

Gilletarom...

What's wrong with the Beacon display? Looks OK to me. What am I missing?

Dave

[Gilletarom]

Hello Dave,

Originally Posted by bdbcat

Gilletarom...

What's wrong with the Beacon display? Looks OK to me. What am I missing?

Dave

Hello,

1)
Is it normal that the topmark is a diamond black and white ? The data present do not said this ...

But perhaps I am wrong.

Is a the CATSPM (general warning mark) is diamond black and white ? I took a doubt. I have searched in the : IHO PUBLICATION S-52 APPENDIX 2
ADDENDUM TO ANNEX A, PART I, USERS´ MANUAL EDITION 3.4 (2008) PAPER.
But I did not find any information about CATSPM.

2)
The color of the beacon should be brown. It is true that it is a rare color.

B.R.

Gilletarom.