Tactics Plugin

[Canne]

Originally Posted by RonSouthworth

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

"Yes" for an average Joe, it can be fun! But "no" for the instrument unit tester who is looking for an independent testing reference.

Boat's owner has blind faith to his boat's instruments, not always founded since there is no calibration procedure has been executed ever since the instrument left the factory sometimes ten years ago. But it is human to believe to some authority. Because it is build in a factory it cannot be wrong.

Professionally, I believe in standards and when working on O I would take the OpenCPN interpretation of NMEA-0183 standard and except to be able to build with your tool sentences which match that intrepretation, Then I would send the ensemble to the instrument (including Tactics active calculations), one at a time, and verify that it works as the test plan expect it to behave. then it is either PASS or FAIL. And nothing in between.

Please don't create a repeater of VDR recordings. Their interest is in the intermediate step between the unit tests and the real world (sailing). VDR's problem is that there is no timestamps. Playback is at arbitrary speed, albeit always monotonic. Maybe I do not want to repeat what I think about testing an event based system with a monotonic rate player?

Originally Posted by RonSouthworth

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)

They all have in their settings the depth offset (Dashboard and Dashboard-Tactics even are sharing this setting):

This is how the offset (g_dDashDBTOffset) and value is treated and set to instruments after the NMEA-parser:

                    if( m_NMEA0183.Dbt.DepthMeters != 999. ) depth = m_NMEA0183.Dbt.DepthMeters;
                    else if( m_NMEA0183.Dbt.DepthFeet != 999. ) depth = m_NMEA0183.Dbt.DepthFeet
                                                                    * 0.3048;
                    else if( m_NMEA0183.Dbt.DepthFathoms != 999. ) depth =
                                                                       m_NMEA0183.Dbt.DepthFathoms * 1.82880;
                    depth += g_dDashDBTOffset;
                    SendSentenceToAllInstruments( OCPN_DBP_STC_DPT, toUsrDistance_Plugin( depth / 1852.0, g_iDashDepthUnit ), getUsrDistanceUnit_Plugin( g_iDashDepthUnit ) );

[rgleason]

As a frequent user of VDRplayer and VDR with a very big folder of nmea files, this has been the majority of "testing" that I have done, other than some "real" tests on the boat. So I am still learning...

It appears from what Petri says, that Ron's Simulator has the potential to

1. Build nmea sentences that match the OpenCPN interpretation of NMEA-0183 standard
2. Send sentences to the instrument (including Tactics active calculations), one at a time.
3. Be able to verify if verify that it works as the test plan expects it to behave.
4. Pass or Fail.

Petri's comment about using VDR players:

VDR's problem is that there is no timestamps. Playback is at arbitrary speed, albeit always monotonic. Maybe I do not want to repeat what I think about testing an event based system with a monotonic rate player?

So I guess I've got to learn how to make the simulator work, provided it will work as Petri suggests.
Note: I have made individual VDR files to test specific things.
The Simulator has the potential to improve the quality of the software, I think.

[rgleason]

Originally Posted by Canne

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.

Petri, Thank you for taking the time to explain how. From the first reading it seems similar to what I had to do to get appveyor to push an artifact file up to the github repository, (it took me a day of work to get it right) with initiation of the action by pushing a new Tag to origin. The credentialing looks different however. When I get to know these techniques better, I think we might want to write them up for the Dev manual.

[rgleason]

I started this section in the Dev Manual just so things don't get lost. Needs some editing though.


https://opencpn.org/wiki/dokuwiki/do...ith_a_push_tag

[rgleason]

Canne, rather than download ruby, in order to encrypt a github token for travis, I had an idea. I have a WSL install of 18.04LTS Ubuntu linux, thanks to TDan, perhaps I just install the linux encryption in there to encrypt the github token?

Would these prequisite commands work with Ubuntu? I get screwed up with all the flavors of OS here and have no idea what works. Windows guy,...

https://docs.travis-ci.com/user/encrypting-files/

[Canne]

Rick, I like this! You put even my rant about interweb fake instructions over there

Out of curiosity, you mentioned that with AppVeyor it was enough just to remote push a tag in the origin to launch an AppVeyor build which would end up to deployment by AppVeyor into GitHub. But where did the generated *.exe file ended up in GitHub and how did one refer to it?

I understood from Travis that a release repository is needed as target.

[Canne]

Originally Posted by rgleason

https://docs.travis-ci.com/user/encrypting-files/

Nope, don't use this, it has nothing do with simple token encrypting, it is one string, not a file system...

Originally Posted by rgleason

I have a WSL install of 18.04LTS Ubuntu linux, thanks to TDan, perhaps I just install the linux encryption in there to encrypt the github token?

Yes! Now you're talking business, with Ubuntu you have probably ruby installed by default. Let me start my 16.04LTS and I copy the commands I used to save you from Windows hell...

sudo apt-get update --fix-missing
sudo apt-get install ruby
sudo apt-get install gem
ruby -v

I got ruby 2.3.1p112 (2016-04-26) - you may have later. Below, note double dashes.

gem install travis -v 1.8.10 --no-rdoc --no-ri
travis version

1.8.10. Voilà!

Welcome to the world of the command line where everything is possible!

[Canne]

Originally Posted by AedanC

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

Originally Posted by Canne

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):

Aedan, I made a quite verbose debug printing version in order to get more than just one line in opencpn.log file, please use this one for your test: https://github.com/canne/dashboard_t...32DbgLog++.exe

It is filling very quickly the opencpn.log so don't let it run more than 2 - 3 minutes with VDR playing, that's enough.

I enforced some tests inside the Tactics TW calculations. Now, if it does not crash (one can always hope) but you do not see anymore the TW values, then please send me your .ini file together with the .log file. There is call-back to O itself which can, potentially, be the cause of the crash if some settings are gone or have out-of-range values.

Thank you for patience!

[AedanC]

Dear Petri,

Originally Posted by Canne

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 ):

For some reason OpenCpn started up with a default position in the middle of Denmark, the deviation was like the attached file Original_WWM.jpg

Originally Posted by Canne

1. Do not start the playback but move your boat back to the crime scene approximately where the recording starts
2. Check with WMM model plugin what is the magnetic deviation at the boat's position:

I did, and a picture is attached, see AtStartOfTrack_WWM.jpg

Originally Posted by Canne

1. (I have)Attachment 194477
2. Disable the WMM plugin
3. Close OpenCPN/Restart it
4. Set the SOG option as always
5. Start the VDR playing
6. Send back the log file and report here any observation

I did all that (using the first debug version). OpenCpn crashed in the same way as before and the log file is attached.


I will now install the second debug version (the more verbose one) and report back on that shortly.


Aedan

[AedanC]

Hi Petri,

Originally Posted by Canne

Aedan, I made a quite verbose debug printing version in order to get more than just one line in opencpn.log file, please use this one for your test: https://github.com/canne/dashboard_t...32DbgLog++.exe

It is filling very quickly the opencpn.log so don't let it run more than 2 - 3 minutes with VDR playing, that's enough.

I enforced some tests inside the Tactics TW calculations. Now, if it does not crash (one can always hope) but you do not see anymore the TW values, then please send me your .ini file together with the .log file. There is call-back to O itself which can, potentially, be the cause of the crash if some settings are gone or have out-of-range values.

Thank you for patience!

I have installed that version and also left the WWM plugin disabled. I'm afraid OpenCpn crashed just like before. I have attached the log file and ini file below, hopefully there is something useful in them.


Re the WMM, my position comes from a Vesper XB6000 AIS via NMEA and it also has a magnetic model built in, I assume that's where the second value came from.


Best regards,


Aedan

[Canne]

Originally Posted by AedanC

I have installed that version and also left the WWM plugin disabled. I'm afraid OpenCpn crashed just like before. I have attached the log file and ini file below, hopefully there is something useful in them.

Bon sang, mea maxima culpa! Why in the earth I did not ask you to send the .ini file in the first place! Because myself Rick and few others have Tactics_pi installed, I thought "he must have migrated his settings from Tactics". Obviously you did not since I immediately spotted this:

[PlugIns/Dashboard/Tactics/Performance]
PolarFile=NULL

Mea maxima culpa #2: I have written in my requirements list that "user of Dashboard-Tactics should be able to use the plugin without a polar file". Of course, I never did implement that.
Mea maxima culpa #3:Even if I did not implement it, good programming QA would have required that I write in my test plan at least one test without a polar file. A program should never crash, even if it does not automagically work!

Some midnight oil burning produced quickly this version https://github.com/canne/dashboard_t...arDbgLog++.exe which maybe would compensate your efforts by actually not crashing. If it does not (maybe my tired eyes missed some BoatPolar-pointers), this version comes also with even more debugging in the log file, which I hope would allow to pinpoint where the eventual troublesome pointer is located.

Originally Posted by AedanC

Re the WMM, my position comes from a Vesper XB6000 AIS via NMEA and it also has a magnetic model built in, I assume that's where the second value came from.

I see. Here's something to consider for VDR-play-back testers. This would never happen in real life, luckily: if you have a WMM module, that value for the boat's position at startup is sent immediately by O to all plugins, once. Now later on, O analyzes the NMEA-sentences (or call some higher forces) to get a fix.

This fix contains the magnetic variation. O gets it from your instrument, I have checked. It overrides, with highest priority once per second all other magnetic variations Dashboard may have found from any other NMEA sentences (wonder why we keep searching them, sometimes O is curious in its logic, or the lack of it). And, of course, it overrides the WMM value, which is the lowest priority.

The caveat for the Tactics active calculations is that during the time before O gets a fix from the NMEA stream, Tactics gets True Heading values which, in your case are magnetic heading in Scotland corrected with magnetic variation in Denmark! Not very scientific but since Tactics does not seem to suffer too much from that and since there is nothing I can do, since it is O feature, I would just suggest not to use WMM with Tactics functions. At least, this way it is clear.

Aedan, thank you! Two bugs fixed (I hope) and one O "feature" understood thanks to you immense patience and availability.

[rgleason]

Congratulations guys!

That was a tough one. Knowing which WMM Opencpn or Vesper seems to be pretty important. There are some other very important things to understand about this sophisticated plugin.
1. Calibration of instruments.
2. Where WMM should come from O or Vesper. What to do.
3. Important role of STW for Performance metrics.
4. What else....should go into the manual?

Originally Posted by Canne

Bon sang, mea maxima culpa! Why in the earth I did not ask you to send the .ini file in the first place! Because myself Rick and few others have Tactics_pi installed, I thought "he must have migrated his settings from Tactics". Obviously you did not since I immediately spotted this:

[PlugIns/Dashboard/Tactics/Performance]
PolarFile=NULL

Mea maxima culpa #2: I have written in my requirements list that "user of Dashboard-Tactics should be able to use the plugin without a polar file". Of course, I never did implement that.
Mea maxima culpa #3:Even if I did not implement it, good programming QA would have required that I write in my test plan at least one test without a polar file. A program should never crash, even if it does not automagically work!

Some midnight oil burning produced quickly this version https://github.com/canne/dashboard_t...arDbgLog++.exe which maybe would compensate your efforts by actually not crashing. If it does not (maybe my tired eyes missed some BoatPolar-pointers), this version comes also with even more debugging in the log file, which I hope would allow to pinpoint where the eventual troublesome pointer is located.

I see. Here's something to consider for VDR-play-back testers. This would never happen in real life, luckily: if you have a WMM module, that value for the boat's position at startup is sent immediately by O to all plugins, once. Now later on, O analyzes the NMEA-sentences (or call some higher forces) to get a fix.

This fix contains the magnetic variation. O gets it from your instrument, I have checked. It overrides, with highest priority once per second all other magnetic variations Dashboard may have found from any other NMEA sentences (wonder why we keep searching them, sometimes O is curious in its logic, or the lack of it). And, of course, it overrides the WMM value, which is the lowest priority.

The caveat for the Tactics active calculations is that during the time before O gets a fix from the NMEA stream, Tactics gets True Heading values which, in your case are magnetic heading in Scotland corrected with magnetic variation in Denmark! Not very scientific but since Tactics does not seem to suffer too much from that and since there is nothing I can do, since it is O feature, I would just suggest not to use WMM with Tactics functions. At least, this way it is clear.

Aedan, thank you! Two bugs fixed (I hope) and one O "feature" understood thanks to you immense patience and availability.

[rgleason]

Petri wrote:

Out of curiosity, you mentioned that with AppVeyor it was enough just to remote push a tag in the origin to launch an AppVeyor build which would end up to deployment by AppVeyor into GitHub. But where did the generated *.exe file ended up in GitHub and how did one refer to it?

I understood from Travis that a release repository is needed as target.

Yes, I have set up an Appveyor file with a github security token with some permissions, that then is encrypted by Appveyor's on line encryption and then used as the auth_token in the appveyor.yml file. See Weather_routing appveyor.yml With the proper settings you can then make changes and push, then issue


git push origin v1.5 push a tag to remote server


If you make a mistake and need to undo and push the tag again use some of the commands below to remove the tag and push it again.

---

git tag shows a list
git show v1.2 shows detail
git tag v1.4-lw
git tag -a v1.4 -m "my version 1.4"
git tag v1.4-lw
git push origin v1.5 push a tag to remote server
git tag -d v1.4-lw delete tag


-----


Follow the settings in the appveyor.yml file for weather_routing.



The process to get a github token or key and then encrypt is quite easy and quick, (it took me about a day because I did not understand any of it)


The files will end up in a new "Release" with the version number you use simillar to my weatherrouting repository.
Here https://github.com/rgleason/weather_routing_pi/releases


v1.13.1 is one example. This release could have the Osx files and linux.


All that is left is to make the auth_token encrypted security
Please see my writeup that needs to be edited and improved.

See https://opencpn.org/wiki/dokuwiki/do...github_release




I understand from your work that we can do the same with .travis and all that is needed is the encrypted security code which provides access to upload or push files to the github release area. Bravo.


We can have windows, mac and linus install files in the same place Release! with just a little work.


This does not take away from Leamas and Pavel the immense power and advantages of a plugin Manager which we should be striving for all the time.

[Canne]

Originally Posted by rgleason

See Weather_routing appveyor.yml

Ok, I can see that you have "releases" like me in GitHub on which the AppVeoyr pushes the built packages if a tag is defined. We're doing the same thing, Rick, except this time you are using the command line (!) and me the easy web interface (!) directly on GitHub! Well, essential is that we have the same look and feel for the end user and you assured me that yes, we do. For all Sean's plugins you should be able to add Travis dual build and GitHub deployment without too much pain.

For you document, it lacks a clear example, instead of referencing external, why not give a complete example where all bits an pieces are in place and the only thing which is missing is the encrypted token. I noticed that this part of the AppVeyor file is the crucial one in the deployment - this is not the only way of doing it, of course:

deploy:
  description: 'release created by AppVeyor CI'
  provider: GitHub
  auth_token:
    secure: <your encrypted GitHub API token here>
  artifact: installer
  draft: true
  prerelease: true
  tag: $(APPVEYOR_REPO_TAG_NAME)
  on:
    appveyor_repo_tag: true # deploy on tag push only
    configuration: Release  # Debug contains non-redist MS DLLs

[AedanC]

Dear Petri,

Originally Posted by Canne

Some midnight oil burning produced quickly this version https://github.com/canne/dashboard_t...arDbgLog++.exe which maybe would compensate your efforts by actually not crashing. If it does not (maybe my tired eyes missed some BoatPolar-pointers), this version comes also with even more debugging in the log file, which I hope would allow to pinpoint where the eventual troublesome pointer is located.

I think you can go and celebrate now!!! Well done you seem to have fixed it. The latest version does not crash and produces values for TWS and TWD with "Use SOG... " ticked. I also tested it with and without "Force..." ticked too.

One small issue is that on the "True Wind Dir. and Speed" instrument, the TWS displays as zero, see attached picture.

Originally Posted by Canne

I see. Here's something to consider for VDR-play-back testers. This would never happen in real life, luckily: if you have a WMM module, that value for the boat's position at startup is sent immediately by O to all plugins, once. Now later on, O analyzes the NMEA-sentences (or call some higher forces) to get a fix.

This fix contains the magnetic variation. O gets it from your instrument, I have checked. It overrides, with highest priority once per second all other magnetic variations Dashboard may have found from any other NMEA sentences (wonder why we keep searching them, sometimes O is curious in its logic, or the lack of it). And, of course, it overrides the WMM value, which is the lowest priority.

The caveat for the Tactics active calculations is that during the time before O gets a fix from the NMEA stream, Tactics gets True Heading values which, in your case are magnetic heading in Scotland corrected with magnetic variation in Denmark! Not very scientific but since Tactics does not seem to suffer too much from that and since there is nothing I can do, since it is O feature, I would just suggest not to use WMM with Tactics functions. At least, this way it is clear.

I think I understand this, but I don't understand why "this would never happen in real life". From your analysis above I think I should disable WMM on my boat's computer so it can't fight with the Vesper one, is that correct?


Your persistence on finding this when only one person could cause it has been exemplary. Many people would have just said "it's obviously Aedan's computer is acting a bit odd" and moved on. In contrast I reported a really dangerous bug to Garmin which prevented AIS targets classified by Garmin as dangerous being displayed on the screen. First they tried to blame Vesper, once I'd got them past that they really were not interested and eventually just closed the ticket without even telling me.

Originally Posted by Canne

Aedan, thank you! Two bugs fixed (I hope) and one O "feature" understood thanks to you immense patience and availability.

Thanks again for all your work on this plugin. I'll go off and try and do a bit more testing on it now. I'll do a few more things before I load that polar.....


Aedan