Fails to calculate true wind with some NMEA message combinations

[ARF1]

Great plugin! I have always been wondering: "Where will I end up if I tack now? ... Is it still too early to make it arount the cape."

From what I understand, this plugin is supposed to calculate true wind if apparent wind and magnetic heading are provided on NMEA. For some combinations of NMEA sentences this does not seem to work.

If I send the following (artificial, because I am at home at the desk) sentences, true wind is not calculated:

$IIMTW,30.10,C*21
$IIMWV,64.00,R,20.70,K,A*3F
$IIVHW,,T,179.50,M,30.00,N,5,K*59
$IIHDM,179.50,M*18
$GPGLL,3553.5295,N,13938.6570,E,002454,A,A*4F
$GPGGA,002454,3553.5295,N,13938.6570,E,1,05,2.2,18.3,M,39.0,M,,*7F
$GPVTG,160,T,034.4,M,005.5,N,030,K*49

I have the WMM installed and activated.

Theoretically, with the magnetic heading (in HDM and VHW), the apparent wind (in MWV) and the declination (from WMM plugin) true wind calculation should happen automatically, right?

Instead only apparent wind data is recognized. If I "force calculation of true wind" in the settings, it works. But from my understanding of the docs, this setting is only intended to replace any existing true wind data on the NMEA stream. It should not be require to supplement an incomplete NMEA stream, right?

So is this a bug I did I misunderstand the documentation?

[rgleason]

I am not where I can mess with this problem easily.

1. Can you check the format of your sentences with the User Manual? Look for the list of nmea 0183 sentences supported in the User Manual under "advanced"
2. I believe it should work both ways, and using VDR_pi with your nmea is a good way to test it.
3. I may be a bug, but I think it was working fine, both as "calculated" and from "incoming data".

[ARF1]

@rgleason Thanks for taking the time to respond. No problem if you do not currently have the chance to look at it in detail.

Thanks also for your debugging advice. I have some questions regarding your suggestions though:

1. What user manual are you referring to? The tactics plugin manual in particular or the OpenCPN manual in general?
2. If you referred to the latter, the format of the wind related sentences cannot be checked with the OpenCPN manual as wind related sentences are not listed as recognised by OpenCPN - only by the dashboard plugin.
3. I believe the format of the sentences is ok: NavmonPC recognizes them as valid and calculates True Wind from them. (Provided I enable the calculation of the declination from WMM in NavmonPC. Otherwise the declination data would obviously be missing.) - A problem with my NMEA stream thus seems unlikely.
4. How do you suggest I use the VDR plugin? To inject the NMEA sentences quoted above? I am already injecting them as a stream. - Since my NMEA stream works fine with NavmonPC I no not believe the injection method is a problem. I can also see the messages being received as "OK" in the OpenCPN NMEA monitor window.
5. Where is the logic that uses apparent wind angle and declination data from the WMM plugin to calculate true wind angle? OpenCPN or your plugin? Where would I have to look for the bug?

Short: I do not believe this is a NMEA stream problem but a problem with the calculation logic for true wind using the WMM-plugin.

For now I am routing my NMEA stream through NavmonPC and let it calculate the true wind angle and export this supplemented NMEA stream to OpenCPN as a workaround.

I thought however I would document my issue in case somebody else encounters this issue.

[tom-r]

I think this is a simple missunderstanding ... The plugin does NOT ALWAYS calculate true wind, but only if you set the "force true wind calcultion" tick in the preferences. The purpose is to have an option to neglect existing true wind data from your instruments, and use the plugin calculation instead. Reasons could be e.g. that you prefer to use SOG for boat speed instead of the boat's speedo: Say you have 5 kts of current and you sail 5kts of boat speed, directly into the current, i.e. you're not moving over ground at all. --> True wind calculation will go completely wrong, when using the speedo (log), as it shows 5 kts. SOG shows 0 kts which will improve the calc. At least on my instruments I cannot change from log to GPS-speed for the internal true wind calculation. So I implemented this as an add on ... I hope that helps ... Thomas

[rgleason]

ARF1 I intended the say the tactics_pi user manual. Yes you can use NavMonPC (an excellent program) to send the nmea0183 sentences, instead of VDR_pi. Checking the nmea stream with the Nmea Debug window is a good idea. I guess your nmea is formatted acceptably. Have you checked "Force true wind calculation"? Does your nmea data now work as expected? Thomas has provided a more complete explanation above. This has been checked by several people, but it is possible that something changed.

[scadaperspective]

Hi Tom and Rick (enjoying some sailing I hope),

Thanks for creating and developing this plugin Tom.

I am exceedingly grateful for you efforts.

Re True Wind NMEA data Indication / use.

I have been testing this plugin using both applications I have at my disposal and the wind meter indicators in OpenCPN dashboard behave consistently but not the tactics_pi indicator. I am certain when Rick returns from sailing he can use the beta plugin I am developing to help test / demonstrate OpenCPN / other plugins and will be able to confirm what I am observing.

dashboard_pi is indicating true and apparent wind consistently with the messages being sent from the test programs I have here.

I find that unless the force true wind calculation is selected the true / applied wind dial and other dial's on tactics_pi don't use the true wind data reliably. What I am seeing even in your most recent build is the value flashes on and off the tactics_pi dial at the rate of 1Hz. Select force and it works solidly.

Apparent wind displays consistent to how the dashboard dial indicates for that value. This flickering is also impacting the other tactics indicators on the chart and the bearing and performance dial they show nothing with the true wind flickering.

With the force calculation selected the wind values and displays and everything works as expected when I use my stand alone simulator program. (Rick an issue I am aware of with the beta test plugin at the moment will cause the lay lines to not indicate correctly. this is due to the position math not yet being fully debugged something to note using it to test to ignore until I sort it out. not using the ship driver CRC routines / sorted yesterday) The tactics_pi shows lay lines correctly with my java test app. It includes set and drift into the positional data and the tactics_pi is displaying very closely to the values of set and drift that are dialled up. I have pitch and roll at zero values so those impacts are not reflected in the position calculations for the tactics_pi or my program

Hopefully these couple of observations might help in narrowing down the point at which the code variance is happening from with it deselected Tom.

Many Thanks

/Ron

[tom-r]

Ron, can you please send me a longer NMEA test file, please ? Maybe simply use VDR to export what you're feeding in as NMEA stream... Just a logical analysis (w/o looking into the code yet): a) when you set the "force true wind calculation" tick in tacticspi, it simply ignores any NMEA true wind data and does the calculation on its own. As this is working, it tells me that the plugin does not_ miss any NMEA true wind sentences, but recognizes them all (and drops them). So this logic seems to work correctly. b) Problem only occurs when you deactivate "force true wind calculation", i.e. you're using the incoming NMEA sentences. dashboard_pi as well as tactics_pi (as a fork of dashboard) use an internal "NMEA priority" for different NMEA sentences containing the same data (e.g. true wind, GPS position, speed, etc) , simply ignoring the lower priority sentence then ... I can see 2 possible sources for your problem : 1) tactics_pi has a bug in the NMEA sentence priority settings, and uses both of them 2) you're repeatedly sending the same NMEA sentence from 2 different data sources (sensors), and they're overwriting each other, causing the flickering ... I had this in the past when my AIS (besides my navigation GPS sensor) also sent an RMC sentence into O, and both were overwriting each other. I noticed it because my track had "spines" ...

It is strange that your system is obviously sending different data for true wind ... That shouldn't happen if you have only one wind sensor ...

To investigate this, I really need a longer sample NMEA file (a couple of minutes will do) which I can replay with VDR and look into it ...

BR, Thomas

[scadaperspective]

Hi Thomas,

I think I have an answer to what I am observing, that explains why forcing true wind calculations are required, thus answering ARF1 's query and as a follow on I now have something for me to include as far as message types so that the plugin can be tested in either mode. At least the info is easy for me to include in my stand alone program and just some extra info to work out when I get into that aspect of the simulator plugin.

The message probably needed to test the plugin without NKE or similar instrument set configured into the test rig is an $IIMWD / $--MWD message. Details on this message type are not one found from the usual suspect reference sources, with a bit of google diving however these details I found (not from NKE) say it all. I cannot see any other message type based upon what info is below that contains the same information. I welcome any feedback on any other message type that will.

$IIMWD / $--MWD.

$WIMWD Summary NMEA 0183 standard Wind Direction and Speed, with respect to north. Syntax Fields $WIMWD,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>*hh

<1> Wind direction, 0.0 to 359.9 degrees True, to the nearest 0.1 degree <2> T=True <3> Wind direction, 0.0 to 359.9 degrees Magnetic, to the nearest 0.1 degree <4> M = Magnetic <5> Wind speed, knots, to the nearest 0.1 knot. <6> N = Knots <7> Wind speed, meters/second, to the nearest 0.1 m/s. <8> M = Meters/second Default State Enabled. Transmitted once per second. (On the instrument system sourced this message format info from) Notes: The wind speed and direction data provided in this sentence are calculated using vector math based on the measured apparent wind speed and direction, SOG and COG from a GPS, compass heading, and magnetic variation. If any of these data are not available, this sentence shall be transmitted with null fields. The SOG, COG, and compass heading data used in the calculation may be provided by the internal GPS (if installed), internal compass (if installed), and/or from an external compass and GPS. The decision as to which data will be used is determined by the precedence rules defined in section 2.2.1. Says it all :) /Ron

[scadaperspective]

Hi Thomas and ARF1,

I have implemented the above $IIMWD message frame into my stand alone simulator program and the result says it all (see attached image) :) Much quicker and easier to code up than trying to get VDR working on macOS :)

From what I have worked out ARF1 I think your message combination is actually incomplete. I believe that yes you need to use the checkbox in order to have a means of calculating the values from the instrumentation on board if your setup does not include this message type.

I was hopeful in some respects initially that dashboard_pi would perform the calculations but at present it does not and that is understandable really. The math has to happen somewhere, for the budget conscience maybe another feature for raspberryPi network gizmo or similar folks to look at.

I have posted this info for Rick on the forum Thomas so that he will be aware of how to assist others etc for future reference.

Perhaps Thomas, a cursory note in the next document release clarifying this may alleviate future reports / make it clearer for prospective users that they need to either have an external means to compute the TWD such as what is available from NKE instruments or use the check box :) Might save some confusion.

Thanks once again for a brilliant piece of work Thomas (To everyone that has worked on this plugin actually) and for your thoughtful and helpful reply. I hope I have saved you some efforts. That would make my day.

/Ron

[pa2wlt]

Thomas,

Compliments for your good work! I'm highly interested in calculating True Wind, using SOG (and COG). I sail with ST50/60 instruments, that do not send NMEA-strings for True Wind data to OpenCpn. A few years ago, I wrote a separate program, to capture the incoming NMEA-stream, calculate True Wind, and send that in a NMEA-string on another stream to OpenCPN. Works good, though I always have to start that other program next to OpenCpn. I would love to integrate this in OpenCpn.

I was happy to find out that tactics_pi has an option to calculate True Wind, using SOG instead of STW. However ... on my installation it doesn't behave as expected: The instruments for True Wind Angle & Speed and True Wind Dir. & Speed on the Tactics dashboard show no value. That's why I send this post.

My incoming NMEA-stream only holds sentences for $IIMWV (for wind speed and angle) and $GPRMC (holding SOG and COG). I would expect that to be enough to have the True Wind calculated. Whereas it turns out differently.

Would you please inform me if the tactics_pi should have enough with these values to calculate True Wind, or that other incoming NMEA values are required as well?

FYI: Since I am not on board, I am simulating the incoming NMEA-stream with a stream I captured a few years ago while sailing on the Atlantic and writing the other program. I only recorded these 2 NMEA-sentences. The simulating streams works okay, since the instruments for Position, SOG, COG and App. Wind Angle & Speed work properly.

Hope to hear to see what my options are to continue.

Kindest regards.

[rgleason]

pa2wlt Please see the testing that Petri has done on dashboard_tactics. I believe all of those improvements/bug corrections were implemented in Thomas' Tactics_pi. It should give you additional insight. See TW items on this page https://github.com/canne/dashboard_tactics_pi/issues?page=4&q=is%3Aissue+is%3Aclosed https://github.com/canne/dashboard_tactics_pi/issues/4 https://github.com/canne/dashboard_tactics_pi/issues/5 https://github.com/canne/dashboard_tactics_pi/issues/6

There may be some other relevant tests which will inform you. Sorry but I have not tested these features at this point.

Let us know what you have determined please.

[pa2wlt]

Good to see it has been tested thoroughly. I might overlook it, though I cannot find if it is supposed to calculate the TWS TWD TWA when (only) $IIMWV (for wind speed and angle) and $GPRMC (holding SOG and COG) are available... Is there any functional description somewhere perhaps?

[rgleason]

pa2wlt Sorry, I am not much help right now, but the answer may be in the PDF file here https://github.com/tom-r/tactics_pi

[rgleason]

A search on issues for "true wind" https://github.com/tom-r/tactics_pi/issues?utf8=%E2%9C%93&q=True+wind

[pa2wlt]

Thx @rgleason. The PDF holds handy information about tactics_pi. About the True Wind calculation it says: "Input is AWA, AWS, STW, and for TWD also true heading HDT." I just can't see if these AWA and AWS refer to the actual AWA / AWS NMEA-strings, or to the values.

My NMEA-stream has $IIMWV (that holds AWA and AWS-values) and $GPRMC (that holds COG and SOG-values). With these values the instruments for AWS and AWA work properly.

Having the AWA, AWS, COG and SOG values, I am able to calculate TWS, TWA, TWD (apart for more refined corrections for heel, leeway, etc.). I prefer to use speed and heading from the gps above the waterspeed (STW) from the conventional log (since mine isn't very accurate) or the compass (HDT).

I hoped tactics_pi would make calculate TWA, TWS and TWD based on these values as well, though it isn't in my case.

I would like to find out if this is expected or unexepected behaviour. I reckon @tom-r does know the answer.

If this is unexpected behaviour, then perhaps there is an option to further improve tactics_pi to have TWA, TWS and TWD calculated with this data as well. I am more than willing to help with that.

If it is expected behaviour, then I'd like to find out what specific NMEA-strings are required to have TWS, TWA and TWD calculated. Am I only missing TWS here?

In the later case, I'd like to find a way to do this calculation somewhere in OpenCPN. That might be in tactics_pi, nmeaconvertor_pi could do as well, or directly in dashboard_pi.

[pa2wlt]

The sources gave clarity. I read at the end of this line ''&& !wxIsNaN(mHdt)". In other words: there has to be a magnetic heading value to calculate True Wind data. What happens in my case, should then be considered expected behaviour. Not desired though...

To enhance the calculation, and make it useful in my situation as well, I'd like to suggest an extra True Wind setting:  "Use COG instead of HDT". This fits perfectly under "Use SOG instead of STW". The calculation itself only requires some minor changes. I am more than willing to see if I can provide the code-changes for this. Please @tom-r, are you okay with this?

[rgleason]

Dear Werner, I would like you to consider getting a good heading sensor because this sentence is at the heart of the AP and instruments, particularly Tactics. I have asked about you proposed change and recieved a very good simple solution which may work. How about using nmeaconverter to create heading for tactics to use? This is a bit of a cob until you decide to get some equipment but it may work fine.

Incidently heading is essential data for tactics, unlike dashboard, and there is some reluctance to making this option and making the pi more complicated. You could fork the pi and add your change, that is opensource!

PS Thomas may decide to do it though.

[pa2wlt]

Thx @rgleason. Obviously you're right. Actually I have a good heading sensor, and even a spare one onboard. The test data I am using, however, hasn't got this value. That is because I only recorded some NMEA-strings. The NMEAConvertor plugin might work, though, sorry, I try to avoid using it. I spent hours and hours on it, 2 years ago, to get the work done and noticed it didn't work as I wanted to. Perhaps things have changed now, but I don't dare to rely on that while being out on the ocean.

Let's look closer at what HDT is being used for in the True Wind Calculation in tactics_pi. It is only used for calculating TWD. However, the part of the condition in line 4934 of the code I referred to in my previous post, causes that without HDT, the values for TWS and TWA are not calculated either.

We could change this easily, without introducing extra complexity. This would make the plugin more valuable to more people. And in case the HDT value might not be there, TWS and TWA are still calculated correctly.

The extra option I suggested is only for TWD, since in my case I prefer to use the COG for this, as some people prefer SOG instead of STW. The solution I suggested won't introduce significant extra complexity in the code, it's just a few extra lines.

Yes, I could fork, and make my own changes. Though, having the option in the plugin is a more future proof solution, and make more people benefit from it. So, thx again @rgleason I really appreciate your comment. I hope we can proceed in such a way that the code will be changed, and the option added. Hope to hear from @tom-r as well before spending time on the actual code changes. :-)

[rgleason]

Werner, I would like to share with you part of an email from Thomas. Thomas advises:

As [earlier written], it doesn't make sense to use COG instead of HDG.

To calculate true wind we need a course reference to the boat axis, as the wind instrument is aligned to the boat axis. And only the compass is aligned to the boat axis. As soon as you start drifting, COG goes somewhere unpredictable and will imply quite a big error into the whole calculation. And as you probably know of your own experience, we're always drifting. The more heel, the more current, the bigger the drift ...

Two simple examples :

1. Imagine that you sail across a river (current 90° to boat axis), SOG = 3kts, 3 kts of current. It's a simple triangle calculation what COG shows versus HDG. There's a 45° error ... That's way too error prone, how should we ever get a reasonable result ?
2. Opposed to that, it does make sense to use SOG instead of STW, because SOG eliminates any kind of current (waves pushing, etc). Imagine you sail directly up that river (current directly on the bow), 3kts of boatspeed, 3kts of current --> over ground, you don't move at all, but according to STW you do move with 3kts.

Concerning wind speed, all we really have is the apparent wind speed from our instrument. And apparent wind includes the "self-made wind" part from our own boat speed. To calculate it back to true wind, we have to remove the boat-speed-wind part.

If you calculate TW now with STW = 3 kts, it'll give you an error, as you really don't move over ground, but the calculation "removes 3 kts" to calculate the true wind speed ...

... I also suggest Werner to use the NMEA converter plugin ... BR, Thomas

Which is, I think, a very good explanation of the forces and factors at work. I will be interested in your thoughts about the proposed change, considering the above. Best Rick

[rgleason]

BTW, there are considerably more examples in the nemaconverter_pi wiki and quite a variety of uses. I do recall your earlier efforts and believe that there have been a few improvements since then. (You can look at the commits to see.) https://github.com/rgleason/NmeaConverter_pi/commits/master

Nemaconverter Manual

See TWA and TWA (right up your alley) https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:plugins:logs:nmea_converter#tws_and_twa

[pa2wlt]

Thx @rgleason very helpful again!

My main issue is that a Heading is only required to calculate TWD, not for TWS or TWA. However, without a HDT value, tactics_pi does not generate the TWS or TWA. That can easily be improved by changing a few lines of code. This won't add any complexity to the code. I already forked the module, and made the changes to test. I also managed to set up a development environment under Windows 10, which is quite a thing for a Mac-addict. I also created a package, though installation doesn't work yet, so I cannot test the new behaviour yet. I will keep you updated on this, and hope this improvement will make it into the plugin.

Then the HDT or the COG. Yes, you guys are absolutely right. HDT is better than COG. Though not in all cases. I experienced a situation where the HDT sensor was not sending out proper values anymore, perhaps due to lightning, not sure. In that case the COG value was still there. I do prefer the COG since that value is generated by a reliable Vesper AIS, and the HDT by a 30 year old instrument. So, I would be very happy with the extra option as suggested. Though, I'll first focus on the improvement above.

Regarding the nmeaconverter: Good to hear things might have been changed. I will only try this if I really really really can find no other solution. I already wasted too much time and effort on that. Apart from that, I honestly think that applying if-then-else, and cos-functions preferably are handled in sources (in this case).

[rgleason]

I also managed to set up a development environment under Windows 10, which is quite a thing for a Mac-addict. I also created a package, though installation doesn't work yet, so I cannot test the new behaviour yet. I will keep you updated on this, and hope this improvement will make it into the plugin.

Good work on the build of Win Dev Environment. Are you building the plugin inline or standalone? If standalone you will need to put opencpn.lib in the build directory.

Thanks for the improvements to the wiki about downloading. etc.

See your new branch here https://github.com/pa2wlt/tactics_pi/tree/improved_CalculateWind

[pa2wlt]

@rgleason Yep, that's where it is. While I was dowloading and installing the older Visual Studio I changed the code directly on GitHub.com, even before cloning it locally. I built the plugin standalone (don't know how to to that inline btw). And, yes, thx, I copied opencpn.lib into the build directory. The release package is there, with the changed sources. It seems to intall properly, however it does not show up in the list of installed plugins. So I am stuck for now ... No clue where to look or what to look for, since installation seems to go smooth. Maybe you have any suggestion.

I tried to install the package, and I also tried to just copy the tactics_pi.dll over the original one. Both options don't work, and the plugin doesnot show up in the list.]

I can think of 2 things. It might have to do with me developing on a Windows10-64 bit installation, whereas the default OpenCpn installation might be 32 bit. Or it might have to do with the SDK-version I struggled with. I ran into an error that a certain file wasn't found, that was part of the Windows SDK, but there were like 15 versions to choose from with the Visual Studio Setup. Trying the other 14 might cost 2 days...

So, my main question for now is what could I have to do differently to have the plugin showup in the list after installation.

[rgleason]

You are thinking of a .dll file. Do a search for .dll on the build directory.

Did you use the right opencpn.lib? It needs to be from Opencpn v5.0. Maybe this one will work. Rename to opecnpn.lib

opencpn-v500.lib.docx

[pa2wlt]

I gave it a try, though no luck. Still not showing up, and in the logfile the error

: Failed to load shared library tactics_pi.dll error 126: The specified module could not be found.

Many thx @rgleason for your help so far.

No clue how to proceed from here, or how to dive in to this error message. Any help would be appreciated.

[rgleason]

I'll try to build it for you.

[pa2wlt]

That is kind, though no need to do so. TransmitterDan already did so and it runs fine. I reckon my issue has to do with setting up the development environment. I am using Microsoft Visual Studio 2017. Whereas the online manual for the plugins is still referring to 2013. Too many options, to many things to do manually...

Op za 2 nov. 2019 om 21:59 schreef Rick Gleason notifications@github.com:

I'll try to build it for you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tom-r/tactics_pi/issues/29?email_source=notifications&email_token=AD45XMPUB233FQF7O5IHHU3QRXSZZA5CNFSM4G6QWQNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5E5GA#issuecomment-549080728, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD45XMMYYYE56TTSU5GCSDLQRXSZZANCNFSM4G6QWQNA .

[rgleason]

TDan has helped me a lot too. Do you have the correct wxwidgets? Which areas of the wiki are not clear? This section is for Opencpn v5.00 https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:developer_manual:developer_guide:compiling_windows#prerequisities

This section is for Opencpn v4.2 through v4.8.8 and wxWidgets v3.0.2 https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:developer_manual:developer_guide:compiling_windows#compiling_on_windows_to_opencpn_488

[rgleason]

Werner, Karmasailor has been editing the manual lately. Is that you?

If there is something you are not sure about leave a note like this in the wiki manual. %%FIXME%% FIXME (in Smilies button at the top) With a note & your name, you can use the signature icon --- //[[fcgleason@gmail.com|Rick Gleason]] 2017/01/17 17:05//

So that it can be identified for a fix. Thanks very much.

That is in the editor manual https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:developer_manual:edit_user_manual but it is a bit unwieldy.

[pa2wlt]

yep, we were working in the same file I noticed. had to roll back a few times. thx for the %%Fixme > didn't now how to do that. time to sleep, new day tomorrow. one day I'll succeed with that windows development environment. it costed me 3 days already, including installing Windows on the MacBook. where as the actual code changes were done within 15 minutes...

Op za 2 nov. 2019 om 22:52 schreef Rick Gleason notifications@github.com:

Werner, Karmasailor has been editing the manual lately. Is that you?

If there is something you are not sure about leave a note like this in the wiki manual. %%FIXME%% FIXME (in Smilies button at the top) With a note & your name, you can use the signature icon --- //[[fcgleason@gmail.com|Rick Gleason]] 2017/01/17 17:05//

So that it can be identified for a fix. Thanks very much.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tom-r/tactics_pi/issues/29?email_source=notifications&email_token=AD45XMPJBC4KGG5DC75IYJLQRXZBPA5CNFSM4G6QWQNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5F2PQ#issuecomment-549084478, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD45XMJB6P3BEHHW7JQKNVTQRXZBPANCNFSM4G6QWQNA .

[rgleason]

Nite. Sorry, about the time. I have similar experiences, but once setup it works usually...

I can think of 2 things.

1. It might have to do with me developing on a Windows10-64 bit installation, whereas the default OpenCpn installation might be 32 bit.

My machine is 64 bit Win10. I thought I installed 64 bit MS VS 2019 and then in a first opening screen, selected VS2017 which then added some other modules, but when I look at the actual VS2019 and VS2017 files they are located in the "C:/Program Files (x86)" directory which is 32 bit, so perhaps I remembered incorrectly.

2. Or it might have to do with the SDK-version I struggled with. I ran into an error that a certain file wasn't found, that was part of the Windows SDK, but there were like 15 versions to choose from with the Visual Studio Setup. Trying the other 14 might cost 2 days...

[pa2wlt]

Well, I managed to get the development environment up and running. Made a mistake with downloading the latest wxWidgets instead of 3.1.2. Improved the manual a bit, and started changing the code. In my version TWS and TWA are calculated now, even without TWS or HDT data. The calculations itself are precisely the same. I could lower complexity of the CalculateTrueWind unit as well. I will keep on experimenten for a while, then push the changes to my fork on GitHub. Thx for the help @rgleason @tom-r @Hakansv and transmitterdan.

[pa2wlt]

@tom-r Thx for your clear explanation. Makes perfectly sense. HDG is the right thing to use to calculate TWD and not the COG. No need to add this as an option in the Performance Parameter tab.

I made a mistake in my code with using the COG. I wrote my TrueWindCalculation while crossing from Recife to Tristan da Cunha, without having internet for examples. We didn't have to deal with such a thing as a 3 kt current and we had enough wind and boat speed. Later I noticed that without speed, the TrueWind shows incorrect values as well. That, however, was a minor issue, since I only use that TrueWindCalculation while sailing. With the HDG this issue will be solved as well. Thx again!

Apart from this, I'd like to see if we can use COG as a backup, when for any reason, the HDG is unavailable. My experience is that out on the open ocean everything can fail, also the HDG sensor. Only for that reason I'd like to have the COG as a backup, knowing that the calculated value then is less accurate. At least there will be a value then. Hope we can proceed that way.

In the process flow, I made a few changes in the code, to make the TWD and TWS-calculation more reliable. E.g. TWD and TWS can be calculated without having a heading. I will refine the code changes I am working on, and then share via the github fork and request for a merge.

Op za 2 nov. 2019 om 01:39 schreef Rick Gleason notifications@github.com:

Werner, I would like to share with you part of an email from Thomas. Thomas advises:

As [earlier written], it doesn't make sense to use COG instead of HDG.

To calculate true wind we need a course reference to the boat axis, as the wind instrument is aligned to the boat axis. And only the compass is aligned to the boat axis. As soon as you start drifting, COG goes somewhere unpredictable and will imply quite a big error into the whole calculation. And as you probably know of your own experience, we're always drifting. The more heel, the more current, the bigger the drift ...

Two simple examples :

1. Imagine that you sail across a river (current 90° to boat axis), SOG = 3kts, 3 kts of current. It's a simple triangle calculation what COG shows versus HDG. There's a 45° error ... That's way too error prone, how should we ever get a reasonable result ?
2. Opposed to that, it does make sense to use SOG instead of STW, because SOG eliminates any kind of current (waves pushing, etc). Imagine you sail directly up that river (current directly on the bow), 3kts of boatspeed, 3kts of current --> over ground, you don't move at all, but according to STW you do move with 3kts.

Concerning wind speed, all we really have is the apparent wind speed from our instrument. And apparent wind includes the "self-made wind" part from our own boat speed. To calculate it back to true wind, we have to remove the boat-speed-wind part.

If you calculate TW now with STW = 3 kts, it'll give you an error, as you really don't move over ground, but the calculation "removes 3 kts" to calculate the true wind speed ...

... I also suggest Werner to use the NMEA converter plugin ... BR, Thomas

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tom-r/tactics_pi/issues/29?email_source=notifications&email_token=AD45XMP4LVZUANOOWMNKVMDQRTD47A5CNFSM4G6QWQNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC4POZQ#issuecomment-548992870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD45XMPEXPB3M442NBZD5ZDQRTD47ANCNFSM4G6QWQNA .

[rgleason]

Werner, I tried to find the changes under your new branch. https://github.com/pa2wlt/tactics_pi/commits/improved_CalculateWind Have you made a commit of your changes and push them up to your remote repository Improved_calculatewind?

[pa2wlt]

I haven't yet. Still working on it to refine a few things.

Op zo 3 nov. 2019 om 17:35 schreef Rick Gleason notifications@github.com:

Werner, I tried to find the changes under your new branch. https://github.com/pa2wlt/tactics_pi/commits/improved_CalculateWind Have you made a commit of your changes and push them up to your remote repository Improved_calculatewind?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tom-r/tactics_pi/issues/29?email_source=notifications&email_token=AD45XMPQUDUMBH4XWM5JE2DQR3VVJA5CNFSM4G6QWQNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5XDEQ#issuecomment-549155218, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD45XMJGF2PYMGIKC2HIUB3QR3VVJANCNFSM4G6QWQNA .

[pa2wlt]

Consider it done. Code is on GitHub. Feedback = Welcome. It's my maiden-change in the OpenCPN (plugin) codebase, so obviously I can have made mistakes.

PS. I didn't make a proper branche yet.

Op zo 3 nov. 2019 om 17:45 schreef Werner Toonk wernertoonk@gmail.com:

I haven't yet. Still working on it to refine a few things.

Op zo 3 nov. 2019 om 17:35 schreef Rick Gleason <notifications@github.com

:

Werner, I tried to find the changes under your new branch. https://github.com/pa2wlt/tactics_pi/commits/improved_CalculateWind Have you made a commit of your changes and push them up to your remote repository Improved_calculatewind?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tom-r/tactics_pi/issues/29?email_source=notifications&email_token=AD45XMPQUDUMBH4XWM5JE2DQR3VVJA5CNFSM4G6QWQNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5XDEQ#issuecomment-549155218, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD45XMJGF2PYMGIKC2HIUB3QR3VVJANCNFSM4G6QWQNA .

[rgleason]

That is good Werner. Just a little pointer about using GitHub,

1. Keep your local and remote Master identical to the forked repository.
2. Always make your changes locally in a new branch forked from your master.
3. Always push your new branch up to your remote repository.
4. If you are going to make a PR to the forked master, make it from your new branch on your remote.

I can give you some guidance on how to fix this if you would like.

[pa2wlt]

made some minor changes, created a branch, tested and send out the pull request. https://github.com/tom-r/tactics_pi/pull/45 Hope this will work.

[rgleason]

Here is an interesting post showing several different calculations for TW Schnapsy: http://www.cruisersforum.com/forums/f134/plugin-dashboard-44087-4.html#post2991814 Hakan: http://www.cruisersforum.com/forums/f134/plugin-dashboard-44087-11.html#post2195418

Here is Fabbian's explanation of TW: http://www.cruisersforum.com/forums/f134/plugin-dashboard-44087-11.html#post2195586 Which corresponds with Terminology here

So, after reading Terminology in the Opencpn Wiki and Tactics Wiki, would you still call your calculation True Wind? What would be a more accurate name for this type of wind? Maybe it should be a new instrument with another name for the wind?

Would it be Ground Wind?

[pa2wlt]

Good to know @rgleason. Thx. I notice that discussions regarding True Wind calculation are all over the web, including the OpenCPN fora. We could (and preferably should) do that more efficient. I would like to add a page to developers manual wiki, and write down there the theory, what has been implemented and what not, and what future ambitions are. The Wiki we can change, so that it remains up to date. Can we give that a try? Not too sure if I can create such a page myself.

Regarding your question. Let's start with asking ourselves why the True Wind calculation is important for some at all. I can answer that for my case. I have 2 reasons for that. 1st is that my OpenCPN dashboard (the standard) has 3 instruments (for TWS, TWA and TWD) and a Wind history bar that require values for the True Wind. I like to have these instruments up and running, and register the history. Therefore I do want the values for True Wind. The second reason is that forecasts do use the True Wind (regarding speed and direction), and I like to compare the forecast with the actual conditions that I measure. That helps me to sail safely. Well, those ar the 2 reasons why I do want the TrueWind data in OpenCpN. Others might have more (valid) reasons.

Regarding the terminology there are plenty options. Ground Wind, yes, also: Earth Wind, Real Wind, Wind, Ocean Wind or just True Wind. Personally I couldn't care what name we use. As long as the instruments that show values for True Wind and the history bar will deal with it. Since the protocol being used is NMEA0183 and that protocol only has Apparent Wind and True Wind, I reckon there's only one option, at least in the NMEA stream, that is True Wind.

My Raymarine instruments only measure Apparent Wind, as all Wind-instruments on board of other ships do, I reckon. Values for True Wind are being calculated. My instruments do calculate TWS and TWA, though they unfortunately don't share the outcome of the calculations with my outgoing NMEA stream towards OpenCPN. The other disadvantage of the instruments, is that they date from the 80's when sailboats had no GPS. So the only value for speed that could be used was the STW. On some ships the value for STW is quite inaccurate. Because of the old sensor, the heel, the position, or any other reason. Fortunately today there is GPS and instead of using STW we can use SOG.

So, what I would like to do is modify any plugin that does something with True Wind, and make sure that the values for TWS, TWA and TWD are being calculated. Preferably sailors have the option to use STW or COG, and to have any relevant adjustment made automatically - where possible.

Well, let's first see if we could get that Wiki page up and running.

[rgleason]

Werner, Thank you.

I think your goals, generally are good. I just want to be sure we are all taking about the the same "wind".

1. As you know, we have different names for the measured wind. Apparent, True, Ground, etc.
2. Each time different parameters are used, the result changes and users are going to get very confused about what "True Wind" is, as defined. This also changes the recording and use of Polars.
3. There is no problem with improving the accuracy of "True Wind" so long as it does not change the definition. The traditional version of True Wind uses STW Speed thru the water, substituting SOG is ok and indeed, Tactics and Dash-T both have that option. (Under this option, there is a popup that states "Recommended. As True Wind blows over the Earth's surface, we should calculate it with Speed over Ground. Eliminates the influence of currents."

So already the definition of True Wind has changed. The words "Eliminates the influence of currents" is perhaps not precise enough. We both know that the only thing corrected for the "influence of currents" is the speed, not the direction. So now we have "True Wind" that is morphing to something else. Take it another step and I think we need a new instrument with a new name for the wind!

In short, this is a complex subject, beyond the interest of many users and we need to keep it simple. Therefore I would appreciate it if you would not change the "Terminology" definitions without first having a healthy discussion and agreement on line here or in the forum.

I think your idea for a dedicated page is good. I hope it will start very simple. Explain True Wind in the totally traditional version. Then step by step explain the options and the results. Perhaps we'll come up with some good specific names for these variations and maybe a new instrument.

Toward the lower half there is not reason the page cannot become more technical, getting into the various calculations and code.

Please give me a short title and suggest a good location for this page. Right now I am thinking that perhaps it should be a page underneath Terminology. I think you should also open a new Cruiser's Forum thread titled the same and we can link to it from the new page. Let me know and I will start the new page. It would be very nice to have this all in one place.

One final point, both Tactics and Dash-T are consistent. Dashboard is an older version that is not as accurate and has not been improved as much. There are instruments that aren't working properly and the history graphs don't work as well. It is restricted in the number of instruments it can handle. I am not so sure it is worthwhile fixing Dashboard at this point. I would probably favor simply using Dash-T.

BTW, I do care what name is used. I also care about the underlying calcs and parameters. It makes a difference. You would not find the America's Cup tacticians changing parameters and terminology indiscriminately.

[pa2wlt]

Thx. Let's start with a page 'True Wind Calculations' as a subpage under 'Terminology'. Yes, and we'll open a Cruiser's Forum thread with the same title then.

Thx for the advice regarding Dashboard. To me it's all fine. As a sailor, I do use Dashboard, since that the standard that OpenCPN comes with. I am unaware of any better alternative. As a programmer my goal is to improve any code where necessary, to make sure that True Wind is calculated as good as possible when it's not available. That coding ain't much work (when there is a working development environment, and I enjoy it).

Preferably I do that in such a way that the most users can enjoy the benefits of that, that's why I thought to start with Dashboard (now that tactics_pi has been done). More than happy to start elsewhere. Whereas it surprises me a bit. I see 2 options:

1. Either Dashboard_pi is part of OpenCPN and automatically installed on all machines where OpenCPN is installed, and as a community we keep it up to date and as accurate as we can.
2. If there's any more accurate, more advanced and better dashboard, the current dashboard in OpenCPN is replaced by that one and we keep that one up to date and as accurate as we can. Well, but that's another discussion.

Another issue is that with every copy, paste and modify action (as we do with these plugins), the maintainability of the codebase decreases. By using more of the features C++ offers, we could lower the volume and reduce redundancy of this part of the codebase significantly, and by smart refactoring we could as well lower unit size and complexity. Well, that might be another goal one day to work on. First get that True Wind Calculation all over the place.

[rgleason]

Werner, new page here: https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:terminology:true-wind

Hope this is the first of several calculation pages.

New page instruction: (in the url at the top, after "terminology" added ":true-wind" to create a new page. Then edited to make the title so the page would save. Then added the indexmenu notation for the order of the page. The last thing that I needed to do was create a blank page after "..terminology:true-wind:blank" and write "This page intentionally left blank". That forces the parent page into being a namespace.

Petri has really taken Dash-T somewhere and I agree that it should be incorporated. Maybe I should make an Issue under Opencpn requesting that. Will you support that request?

Would be very interested in how - "By using more of the features C++ offers, we could lower the volume and reduce redundancy of this part of the codebase significantly, and by smart refactoring we could as well lower unit size and complexity. Well, that might be another goal one day to work on"

[pa2wlt]

@rgleason thx I missed your response. Happy with it and will start working on the page.

Regarding Dash-T: if it does cover all functionality of dashboard_pi, then of course I will support such a request. As a community we should try to keep our codebase as maintainable (and therefore small) as possible.

Regarding your last question, see here: https://bobbelderbos.com/2016/03/building-maintainable-software/ Applying these 10 quality guidelines would help enormously. We could start by simply writing no functions (units) anymore that exceed 20 lines of code. Compare for example how CalculateTrueWind has been implemented here and here: 67 lines, versus 16. And 16 if-statements in one function versus only 1. Obviously there is way more to say about this, though that is a completely other topic, that deserves another thread.

[rgleason]

Fails to calculate true wind with some NMEA message combinations #2

Werner. I am going to be very direct and blunt. This title misrepresents the facts and does not explain what your issue is: The plugin does calculate true wind from STW and SOG. It does not calculate some new version of wind (called Ground Wind normally) with SOG and COG. You are trying to make this plugin calculate Ground Wind and to call it True Wind.

The title of this Issue should be changed. I don't believe Petri is going to make the change you desire, however you are able to fork the repository and make the changes you wish, but I would then call that wind "Ground Wind" which conforms to the Terminology page. I have written you with regard to these details before, but you seem to be ignoring those suggestions and addressing Petri directly.

[pa2wlt]

I think you misunderstand my comment, sorry for that. Please allow me to explain again what is going on.

True Wind refers to 3 values:

1. True Wind Speed
2. True Wind Angle
3. True Wind Direction You know where to find the definitions.

The plugin does calculate the first 2 (TWS and TWA) based on STW, SOG and heading, and does that correctly for certain NMEA-streams. For NMEA-streams without heading information, it does not calculate TWS or TWA, whereas for these calculations the heading is not being used in Tom's calculation (!). It is like saying: we cannot cook pasta, because there is no rice. Though, one doesn't need rice to cook pasta.

It's correct to say then that the plugin fails to calculate true wind with some NMEA-message combinations. Exactly as the title says.

Since the calculation itself is fine, and stays the same, we should call the result the same as well: True Wind, and nothing else.

For the third value, the TWD this is different. TWD requires a certain heading. My suggestion is to take into account that instruments might fail and stop sending out a heading. And for that case, and only for that case, my suggestion is that if the heading is unavailable, to use COG as backup (if available). Since then the-TWD instrument and the TW-history bar will remain working. Less accurate, but better than nothing. For me there is no need to give this any other name either, since we're talking about the True Wind Instrument and the True Wind History bar.

[rgleason]

Werner this is defined in terminology as "ground wind"

 And for that case, and only for that case, my suggestion is that if the heading is unavailable, to use COG as backup (if available). Since then the-TWD instrument and the TW-history bar will remain working. 

[ARF1]

Werner this is defined in terminology as "ground wind"

And for that case, and only for that case, my suggestion is that if the heading is unavailable, to use COG as backup (if available). Since then the-TWD instrument and the TW-history bar will remain working.

@rgleason I had configured this behaviour in NavMonPC. It was highly misleading and led to a lot of confusion! - It took me ages to figure out what the issue was...

At anchor when SOG is near zero the COG value has almost no relation to HDG. It generally shows the direction of sideward-drift of the boat.

If COG is then used for the calculation of ground wind, the user will be highly perplexed why the ground wind shown is quite obviously wrong. In my experience, errors of +-90° are frequent at anchor with this calculation method.

If you decide to use COG as fallback for the calculation of ground wind, it might a good idea to only fall back to COG if SOG is above some threshold value to filter out the spurious results at anchor.

[pa2wlt]

@rgleason Are we aligned now regarding calculating True Wind when there is no heading available? My 1st suggestion is to calculate the TWS and TWA whenever possible. Regarding the 2nd suggestion, shall I rephrase it then like this: Let the TWD instrument and the wind history bar display the Ground Wind if the True Wind is not available, as long as there is a certain speed.

@ARF1 Thx! Good suggestion to take a certain minimum speed into account for the 2nd suggestion, to avoid any misleading in the moored situation. My main focus for the 2nd suggestion is on ocean sailing (no anchoring) where the digital compass fails (e.g. due to lightning) and the GPS remains working. What I aim for is to make sure the TWD instrument and wind history bar will keep working in that case. Would this work for your situation:

1. If heading available use this to Calculate TWD
2. Otherwise if speed > 1.0 knt and COG available use COG to Calculate TWD (Ground Wind)
3. Otherwise no TWD calculation.

[rgleason]

Dear Werner,

No I am not at this point. I need to think about this more (yet again). I think there are to few involved in this discussion to consider it a concensus. https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:terminology Have you heard anything from the plugin authors Petri and Thomas? I believe you had some private discussions with Petri, If so, perhaps you can share what was the result?

With these instruments, users push to add or modify certain instruments and it (often/always) causes some other unanticipated problem that has to be addressed. Also, advanced users push for changes which complicate the instruments for average users who do not understand the differences. This is exactly where we are with these proposed changes. Without the plugin author's ear and support, I fear you won't go very far with this.

What I think was suggested was to fork the plugin and build what you want. Then submit as a PR, who knows, it might be accepted. As you know, Petri is in the process of closing his work on the plugin after a long test and improvement project.

I am not really the arbiter of these kinds of things. Sorry.

Best. Rick

[ARF1]

@pa2wlt Sounds good to me. Though this behaviour should probably be documented very well because users WILL be asking why ground wind calculation "does not work/breaks" when moored.

Regarding the threshold value: How fast a boat moves at anchor will depend on the boat type and wind speed. I really do not have a good idea which COG speeds are typical at anchor. Is it worth making the threshold a user-settable option?