Tactics Plugin

[rgleason]

Thomas has looked into this problem, during a break from his busy schedule and reports the following:

regarding this error report with negative HDT :
Tactics is using HDT directly from NMEA, if available, no recalculation then. This is priority 1
IF HDT is not available, it tries to calculate HDT from HGD (compass heading) by adding /subtracting the magnetic variation
There are various sources for the magnetic variation:

• GPS, as part of RMC (AFAIR)
• manual input in the user prefs of O
• via plugin (e.g. wmm_pi)

Any of the args above may fail, even HDT read via NMEA... Keeping that in mind, it's almost impossible to search for an error without a NMEA sample file.
Is simply doesn't make sense to invest time into an error that shows up now after half a year of intense use (at least I have never seen this)

Maybe we can rate it as the "Mystery of the Bermuda triangle" ?

BR,

Thomas

Rick wrote:

Thank you for the very clear report. I will post it on the thread, I believe he had a video of it, but without the file it is hard to track down. I believe the problem was also identified in Dashboard, and probably should be solved there. I agree its very hard to track down.

Thomas response:

Rick,
If it occurs in Dashboard as well, it's even more a sign that it is not the software, but some bug in his setup...
Thomas

I hope this helps identify the problem. (Thomas has had a lot of experience with this kind of problem.)

[hasse_A]

Originally Posted by rgleason

Thomas has looked into this problem, during a break from his busy schedule and reports the following:

Originally Posted by Thomas

regarding this error report with negative HDT :
Tactics is using HDT directly from NMEA, if available, no recalculation then. This is priority 1
IF HDT is not available, it tries to calculate HDT from HGD (compass heading) by adding /subtracting the magnetic variation
There are various sources for the magnetic variation:
GPS, as part of RMC (AFAIR)
manual input in the user prefs of O
via plugin (e.g. wmm_pi)
Any of the args above may fail, even HDT read via NMEA... Keeping that in mind, it's almost impossible to search for an error without a NMEA sample file.
Is simply doesn't make sense to invest time into an error that shows up now after half a year of intense use (at least I have never seen this)

Maybe we can rate it as the "Mystery of the Bermuda triangle" ?


BR,

Thomas

I don't understand. Thomas says he needs a NMEA sample file. This is precisely what I have uploaded to my dropbox showing the error. What more do you want ?

/Hans

[BMayer]

Declination by gps can be false.
An internal information must be updated, yearly (ephemerides in french)
My old Garmin 152 send false declination because it's too old.

[hasse_A]

Originally Posted by BMayer

Declination by gps can be false.
An internal information must be updated, yearly (ephemerides in french)
My old Garmin 152 send false declination because it's too old.

This I do not understand either. How can a correct calculation with an error in declination result in a negative true heading ?
I do understand that an error in the declination can result in an error in the value of the true heading but how can it make it negative ?

/Hans

[BMayer]

Magnetic declination are get by RMC sentence.
NMEA Revealed

I know my local, verified, declination.
I read NMEA from different GPS. On ercent/new device, declination are correct.
On olders devices (> 5 years), value declination are false.

[Schnapsy]

Originally Posted by BMayer

Magnetic declination are get by RMC sentence.
NMEA Revealed

Not really...

Below, the sentence from my three years old VHF Standard Horizon GX2200

$GPRMC,113621.000,A,5102.8059,N,00222.2759,E,0.00, 15.33,150318,,,D*5E

As you can see, the magnetic data is not given...

[Schnapsy]

Originally Posted by Schnapsy

As you can see, the magnetic data is not given...

However, what I wrote may perhaps not be accurate, because this indication was taken when the boat was stopped (at the port).
I have to verify this point...

[BMayer]

most of my device have a fanciful values.
I suppose device have builtin informations (ephemerides), with expiration date

[rgleason]

Please https://github.com/tom-r/tactics_pi/issues/21
also https://github.com/tom-r/tactics_pi/pull/22

[CapnRon47]

Just an update.
I had to rebuild my Rpi SD card system (for various reasons), in the process I upgraded to OpenCPN 4.8.2 and added my previous plugins. I also updated the source code for the Tactics plugin and rebuilt it using the process I previously described in this thread. It all worked, but I still end up having to move the libtactics_pi.so file from the build directory to /usr/lib/opencpn, where all the other plugin *.so files are.

Now to get out on the water and run some polars.

thanks,
Ron

[CapnRon47]

Note: I am not running Raspbian Stretch, I am still running Jessie. I wanted to avoid that issue for the time being.

Also, the reason I have to move the tactics plugin files is because its location reference is different from OpenCPN. OpenCPN references /usr/, while the plugin references /usr/local. As was mentioned to me in another thread. I forgot and did not change the reference in the CmakeCache.txt file in the build directory where it states
CMAKE_Install_Prefix:Path = /usr/local

if I had changed this to just /usr the built files would have ended up the correct location for OpenCPN.

In the end it all seems to work.

Ron

[rgleason]

Capt Ron, lets make a "new issue" in Thomas' repository https://github.com/tom-r/tactics_pi/issues
If you lwould ike me to do it, I can.

...move the tactics plugin files because the location reference is different from OpenCPN.

• OpenCPN references /usr/,
• plugin references /usr/local.

...I forgot and did not change the reference in the CmakeCache.txt file in the build directory where it states

• CMAKE_Install_Prefix:Path = /usr/local

if I had changed this to just "/usr"
the built files would have ended up the correct location for OpenCPN.

In the end it all seems to work.

[rgleason]

Thomas has released a new version of the plugin:

tactics_pi-1.0008-win32
https://github.com/tom-r/tactics_pi/releases

[CapnRon47]

I see you already added an issue to Tom-r issue page, that is fine. The CmakeCache.txt file is created during the make process and is in the build directory. I don't know if the localization dependency comes from something in Tom-r's code or from the system. In the thread on 'compiling for Debian' Janth indicates that you could just change the localization after running cmake and the CMakeCache.txt file is created and before your run the plugin install commnad. I found it pretty easy just to move the files afterwards. There are two sets of files to move, the tactics_pi.so file and the tactics_pi/data files that also end up in a different directory.

[rgleason]

Thanks Ron, I believe the Cmake directory has a file that can be changed.