Dashboard - Mag Heading

[rgleason]

This seems pretty rational to me, but being a physics guy, I've always thought of Cog/Sog and Hdg/Stw as vectors and I still think they should be shown that way, because all other forces on the boat should be shown this way too, current, wind etc.

[transmitterdan]

Rick,

I cannot say what is happening exactly from the VDR file. You must have more than one GPS device sending NMEA messages. I see GLL messages and RMC messages. Sometimes the GLL messages have bogus position but other times they are just slightly different than the RMC positions. So OpenCPN tries to use both position reports as they come in and thus the track is very jagged. The bogus GLL messages have positions that are 26 degrees north of the expected track. They have a valid checksum so I am not sure how they came to be. Perhaps you have checksums turned off on some instruments feeding the chartplotter so it accepts these bogus values and then repeats them with a correct checksum and OpenCPN then believes they are valid. I just can't say for sure what is going on. But the configuration seems pretty complex and hard to diagnose.

I don't see any data from the Seatalk side such as wind speed, knot log or wind direction.

Edit: I do see Seatalk data but it seems very "noisy". The wind direction varies wildly from side to side.

[rgleason]

Originally Posted by transmitterdan

Rick,

I cannot say what is happening exactly from the VDR file. You must have more than one GPS device sending NMEA messages. I see GLL messages and RMC messages. Sometimes the GLL messages have bogus position but other times they are just slightly different than the RMC positions. So OpenCPN tries to use both position reports as they come in and thus the track is very jagged.

Yes, I noticed it was jagged. Except for the first day, in the beginning, when I had the Bu353 attached, we are only using one GPS source, the B&G.

I think it is being re-sent a second time by either the Raymarine ST/STNS converter NMEA2000 or by the gadgetpoole ST Link. I will have to turn off the B&G and use the USB hub + Bu353 GPS puck + gadgetpoole ST Link for the instruments and save a VDR file that way to see what happens, that is a simple setup, all for OpenCPN.

Then I am going to have to isolate the extraneous GPS sentence.
Is there a particular GPS sentence that I should be filtering out using the OpenCPN connection tools? (I know that is not the proper way to do it, but it might be one step to take, then I have to try to figure out where it is coming from.

The bogus GLL messages have positions that are 26 degrees north of the expected track. They have a valid checksum so I am not sure how they came to be. Perhaps you have checksums turned off on some instruments feeding the chartplotter so it accepts these bogus values and then repeats them with a correct checksum and OpenCPN then believes they are valid. I just can't say for sure what is going on. But the configuration seems pretty complex and hard to diagnose.

I can control the gadgetpoole ST Link and filter out sentences, but I cannot control the Raymarine ST/STNG Converter.

I have a wiring diagram for the system. I will attach it, perhaps that will help.

I don't see any data from the Seatalk side such as wind speed, knot log or wind direction.

Edit: I do see Seatalk data but it seems very "noisy". The wind direction varies wildly from side to side.

Yes that is correct, the wind direction was very light and we were motoring all the way, almost all 3 days.

I will check this all out. Thanks Rick

[transmitterdan]

Rick,

You can filter GLL messages out using the connections setup

[rgleason]

I have tried running VDRplayer with the nmea0183 file while using NmeaConverter and don't know how to set NmeaConverter up to filter the GLL sentences.

I have edited several entries from NmeaConverter Preferences
including

$ ,$IIGLL

and

,$IIGLL

Then I disabled NmeaConverter and tried using the filter in the Nmea Debug Window and tried entering $IIGLL , then $GLL, then GLL
it seems to slow the scrolling down but does not change what is in the debug window. The boat track remains erratic.

NOTE I have unchecked all connections in the connections window and
the VDRplayer simply sends the nmea data to OpenCPN via some back communication, and the boat moves its erratic course, but there seems to be no way to actually filter it directly. Is there some Options > Connections "Connection" that would be a "VDRplayer" connection that I could make so that I could filter the input or the output?

Is there a way to read the file, apply the $IIGLL filter, then use the other side of VDR "record" to save it as a cleaned up file that I could see weather it is any better as a recording?

What is the technique I should use to filter the nmea debug window? Some special format?

Am I missing something about applying a filter to a file being played by VDRplayer?

I don't believe the manual has any examples of this.

I've attached the nmea0183 recording (which is the one I sent you earlier, via email, TDan) and a screenshot.

Any suggestions on how to filter the GLL or $IIGLL sentences while playing VDRplayer with the cutty2watchhill.txt file?
1. Using nmeaConverter.
2. Using Nmea Debug filter.
3. Using the OpenCPN Options > Connections "Connections" and applying a filter?

http://www.cruisersforum.com/forums/f134/dashboard-mag-heading-189218.html#post2463185


I think I need to clarify this in the manual for Connections and NmeaConverter, too.



Thanks,
Rick

[rgleason]

OK, I now have at least 1/2 of the solution .... use VDRplayer.py with Launcher.

In Launcher put
Title
Command
c:\python27\python c:\python27\VDRServer1.py C:\Data-Dart\Nmea\cutty2watchhill.txt 127.0.0.1 2947 .033

Then make sure to make a connection
Network 127.0.0.1 Port 2947 TCP

But I don't have it working yet.

[rgleason]

Now get "Access Denied" for python 2.7.10 on Win10


C:\Users\Rick>c:\python27\python c:\python27\VDRServer1.py C:\Data-Dart\Nmea\cutty2watchhill.txt 127.0.0.1 2947 .033
Access is denied.


Windows Defender is doing its job on me. This has been happening for the last two days. When I tried VDRplayer for VentureFarther testing. ----I just hate this stuff.

https://stackoverflow.com/questions/...ied-on-windows

Tried command prompt as Admin. Still says "This App can't run on your computer" "to find a version for your PC, check with software publisher.""

Now isn't this just dandy.... it ran before Microsoft what the devil do you think you are, God almighty?

[transmitterdan]

Rick,

I don't understand what you are doing. This is what I know works:

1) If you disable all connections in Options->Connections by unchecking the Enable box of all connections then no NMEA data will flow into OpenCPN from anywhere.

2) If you enable a connection such as a UDP port that VDRplayer.py can send then there are options at the bottom of the connections setup labeled "Input Filtering". If you click the "Ignore sentences" button and click the choose button (... on the right) you will see GLL as one of the choices. If you select it then GLL will be added to the ignore list. At that point O will no longer process GLL messages.

3) Nothing you do in the NMEA debug window will affect how O processes messages.

[transmitterdan]

Rick,

Maybe you should get the latest VDRplayer.py here:

https://github.com/transmitterdan/VDRplayer

[rgleason]

Yes, I will check latest VDRplayer, I think I have it.

But the real problem is python is NOT working. Windows10 is now rejecting it.
I think I have to update Python 2.7.10 and make sure I pick the 64 bit version because that is the OS I am using. Windows is getting picky now!!

Using Admin did nt work. and still shows same MS rejection.

[transmitterdan]

Originally Posted by rgleason

Yes, I will check latest VDRplayer, I think I have it.

But the real problem is python is NOT working. Windows10 is now rejecting it.
I think I have to update Python 2.7.10 and make sure I pick the 64 bit version because that is the OS I am using. Windows is getting picky now!!

Using Admin did nt work. and still shows same MS rejection.

I don't have such problem with Python. You might try running it as administrator.

[rgleason]

Updates to Win 10 creator voided python 2.7 requiring uninstall (using admin user did not overide compatibility message by OS). Installation of python 3.5 64bit version is working. Have had VDRplayer running from Launcher_pi with Hartmut.txt file. Now working on input/output and filters. Thanks

[rgleason]

After remove and reinstall of Norton Security, due to Windows10 Creator new version overriding Norton functions, Norton is working correctly and I can now run VDRplayer without having it cut off.

The only way I could record a file without the GLL sentences, was to select to Filter GLL from the input side. Then I was able to run VDRplayer which records the nmea0183 data stream going through Opencpn, and the two GLL did not show up in the file. The screenshot shows this setup with the dual GLL sentences in red (filtered) in the nmea popup window.

The tracking is more consistent without the GLL sentences.

I have also had a chance to think about my physical setup, and I believe the GPS puck located just under the cabin roof, that I have attached to the VHF/DSC is also providing location data to the autopilot through a nmea0183 port, and I have not detached those wires. This then means that those location signals are getting into the Seatalk Bus and being converted to Nmea2000 and put on the B&G data bus, creating this confusion.

Out of curiosity, is a way to record nmea data out on the the 127.1.0.0.1 port 10110? What program is used on Windows?

When this file completes, I'll upload it. Thank you TDan.

I think we might need to augment the Connections section a little.

[transmitterdan]

You can make a poor man's VDR recorder by telling OpenCPN to send output using TCP to the local address (127.0.0.1 aka localhost) and an unused port number. Then start a telnet session to that address and port number. You will see all the output messages. Your Telnet program should have a way to redirect or capture output so if you direct that to a file you will record all the NMEA messages. There are several terminal emulator programs floating around the internet that can act as Telnet clients. I think even PuTTY can do it.

[rgleason]

After removal of Python 2.710 and install of Python3.5, using VDRplayer with the following command at the prompt:

python C:/Users/Rick/AppData/Local\Programs\Python\Python35\VDRplayer.py C:\Data-Dart\Nmea\cutty2watchhill.txt 127.0.0.1 10110 0.02 TCP

Then I've setup an Options > Connection in OpenCPN which includes a TCP 127.0.0.1 port 10110 with Control Checksum and Priority 1, with INPUT FILTERING includes of RMC, DBT and excludes GLL,MWV,DBT,VHW,MTW (see attached).

And then used VDR RECORD to record the NMEA 0183 sentences that are sent into OpenCPN and saved as cutty2watch-filtered-only-RMC-VBT-4.txt

While doing this I had Tracking on, and found that there are about 5 out of area points which cause the high speeds, which can be seen in the track. The next problem is to figure out how to remove these bad points, and why they are occurring.

It would be helpful to be able to Move VDRplayer start point, or to start at some designated point in the file, or to move it forward fast, or to pick a point on a time bar.