NMEA Instrument emulation (streaming)

[RonSouthworth]

Hi
Petrie

Yes it is the “own ship data” i am referring to. not the tactics plugin.

Something isnt quite right with using the simulator at the moment for testing the tactics plugin but it is with my stand alone test program. I think i know what it is.

Something fundamental with GPS simulation ...

I believe it actually is important that the spatial geodic point being transmitted in messages (above the water surface) is reported by “the GPS simulator routines” as accurately calculated as is possible, that the co-ordinates be offset by the influences dialled up.

Ideally and especially for accurate GPS position info the simulation should use the geoid system WGS84 model as a spherical reference,
Even so a smooth sphere model does have a reasonable degree of accuracy, the actual impact to not using this model usually is less of an impact than the effects that happen because of “the intentional dilution of precision”.

This is something to address on my to do list for both pieces of software as I would like the simulation to be as accurate as is possible.

Negating that influence to
Position, The simulator plugin wind data does have some vector math for calculating applied wind from true wind. I have to check accuracy however the numbers being sent are being displayed on the tactics dial are the same as what is being dialled up and “xmitted” so I tend to think the math is ok.

I am aware that the tactics calculations don’t utilise the set and drift message type directly. Maybe a future option for the really serious tactician ? The logic being any remainder will in theory be due to actual leeway or variations due to weather influences to sea state —> onto the vessel movement over the water ?

There are a number of instrument solutions (e.g. Garmin) that do provide this message type, at the very least they offer to calculate and display this data in the main numerical processor.

What i have found is that the calculated values being displayed in the tactics displays agree closely with the simulated set point values I use in my stand alone simulator, the set and drift values in the plugin are not.

that has to be because the positional info isn’t being correctly offset at present for the impact to flow onto the calculation and show up correctly.

I am also aware the VMG calculations and display of such values are routed via different means depending on the source and configuration of a given plugin, and that O supports a defined set of message types.

The original design of my stand alone plugin required the use of set and drift and I have found that message type to be extremely handy.

Some good news for me is that thanks to a less fuzzy head today and a opportune pause in the studio work and with more Thanks yet again to Mike

I have worked out how to interface with the formbuilder created GUI for utilising check boxes how that needs to be coded, I have working selection of GPGSV select and deselect via the configuration page (atm) An updated PoC has been loaded up.

I hope to sort out a version of windows on my old mac mini studio computer today after I back it up so I can play around with form builder under windows. this will be the next planned update to the project for me to produce something workable for folks using windows as well as macOS.

With that piece of the puzzle understood I can reach the first
Goal i have set for it and hopefully this point will make it useable for any test cases with the tactics plugin. That will make me a very happy chap...

/Ron

[Canne]

Originally Posted by RonSouthworth

Something isnt quite right with using the simulator at the moment for testing the tactics plugin but it is with my stand alone test program. I think i know what it is.

Ok, I will not complain then...

Originally Posted by RonSouthworth

Ideally and especially for accurate GPS position info the simulation should use the geoid system WGS84 model as a spherical reference

Agreed.

Originally Posted by RonSouthworth

The simulator plugin wind data does have some vector math for calculating applied wind from true wind. I have to check accuracy however the numbers being sent are being displayed on the tactics dial are the same as what is being dialled up and “xmitted” so I tend to think the math is ok.

Ron, I think we have a fundamental problem here. We need to get it straight before we continue: I plan to use your plugin to produce elementary NMEA sentence set up by a dial. Then I use those sentences to verify the correctness of Tactics active (calculated instruments).

Now, you are using Tactics to verify the accuracy of your own maths!

This does not make sense. Not at all.

Maybe our objectives are totally opposite?

Can you please clarify - IMO you can do whatever maths you like (if you are simulating a real boat I guess you need a lot) but if you do, those math'ed sentences should not go to into the system the maths are tested, like Tactics! With the exception of GPS, which is crucial for the SOG and COG so you need to get those maths right but verify them with something else but with O plugins!

Originally Posted by RonSouthworth

Tactics calculations don’t utilise the set and drift message type directly. Maybe a future option for the really serious tactician ? The logic being any remainder will in theory be due to actual leeway or variations due to weather influences to sea state —> onto the vessel movement over the water ?

I explained previously the "signal" path of OSD in which this data is. Let's recall it here, shortly:

<nav.system> -> O -> Fix() -> plugin-call-back() -> Dashboard -> Tactics

The core problem: O does not add drift and fix from OSD into its "fix" data structure (or at least it does not distribute them to plugins in the call-back function).

That is why Dashboard never knows about them. That's also why Tactics cannot use them even if it would like to.

Could I fix it? Yes, by making Dashboard to analyze all incoming OSD sentences and extract this data and making this data available in the Dashboard's existing Own Ship Instrument (see previous post).

Would I do it? Hmmm... a big question. This would make it my Dashboard and not that of O, in which Dashbaord is embedded in the distribution. A dangerous path to take. I need to think about it.

Supposing that set and drift would be there in the Dashboard's Own Ship instrument. Would a Tactician or the solo racer look at it? Like Garmin, NKE regatta processor or any other make can give all the the data necessary and they can be visualized on cockpit displays. It would be nice indeed that he has the data displayed down under on O. So I would vote +1 to show the set and drift data coming from the upstream.

But it would be Dashboard which is showing it, not Tactics, which is the "regatta processor". Thomas has developed his algorithms, among them Leeway to calculate drift cause by the wind (cf. manual section 2.2) . So maybe he will look at it, instead?

But for the average Joe, we are showing two instruments: Dashboard's Own Ship showing "Drift" coming from the boat navigation computer and Tactics' Leeway meaning also drift but most probably with a different value. This will be highly confusing and generate lines and lines of help messages in this forum which needs to be answered.

I am already regretting that I put Dashboard and Tactics together. Thomas did it, in a smaller scale but now, even better it becomes clear: people cannot make the distinction between the boat instrument data and active, calculated values. Now, when we add into the soup the boat's navigation computer and it active, calculated values the forum will explode from questions "why I don't have the same values here, do something"!

Never mind, Ron, for your plugin: be the boat's navigation computer by all means and put drift and set into the OSD sentence. This way, you can advance and its downstream's problem what to do with these values.

Originally Posted by RonSouthworth

What i have found is that the calculated values being displayed in the tactics displays agree closely with the simulated set point values I use in my stand alone simulator, the set and drift values in the plugin are not.

Oh, it starts already!

Let's not get stuck with this.

Originally Posted by RonSouthworth

...play around with form builder under windows. this will be the next planned update to the project for me to produce something workable for folks using windows as well as macOS.

Don't forget Linux, Raspberry Pi 4 is out - it is an amazing piece that can run my boat without me onboard!

Cheers,

Petri

[Canne]

Ron, I am writing now test plans for Tactics active functions in Test Management for GitHub, JIRA, Jenkins, and Selenium - TestQuality - yet another on-line resource available for free for public GitHub projects. I start with the dead simple one, true wind calculations, use case is simple enough. For test cases I need to describe the settings of the test tool, the procedure to use it and the expected results which either PASS or FAIL. You know this, pretty boring stuff. But necessary.

I know you have issues but I tried to understand how I can use your tool in this test procedure. I can see that there could be something I can use but I cannot create test cases for steps needed since I don't understand them myself!

In this screenshot I use what I think is the tool for me: Static (?)

1. There are two 'statics', the tab is to set it up, and the button to start it (I guess?)
2. There are two columns of variables (they have different background on windows, btw)
3. In the middle there is a selector which I can understand but which is not so easy to associate to the abbreviations used in the left and right colums
4. But whatever I do, I can see but some GPS values, depth sentence and some XDR sentences like barometer going out

Furthermore,

1. When I look to the tab XDR...
2. ...I see a column of selectors which makes me puzzled, they look promising but a) what they doing here in XDR-tab and b) I don't see any effect at all, anyway.

What do you think, would it be possible to achieve what I need quite rapidly now to test the TW calculations? I need SOG (from O's fix = GPS), alternatively STW from VHW, AWA/AWS and AWA unit from MWV, and true heading, which can be HDG sentence or composed of magnetic heading and variation (in which case they come from O's fix).

All variables Tactics algorithm gets from Dashboard. What is tested is Tactics algorithm. Quite simple, nothing can go wrong. (Sure, but want a test report.)

Best regards,

Petri

[Canne]

Ron, I created you a pull request in GitHub - just a small fix to see how it works.

[Canne]

Two issues which I cannot resolve myself added in the repo as to be resolved. Let me know when you need testing help (before our corresponding repositories will deviate too much).

[RonSouthworth]

Hi Petri,

My intent with the tool is to build in essentially two “modes” that each instrumented value / message operates with.

1 “Statically” for direct test and calibration of instrumented values.

- The number you dial on the set- point(s) for a given parameter is what is sent.

and

2 Dynamically where the software simulates what an automation equipped vessel would produce as a value dependent on the total data set of the sim.

I am aiming for the defaults to be so someone with a basic understanding can use the tool to check out OpenCPN

Hope that clears up any concerns you may have.


At the moment it is not completely configurable for each parameter to be user configurable to either mode, so it is a bit in both camps but that will sort it self out hopefully in the nest week if i have spare time of course

All a work in progress of course however I think I have all the building blocks With the latest update, one GPS message needed the mag var “flag” sorted (E/W)


Still sorting out a windows box to sort out the wxWidgets cross OS GUI issues I see a couple of issues logged overnight

[RonSouthworth]

Originally Posted by Canne

Ok, I will not complain then...

Agreed.



Ron, I think we have a fundamental problem here. We need to get it straight before we continue: I plan to use your plugin to produce elementary NMEA sentence set up by a dial. Then I use those sentences to verify the correctness of Tactics active (calculated instruments).



Now, you are using Tactics to verify the accuracy of your own maths!



This does not make sense. Not at all.



Maybe our objectives are totally opposite?



Can you please clarify - IMO you can do whatever maths you like (if you are simulating a real boat I guess you need a lot) but if you do, those math'ed sentences should not go to into the system the maths are tested, like Tactics! With the exception of GPS, which is crucial for the SOG and COG so you need to get those maths right but verify them with something else but with O plugins!



I explained previously the "signal" path of OSD in which this data is. Let's recall it here, shortly:



<nav.system> -> O -> Fix() -> plugin-call-back() -> Dashboard -> Tactics



The core problem: O does not add drift and fix from OSD into its "fix" data structure (or at least it does not distribute them to plugins in the call-back function).



That is why Dashboard never knows about them. That's also why Tactics cannot use them even if it would like to.



Could I fix it? Yes, by making Dashboard to analyze all incoming OSD sentences and extract this data and making this data available in the Dashboard's existing Own Ship Instrument (see previous post).



Would I do it? Hmmm... a big question. This would make it my Dashboard and not that of O, in which Dashbaord is embedded in the distribution. A dangerous path to take. I need to think about it.



Supposing that set and drift would be there in the Dashboard's Own Ship instrument. Would a Tactician or the solo racer look at it? Like Garmin, NKE regatta processor or any other make can give all the the data necessary and they can be visualized on cockpit displays. It would be nice indeed that he has the data displayed down under on O. So I would vote +1 to show the set and drift data coming from the upstream.



But it would be Dashboard which is showing it, not Tactics, which is the "regatta processor". Thomas has developed his algorithms, among them Leeway to calculate drift cause by the wind (cf. manual section 2.2) . So maybe he will look at it, instead?



But for the average Joe, we are showing two instruments: Dashboard's Own Ship showing "Drift" coming from the boat navigation computer and Tactics' Leeway meaning also drift but most probably with a different value. This will be highly confusing and generate lines and lines of help messages in this forum which needs to be answered.



I am already regretting that I put Dashboard and Tactics together. Thomas did it, in a smaller scale but now, even better it becomes clear: people cannot make the distinction between the boat instrument data and active, calculated values. Now, when we add into the soup the boat's navigation computer and it active, calculated values the forum will explode from questions "why I don't have the same values here, do something"!



Never mind, Ron, for your plugin: be the boat's navigation computer by all means and put drift and set into the OSD sentence. This way, you can advance and its downstream's problem what to do with these values.

Oh, it starts already!



Let's not get stuck with this.



Don't forget Linux, Raspberry Pi 4 is out - it is an amazing piece that can run my boat without me onboard!



Cheers,



Petri

Been waiting for the news on the release, going to get a couple of these.

[rgleason]

Petri In Tactics is there a decent way to show that a value is "calculated" (from available instrument and other data -heel table etc)?

Is it still true that Dashboard shows only instrument values? It seems to me that a couple of values are "calculated". Should users know when they are calculated?

Would that help with set and drift calcs in Dash?

[RonSouthworth]

Originally Posted by rgleason

Petri In Tactics is there a decent way to show that a value is "calculated" (from available instrument and other data -heel table etc)?

Is it still true that Dashboard shows only instrument values? It seems to me that a couple of values are "calculated". Should users know when they are calculated?

Would that help with set and drift calcs in Dash?

Hi Rick

I know there are two locations on dials that are identified as derived values

at first on my old monitor with macOS it looked like a minus sign.

There is a value identified in each of the tactics dials that have a tilde.

The current speed and direction for example is one set of values that has no indication it is a calculated value.

When the options to force calculate are used maybe those values can have a flag as well?

I have changed the flag on my local version to a unicode approx equals if you recall...

There are the usual issues with unicode formatting maybe Petri has a thought on how to use a unicode value all platforms will be happy with ?


/Ron

[RonSouthworth]

Hi Petri,

The GUI layout is evolving so apologies for the confusion that comes from the documentation not being finalised yet.


Next time I am in the office hopefully i can set up a windows os and check out the gui with windows version of form builder. That is my next step unless you need something changed / implemented to help test.

I have typed out a summary a few times now on what is working sadly the forum has hiccupped each time I have tried to post it, the typing has been lost

So

Selection boxes work only on the plugin preferences page.

With the upload this morning my time the boxes that are active on preferences page are selected on by default can be used, hopefully as I add things that will make it easier to see what is implemented.

The static values tab is what I have been working on implementing first.

The other tabs are more for dynamic operation in any case at the moment except the helm tab.

The helm tab only has the port engine control operating

dual engine control is on my to do list.

The rudder angle control is always active once the simulator is running regardless of being in autopilot mode or not.

Only the bearing and speed is displaying and on the AIS the rudder angle is displayed but it is not a rate of turn value yet. More POC stuff.

The button directly below the rudder angle sets the rudder to midships. A slider can be used here however I wanted a very granular control input and this was the easy quick way to have that granularity.

The +/- 1 , 10 buttons work only when autopilot is “on”.

The grib button toggles activating the grib data for setting the true wind value and. The SOG and STW values are based upon reference to the polar plot and calculation at the moment.


The values that are adjustable on the static page at the moment are

Rudder angle - reads the rudder angle from the helm supplies a port and starboard sensor value message

Barometer

DBT

Pitch and Heel

Water and Air temp

Set and Drift

HDM

The HDM sets the mag variation value which is used globally.

The remaining values the aim is to implement as dialogue code
is created for static operation.

Message types implemented are identified in the readme with a sample generated message. all are enabled/disabled via plugin preferences.

I posed some instructions for rick and they apply as far as the process is to get it started.

I don’t know why the plugin window goes behind on windows OS on linux and macOS it is always on top.

Some sort of wxwidgets thing to look at for me

Hope this helps


/ Ron

[Canne]

Originally Posted by rgleason

Petri In Tactics is there a decent way to show that a value is "calculated" (from available instrument and other data -heel table etc)?

Originally Posted by RonSouthworth

I know there are two locations on dials that are identified as derived values

at first on my old monitor with macOS it looked like a minus sign.

There is a value identified in each of the tactics dials that have a tilde.

Yes, that's the indicator (curiously in Mac, in Windows/Linux is shows as planned ^ (caret) -prefix). I have put the Tactics functions (not instruments, in fact) at the end of the list behind the Dashboard instruments, you may have noticed. There are warnings all over the Tactics settings dialog. It should be clear but is not.

Originally Posted by RonSouthworth

The current speed and direction for example is one set of values that has no indication it is a calculated value.

This is a good example! The current is always, in a moving boat a calculated value! (Maybe at standstill, one can use an instrument but there is not such in my boat at least). If it comes from the navigation computer or regatta computer it is not shown by Dashboard. Now, Tactics acts as regatta computer and makes the calculation. What a mess it would be if we show the values both from the navigation computer and from Tactics!

Take it like this: I have the opportunity to have a free regatta computer with Tactics in O. If I'd had money, I would buy one from NKE.

Originally Posted by rgleason

Is it still true that Dashboard shows only instrument values? It seems to me that a couple of values are "calculated".

Not that I know. Apart the historical tendency graphs where there is some smoothing by averaging, no Dashboard shows what comes in NMEA sentences. Of course, for speed values it calls back O to ask it to convert the NMEA value to the unit value user has selected in the O settings. That's the only arithmetic I know in Dashboard.

On the contrary, Tactics is all about calculation (like a regatta processor) - in the tactics_pi is not so evident to make the difference since it happily mixed with some Dashboard instruments by renaming them as Tactics_something. In dashboard_tactics_pi I carefully kept all original Dashboard instruments and finally what was left from Tactics is the remarkable work of Thomas, in four clear modules which all contain trigonometry, arithmetic and algorithms.

- - - - - - -

You know that in this domain of calculated values, a) people disagree, b) there can be errors even if people agree upon the formula to use.

Now, what seems to be the spirit here, is that let's mix in this soup also the values from the upstream calculated values: Voilà, la soupe est prête! But it is going to be maybe too spicy to eat...

Originally Posted by rgleason

Should users know when they are calculated?

They should read the excellent documentation that Thomas has written. But since today even less than yesterday nobody reads the documentation, it should be evident from the GUI. How to do that, is beyond my skills and time I can spend on this.

Originally Posted by rgleason

Would that help with set and drift calcs in Dash?

I can do such a modification in Dashboard, at NMEA sentence reception and in the Own Ship instrument in two hours.

But I do not want to do it, at least not alone. It should be done in O, from where the Own Ship data is already coming into Dashboard. Raise an issue in O and let's see what happens - maybe it is already there but just not distributed to plugins - I don't have time to start digging O code now.

Originally Posted by RonSouthworth

I have changed the flag on my local version to a unicode approx equals if you recall...There are the usual issues with unicode formatting maybe Petri has a thought on how to use a unicode value all platforms will be happy with ?

My advice is to forget the _T() wxWidget macro which is officially deprecated by wxWidget since years and does not guarantee anything, anyway. For normal text use "text", if you want to get it translated, use ("") wxWidget macro - avoid putting special characters in this case. If you have doubts about special characters, present them with a unicode espace sequence in hex, like suggested in https://github.com/scadaperspective/...or_pi/issues/6 : "\u00B0". You get more codes here: Unicode Character Search

Best regards,

Petri

[Canne]

Ron, I see you keep committing and committing those .DS_Store files. I have a pending pull request for you which is now broken by a ".DS_Store" file. Unnecessary annoyance. We are definitely moving away from each others repositories. I will not be able to start third time from scratch, or every time you need a test, it is too much asked.

Please consider fixing the collaborative workflow first by avoiding pushing .DS_Store files and answering my pull request, thanks!

[RonSouthworth]

Originally Posted by Canne

avoiding pushing . DS_Store files and answering my pull request, thanks!

Sorry Petri

I will amend the git ignore today before any more commits and answer the PR

Still having disturbed sleep and a lot of interruptions to the day and a lot of time to convalesce healing well which is good, downside is it stops my train of thought real bad and not much productivity.

Found a heap of little things that crept in because if being interrupted mid thought and fixed them.

Should get some uninterrupted time to finish the studio upgrade and then i can focus on this project for a while unless my storage solution is delivered, not expecting it till next month


/Ron

[Canne]

Ron, from Tactics forum: "degree º sign" of forms: oops be careful, this - I think - is causing the Windows showing it strangely. I suggested above to us \u escape for unicode of the same. Is it possible in the form builder? If it takes the unicode, you should use it not cut and paste on Mac, or Mac keyboard. That makes it portable across the platforms. I hope...

[RonSouthworth]

Originally Posted by Canne

Ron, from Tactics forum: "degree º sign" of forms: oops be careful, this - I think - is causing the Windows showing it strangely. I suggested above to us \u escape for unicode of the same. Is it possible in the form builder? If it takes the unicode, you should use it not cut and paste on Mac, or Mac keyboard. That makes it portable across the platforms. I hope...

Hi I have taken the easy/quick route for now and replaced it with Deg

Noted on testing to go to github at this point in the process.


Rick is the plugin staying on top for you or does it drop to the background as it is for Petri ?