Tactics Plugin

[Canne]

Dear Aedan, thanks a lot for your efforts, it helps me to pinpoint the issue in a smaller area; around the entry of the tactics' TW calculation. The inspection for entry rights is severe, you will see!

That was a good idea to remove the STW sentence altogether, I tested it and immediately it revealed a logical error in the entry to the TW calculations. It says:

    if (st == OCPN_DBP_STC_AWS && !std::isnan(mStW) &&
        !std::isnan(mSOG)){

But that does not make sense since the next sentence says

        //  Calculate TWS (from AWS and StW/SOG)
        spdval = (g_bUseSOGforTWCalc) ? mSOG : mStW ;

In your case, mStW can remain NaN since you have required SOG for TW and provide mSOG, you are right and the above logic is wrong. I'll improve in the next beta patch version, hopefully tomorrow, latest this weekend.

You see, we've already found one bug!

Back to the original recording, with IIVHW but with STW=0.0. I am suspecting a NaN somewhere. Again, let's check to the next entry point to the TW calculations in Tactics. It says:

        // only start calculating if we have a full set of data
        if ((!m_bTrueWind_available || g_bForceTrueWindCalculation) &&
            (mAWA >= 0.0) && (mAWS >= 0.0)  && (spdval >= 0.0) &&
            (mAWAUnit != _("")) && !std::isnan(mHdt)) {

You may notice that Tactics is not checking against NaN values (not a number). I reckon it is my task to protect it from those in the upstream, in Dashboard side (in which I have created code which is calling this function).

I have created a special debug version, which is verbose, very verbose in the C:\ProgramData\opencpn\opencpn.log file. Download it from here:

https://github.com/canne/dashboard_t...n32_DbgLog.exe

If you have SOG TW selected and you start the VDR (with STW=0.0) you should get very quickly to the above gateway with AWS. I print in the log file those values before they are evaluated by Tactics. It looks like this in my system with your data:

1:15:09 AM: Changing NMEA Datasource for OCXDR to  (Priority: 0)
1:15:22 AM: tactics_pi::SendSentenceToAllInstruments_GetCalculatedTrueWind()- mSOG 3.728000, spdval 3.728000, m_bTrueWind_available false, g_bForceTrueWindCalculation false, mAWA 38.000000, mAWS 13.500000, mAWAUnit '°R', mHdt 270.500000
1:15:22 AM: tactics_pi::SendSentenceToAllInstruments_GetCalculatedTrueWind()- mSOG 3.728000, spdval 3.728000, m_bTrueWind_available false, g_bForceTrueWindCalculation false, mAWA 37.000000, mAWS 13.500000, mAWAUnit '°R', mHdt 269.500000
1:15:22 AM: tactics_pi::SendSentenceToAllInstruments_GetCalculatedTrueWind()- mSOG 3.728000, spdval 3.728000, m_bTrueWind_available false, g_bForceTrueWindCalculation false, mAWA 35.000000, mAWS 13.500000, mAWAUnit '°R', mHdt 269.500000

and so on. In your case, it would be a good progress if we have at least one of these variable printouts. Please try and provide a few of those log values.

[Canne]

Hi Aedan, please see and move to use https://github.com/canne/dashboard_t...s/tag/v0.2.017 which as few fixes, thanks!

[AedanC]

Dear Petri,

Originally Posted by Canne

Dear Aedan, thanks a lot for your efforts, it helps me to pinpoint the issue in a smaller area; around the entry of the tactics' TW calculation. The inspection for entry rights is severe, you will see!

That was a good idea to remove the STW sentence altogether, I tested it and immediately it revealed a logical error in the entry to the TW calculations.

I'm very glad all your work is finding things at last, and I feel very sorry for being the only person who can cause a crash. I hope it does not turn out to be me doing something stupid in the end.

Originally Posted by Canne

In your case, it would be a good progress if we have at least one of these variable printouts. Please try and provide a few of those log values.

I ran this and got one such line in the log file. The complete log file is attached, renamed as required by the forum.

I also tried 2.017 as per your next post, it still crashes at the same point.

Unfortunately I'm going travelling again now, I'll be back on Saturday afternoon (UTC+1).

Rick, I hope your boat launching is going well, I'm planning to launch next Thursday.


Best regards,


Aedan

[Canne]

Great job, thank Aedan. Only one debug line, and it says "all good for TW calculations"! Now I know that the crash occurs not in the Dashboard side or its interface to Tactics functions but very likely in the Tactics' true wind calculation method. That information is really useful for debugging.

Originally Posted by AedanC

I feel very sorry for being the only person who can cause a crash.

Don't feel sorry, I am so happy to have you since I am sure that this issue is concerning many other users as well. With the small number of Windows testers (you, Rick and me) and with Rick and me repeating the same VDR file at monotonic rate it is very valuable to have a tester like you who has something _different_. Thank you so much for making this effort. Let's hope I can get it sorted out before your boat launch! I'll keep you posted (maybe with some more debug logging if I spot a likely place for the crash).

[rgleason]

Petri,
This is great. You've got OSX building and Linux. I've been wanting to do that too. If I used your travis version what else would be needed? Thanks.

Originally Posted by Canne

Progress: I managed to get out from Travis build a OSX package! But I have no way to test it, see here:
https://github.com/canne/dashboard_t...s/tag/v0.2.013
All comments welcome from Mac owners!

"Travis CI uses macOS 10.13 and Xcode 9.4.1" by default. Wishes for changes taken, see here what's available :
https://docs.travis-ci.com/user/reference/osx/#macos-version

[rgleason]

I've tried v0.2.017 release with Win10 and Opencpn 5.0 + 20c9a05


With a file recorded by Hartmut in the Markermeer
Hartmut-AN-Markermeer-Wind-AIS-6m.txt


I toggled Preference settings Tactics Performance Paramters such as
Display Current on Chart
Correct STW with Leeway
Force True Wind Calc
Show wind barb
Use SOG instead of STW for TW.


(I am using "X manual heel input" because I do not have a heel sensor.)

(I changed it to use heel sensor, but this Hartmut file does not have that data)

I have not been able to make it crash so far.


Log

5.0.0+20c9a05\plugins\dashboard_tactics_pi.dll
4:27:21 PM: PlugInManager: C:\Program Files (x86)\OpenCPN 5.0.0+20c9a05\plugins\dashboard_tactics_pi.dll
API Version detected: 112
PlugIn Version detected: 105
4:27:22 PM: dashboard_pi req = 4d9e
4:27:22 PM: tactics_pi req = cd9f
4:27:22 PM: dashboard_tactics_pi init ret = cd9f

Will try some more with Petri''s newest version, so sorry.

[Canne]

Originally Posted by rgleason

OSX building and Linux...If I used your travis version what else would be needed? Thanks.

I thought this might interest you... You can use it as it is, the MacOSX part was helped to package FAI (fully automated installation) by Nereus32 here. The two build target conditional variables are courtesy from Sean d'Epagnier from whom I have shamelessly stolen that part. But that's not all, you are certainly better aware than I am about the different Cmake include files in cmake-directory. In this case, there is a small modification for Mac in packaging, courtesy of Nereus32. Anyway, it takes for a while before, for each commit, both Linux and Mac builds correctly. There is no point to continue before they do.

Caveat: Nobody has tested yet the Mac packages I've created with travis.

Now you are ready to move to recover the built packages. In free travis.org version they are put in your project's release folder (that's why I have so many releases). In GitHub, release is not only a tag but also a repository where the built files are deployed.

You need a travis CLI (command line interface). It is needed to encrypt the GitHub token. The encrypted string is put in your personal .travis.yml file. Unlike in AppVeyor, there is no on-line service for it, not that I know. That's why you need to start with travis CLI installation. Here are some installation instructions for Windows, I used Linux where the installation was straightforward.

When you are sure that you have travis CLI up and working, you can start to create the encrypted key. Without it, deployment to GitHub does not work.

1. Create an API token for travis in GitHub here https://github.com/settings/tokens (Developer tools). Select all rights to repository and repository only (that's enough - if it does not work, it is something else). Don't close the window, or make sure you have copied the key to your computer.
   
2. Open command window and give following command (in Linux) with travis CLI:
   
3. echo pasteGitHubTokenHere | travis encrypt -r rgleason/reponameHere --org
   
4. It gives you out a very long arbitrary string in format "1234abcde....f". You need to copy and paste it in .travis.yml in secure field as one single line. Don't let your editor to break it on different lines.

Warning: you will find from the wonderful interweb instructions which are supposed to modify the .travis.yml on the fly. Believe me, I tried and they screwed up completely the file. Stick to copy-paste.

When you commit .travis.yml file, the travis build starts. It is good to check that both of its build processes do pass faultlessly before the next step.

In GitHub create a repository, like v1.2.3 as tag, description is free but it is good to contain the version. Here is where Travis and AppVeyor both deploy the built contents. When you hit the create button it is a sign for Travis and AppVeyor to start the build which will end up with deployment (the condition flags in the configuration file are defining this. That's why it is important that you check before you create the repository that all builds do pass faultlessly, you will not get a second chance but you need to create a new repository. (Repositories cannot be deleted since they are, in fact defined by tags.)

If you observe 401 error at the deployment phase in travis logs search in google.com with the following phrase for possible causes "travis github https://api.github.com/user: 401 - bad credentials"

Hope this helps a bit; you need tons of patience and a few trial repositories to sacrify.

[Canne]

Originally Posted by rgleason

I've tried v0.2.017 release with Win10 and Opencpn 5.0 + 20c9a05

Thanks, Rick, that's very useful. Have you actually tried with Aedan's recording here http://www.cruisersforum.com/forums/...ml#post2912336 - the bigger file with VHW sentences but where STW is 0.0 ? You leave but SOG calc ticked. For Aedan, it crashes as soon as the recording playing starts (his debug makes to think: at first time TW calculation algorithm has enough data to be executed).
Thanks!

BTW, Aedan has different variation correction in his heading values than I have when I run the same NMEA recording (i.e. his heading value is different than mine when he enters into the TW calculation algorithm). Since we have the same NMEA file and his instruments return in NMEA sentences the magnetic variation I was thinking we would have the same value. Maybe i is so that the WMM-model plugin provides this value no matter what the instrument says? Does this ring a bell? (from the code it looks like this being the case, but has there ever been discussion what is the selection criteria?)

If this is the case, it is about impossible to have exactly the same results for the two testers being in two different geographical position since HDT is used everywhere in Tactics. This may interest Ron.

[Canne]

Originally Posted by Canne

Does this ring a bell?

See my comment in https://github.com/canne/dashboard_t...d404#r34037949, next to the HDG sentence content distribution, which also sets mVar (for magnetic variation), this time from an instrument. Only that soon it will be overwritten by O who calls Plugin_Position_Fix() and which sets mVar it back to WMM value. Not good. Now you are telling me that why, they are the same value. Well, that's not true, but even if they are, why we have two sources for the same value?

[rgleason]

Well, I couldn't get either file to bomb by checking and unchecking

"if I tick the "Use SOG..." box when vdr is running"

Also I could not get either file to bomb by uncheck "Use SOG..." closing the plugin and the VDR file. Open dashboard-tactics then start VDR and either one of the files and it does not bomb.

What I do notice when "Use SOG..." is checked,
The true wind angle and speed gauge works, and the true direction and speed gauge works just halfway showing only direction and not speed.

When I check "Use SOG...." with both files and start up the plugin and the VDR then the polar file and laylines show, (but not Polar performance or graph), and when Use SOG is unchecked these disappear.

I note that having STW=0 and consequently actual CMG and Target VMG, Target CMG and Polar performance at 0 / (some value) is somewhat artificial.

Here are some screenshots.
Sorry, I could not get it to crash, but I think the speed should show in the True direction and speed gauge.

[rgleason]

... HDG sentence content distribution, which also sets mVar (for magnetic variation), this time from an instrument. Only that soon it will be overwritten by O who calls Plugin_Position_Fix() and which sets mVar it back to WMM value. Not good.

I think I understand this, but not programmatically or with respect to the plugin. Don't know if that helps...

[Canne]

Originally Posted by rgleason

Well, I couldn't get either file to bomb by checking and unchecking

"if I tick the "Use SOG..." box when vdr is running"

Also I could not get either file to bomb by uncheck "Use SOG..." closing the plugin and the VDR file. Open dashboard-tactics then start VDR and either one of the files and it does not bomb.

Thanks Rick, for having done this test, it sure helps to see that in both of our systems we have the same results. I have some ideas for further testing and now I know I can trust my own settings (I have too much stuff as all developers).

Originally Posted by rgleason

What I do notice when "Use SOG..." is checked, the true wind angle and speed gauge works, and the true direction and speed gauge works just halfway showing only direction and not speed...

This is expected, about in every algorithm of Tactics which has a "performance" tag on it is required that one has valid STW _and_ that it is >0.0. The author (Tom) says that "I cannot tell the performance of a boat which is moored". You may say, but you have SOG! Well, how would you calculate the leeway, for example? You say, it is OK that is 0.0. Gosh, this way, the exception list would be endless.

Currently, and before Tom submits new algorithms - I will not touch the existing ones unless Ron's B52 bombarder tester reveals a clear bug - if you have no STW or it is 0.0 you can use Tactics only for TW calculations, if you tick that SOG box. Ignore all Tactics instruments (that's why it would be good to group them in their own window panes).

[Canne]

Originally Posted by AedanC

...I ran this and got one such line in the log file...

Dear Aedan, one thing I noticed in your debug print (I am getting desperate you will notice ) is that you have your WMM model plugin activated and it is (correctly, it has priority=1) used in HDT calculations by Dashboard and the value is given to Tactics for TW calculation. But I have WMM model activated, too but somehow my debug sessions all show the HDT value being corrected with the magnetic variation reported by your instruments (GPRMC-sentence), 3.50 W. I cannot figure out why it is like this but I suspect a bug in Dashboard.

Can you please make the following test once you're back from travelling and whenever you have the extra time (it should not take long):

1. Start OpenCPN and before doing anything else..
2. ..check with WMM model plugin what is the magnetic deviation at the startup of your system at the default position (you don't have reveal the position here, only the magnetic deviation) - this value is according to NOAA tables submitted with your fresh OpenCPN v5.0.0. installation (they are less fresh, at least mine are, here c:/Program Files (x86)/OpenCPN/plugins/wmm_pi/data/WMM.COF ):
3. Do not start the playback but move your boat back to the crime scene approximately where the recording starts
4. Check with WMM model plugin what is the magnetic deviation at the boat's position:
5. (I have)
6. Disable the WMM plugin
7. Close OpenCPN/Restart it
8. Set the SOG option as always
9. Start the VDR playing
10. Send back the log file and report here any observation

I am not expecting that this will be the remedy for the crash (since with or without WMM it does no crash for me) but if the HDT value is jumping back and forth according the source (maybe bug in prioritization) that would not be good for the Tactics TW calculation algorithm. I am going to hunt down this anomaly first.

[rgleason]

Currently, and before Tom submits new algorithms - I will not touch the existing ones unless Ron's B52 bombarder tester reveals a clear bug - if you have no STW or it is 0.0 you can use Tactics only for TW calculations, if you tick that SOG box. Ignore all Tactics instruments (that's why it would be good to group them in their own window panes).

Yes, understood and expected. So if my paddlewheel is stuck by seaweed, I am not going to be able to use the performance aspects of Tactics, which is very clear and understandable.

[RonSouthworth]

Originally Posted by rgleason

Yes, understood and expected. So if my paddlewheel is stuck by seaweed, I am not going to be able to use the performance aspects of Tactics, which is very clear and understandable.

Comments on test plugin on that thread


Config selection of signals.

Do you think it would be good to select the set and drift values from a vdr frame ?

The other data value that seems to be upset is depth. I cannot zero out what looks to be an offset with all 3 dash plugins installed ( not necessarily all enabled at the same time)