NMEA Instrument emulation (streaming)

[RonSouthworth]

Originally Posted by RonSouthworth

Hi Rick

Thanks for the advise on wxFormBuilder. In working out compiler errors it was apparent very quickly that people had not kept the form for the given project up to date.

The header warns people not to do that very thing, however people have time constraints. So it happens.

The good news is formbuilder forms are an xml data structure. When you hit compile it creates the code....

I have worked out how to merge form projects and the really painful thing of getting the “display” where and how i want it / finally makes some sense. Usual fun with open source tools and cryptic bread crumbs.

I have some thoughts on a process to convert forms and the GUI code so the form builder can be used again. As i sat the to do list gets bigger

Form builder has the features to accomodate adding code blocks / plugins for form builder but working it out takes a lot of effort i think. I have persisted with it....


A lot of SCADA systems use a similar type of arrangement to get stuff happening

that is some sort of GUI to create the HMI human machine interface, you then have to write code underneath all of that, stuff like fortran COBOL and C++ and some really exotic languages and scripting engines so it is in many ways an all to familiar a process to me.

I have a first pass GUI worked out stuff probably to add to it to help debug features but the building blocks are all there for what i have in mind to do....

I have been working on the rudder indicating and messaging routines, and looking at porting my GPS emulation routines across lots to do


/Ron

Attachment 192815

BTW lots of quirks between OS behaviours

[rgleason]

Originally Posted by RonSouthworth

BTW lots of quirks between OS behaviours

Yes, exactly! For Windows, it has been generally not enough room in a field to see or enter data.

[RonSouthworth]

Hi Rick,

Recovering this version of Simulator has made me very happy. Bugs and features to be sorted and added respectively,

Actually since i started this message only one reported bug remains with it at present, to do with how leeway and current is simulated depending on the bearing of the vessel to the water surface current direction, the vessel doesn’t always drift in the direction it should be....

Updating the satellites in view routines so it uses the XOR function, a first step to adding U/I adjustability across the codebase.

Working out what instrumented messages to include

/Ron

[rgleason]

Ron I like what you're doing.


There are some things you might be able to use.



1. how to normalize degrees greater than 360 (nmeaconverter_pi)

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



2. How tactics calculates and uses current and leeway might be helpful.
https://opencpn.org/wiki/dokuwiki/do...ailing:tactics

[RonSouthworth]

Originally Posted by rgleason

Ron I like what you're doing.


There are some things you might be able to use.



1. how to normalize degrees greater than 360 (nmeaconverter_pi)

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



2. How tactics calculates and uses current and leeway might be helpful.
https://opencpn.org/wiki/dokuwiki/do...ailing:tactics

Thanks Rick for the feedback

I think It is a good demo tool.

That was what it was scoped to be originally.

I will have a look at the normalising routine and the other reference links.

My intention with the bug fixing i am doing on this and review process is to compare my formulae with things like the tactics plugin so you read my mind. It is well commented the tactics plugin btw.

This morning I have incorporated code for simulating a rudder angle sensor and it is working with $IIRSA and $TIRSA type messages with two sensors or one zero and scale adjustment can be a handy thing on meters


I will presently sort out my set and drift issue.

That will make it pretty much all the items I scoped for it originally, maybe a simple depth instrument message.

I would rather create a fish finder simulator ....

I think all the other bugs are pretty much sorted apart from some compiler warnings (which are painfully cryptic but will have to be sorted eventually).

All this is helping me to be able to propagate other things that in reviewing what i can do with it, what i want to do i think it will make it more versatile as a test suite and stand alone multi platform one at that

I do have a big thing about end to end instrumented value accuracy and data assurance.

Decimals are there in the protocol specification for good reasons,
OpenCPN there are a lot not displayed.? Reminds me of the object standards and lamenting documentation.


/Ron

[RonSouthworth]

Stand Alone Version progress

/Ron

[rgleason]

That is looking pretty darn good Ron. It will be a useful tool.

[RonSouthworth]

Hi Rick,

Thanks

The simulator is coming together nicely, Sorted out the bug with set and drift. Instrumented have a means to set a set-point. No forward reverse selector


The WGS84 spherical model is what i am intending to sort out next with this program.

To add more instrumented values on the U/I or features without making the frame any bigger is going to mean some work, Nearly finished off the old project.


The forum cloud backend seen here is not at all happy breaks the app completely ive seen there are some packages people are interested in having included. Hopefully get them up on the repo today once I finish testing a bit more.

[rgleason]

Ron, you might want to take a look at canne's repository for dashboard-tactics, he's been making some improvements.


https://github.com/canne/dashboard_tactics_pi


also good discussion in the tactics thread.

[RonSouthworth]

Originally Posted by rgleason

Ron, you might want to take a look at canne's repository for dashboard-tactics, he's been making some improvements.


https://github.com/canne/dashboard_tactics_pi


also good discussion in the tactics thread.

Hi Rick have been trying to follow the threads on the forum

has been broken here for a few days. Asia area cloud errors a plenty

Iy is looking good like the new features

He’s interested in having pitch and roll sensor sentences. Combining that into a leeway calculation sounds like some math fun.

Happy to test more

/Ron

[rgleason]

Ron, perhaps this will help, with ais or the links?
https://github.com/doron2402/ais-protocol-decoding

[RonSouthworth]

Originally Posted by rgleason

Ron, perhaps this will help, with ais or the links?
https://github.com/doron2402/ais-protocol-decoding

Thanks Rick,

Re AIS

Like most things it is just a matter getting my head around it .... I will get there

Sorting out the java GUI, Pitch and heel input sliders to add then the back end code to think about.

Happy with it so far.

[RonSouthworth]

Originally Posted by Canne

Hi Ron, I fetched your PoC commit and tested it on Win10 Ov50. I got it running! Or almost, there were two major issues: a) in run-time I still got this disappearing dialog issue I already reported but I managed to get it under control when executing using opencpn.exe as debugger(!): here, every time I clicked somewhere else than on the dialog, the window went hiding behind the O main screen! Once restored on the front, I managed to get it running, but b) the font is totally unreadable so I have no idea what I am clicking. See below screenshot.

Attachment 194114

Great job, it can be seen from your screenshots! I am looking forward to use it in some unit tests of active instruments of Tactics. Keep on committing into your repository as often as you like!

Thanks Canne

I’m happy to call it a proof of concept, to me the upload to the repo last night achieves that personal project goal.

All thanks to Mike and ship driver i have been able to fairly easily port stuff from java thus far and get something working.

Using that plugin as a base for this project has made it a lot easier to develop something quickly.

Never will claim to be a programmer, however i understand a few programming languages so I can do enough to get something working with a bit of effort. Thankfully as an electrical engineer, protocol test tools are something I have developed over the years. I am very slow at writing code just the same. Stuff isn’t falling out from the sky


That said I will look at the colour selections you have used with the dashboard_tactics plugin and amend the GUI to those I think unless i receive different advise, see if the amendments cross platform helps with further updates. I am using standard c++ code any shortcuts that i have seen in the base code etc i will follow as best i can.

The GUI should all be set to stay in the foreground I will check to see that something hasn’t changed. That might be a windows wxWidgets override specific thing.

I have merged a lot of XML for using wxFormBuilder so anything is possible to have crept in along with some issues with the corrupt / pre release versions of wXWidgets and XCode frameworks (sigh).

I will write up a basic how to start into the documentation - also uploaded with the snapshots.


For now.....
——————-


Think of this plugin as having an autopilot feel about it.

Press Start,

to start the code.

Stop to stop the code...

The indicator backgrounds change colours to show state and highlight emergency stop

the first time you press start on app startup it loads up the grib plugin.

If the grib plugin is already loaded it is all set.

You need valid grib data and to be on a heading not in irons for wind and movement from wind

You have to select a location to start from, selected from a right click menu option on the map.

There is a polar performance xml file. I renamed it LoftyPerch.xml. It is the name of the last firm i worked for full time...
a good name for a cyber vessel

potentially not a very realistic cruising yacht performance envelope but it makes things faster at times summs up lofty nicely.

Auto makes the step buttons work.

E.g. -1 -10 +10 +1

Later on the Auto button will be more of an autopilot emulation selection and use the autopilot tab menu items.

Standby drops out of auto. Rudder adjust always works.

throttle works when not in grib mode and isn’t locked out.

Pressing the grib button sets throttle to zero.

Setting throttle to any value when in grib has no impact on speed at the moment but i may alter this to vary the SOW depends on how the U/I develops.

The rudder angle setting is always active It is granular so it lets you set up a vessel out of trim

the button below the dial >|< will centre out the helm setting.

The indicators only display when there is a angle change to the respective helm, port / starboard.

Only the bearing / speed indicator next to the start button works and the rate of turn indicator on AIS is displaying angle (not ROT yet) but it is working as well and the instrument messages use the angle info.

The port throttle only works not the starboard one. Eventually i will add some code to use the two engines to steer and some dynamics to simulate steering by engines and the impact of a stuck rudder etc.

In the interim the port engine might be used as a setpoint for the the SOW value.

If you don’t press stop or cause a message loop fallback, the plugin continues to run.

The grib button needs to be pressed to start reading the grib wind speed data and for wind data to be produced. The GPS data is sent as soon as the plugin is started.

The grib button colour changes with different logic state conditions helps to know why there is no movement or wind.

E.g. in irons invalid grib data etc.


———————



I plan to propagate that data source for a few dynamic parameters in the mix for the long term using some data from other plugins.

A lot of API hooks for me to figure out,

some stuff to port into shipdriver to thank Mike so he can sail his plugin to the Bahama’s

I might rename that grib button to Dynamic once i have a means to select and dial up settings with the U/I. Some more changes on the U/I more tabs. Some additional settings to incorporate into the GPS tab.

The U/I is basically constructed to show the direction of the tool interface and useage.

I want it to be as easy to use as is possible. Some of the commercial test tools apart from being windows only have so many features that it overwhelms people I am certain. Even saying that there is just a lot of things with automation and marine is no different. Two more messages to add!

/Ron

[Canne]

Originally Posted by RonSouthworth

I’m happy to call it a proof of concept, to me the upload to the repo last night achieves that personal project goal.

I was referring to your commit name only; happy to sync my fork and test again whenever you like!

One more issue I found out later on: when the plugin is disabled, OpenCPN ov50 starts OK but when one opens the O plugin dialog, it crashes. I had to uninstall / reinstall the plugin.

BTW, in Windows 10, your installation program creates an entry in the install/uninstall control panel for the plugin like for a standalone program. This is not how other O plugins are doing - they merely create an unistall-**.exe in the OpenCPN program folder and only O appears in the "program install/unistall". I don't know if there is a style guide for this in O?

Talking about protocol testing, I am a user of network, PCIe and other serial protocol analyzers and testers (HP) and from the software unit test point of view, one can argue that an external device (the computer+SW is the unit to test) or at least independent software unit (opencpn.exe is the unit to test) would be the best for the active calculations unit tests.

However, plugin-to-plugin test with a controllable and stable NMEA-stream will be still way much better for unit tests than the recorded NMEA with VDR (which is useful for final functional tests). So please keep up going!

Originally Posted by RonSouthworth

That said I will look at the colour selections you have used with the dashboard_tactics plugin and amend the GUI..

Sorry that I cannot help you with the GUI color schemes, it is not my cup of tea. I just forked the Dashboard and all the good cross-platform behavior is inherited from there. It works also well in the night-color-modes! Copying from there is not therefore a bad idea.

Originally Posted by RonSouthworth

Think of this plugin as having an autopilot feel about it...

Thanks for the user guide! That's sure very useful.

Originally Posted by RonSouthworth

There is a polar performance xml file. I renamed it LoftyPerch.xml.

Hmmm... Tactics is still using .pol polar performance file (maybe there is room for improvement) and I see that your plugin, polar plugin and weather routing plugin of Sean d'Epagnier are using XML. Well, I have both, but are they compatible with yours? Should I take my boat's XML-polar file (the same I use in weather routing) and override with it your LoftyPerch.xml?

[RonSouthworth]

Originally Posted by Canne

I was referring to your commit name only; happy to sync my fork and test again whenever you like!



One more issue I found out later on: when the plugin is disabled, OpenCPN ov50 starts OK but when one opens the O plugin dialog, it crashes. I had to uninstall / reinstall the plugin.



BTW, in Windows 10, your installation program creates an entry in the install/uninstall control panel for the plugin like for a standalone program. This is not how other O plugins are doing - they merely create an unistall-**.exe in the OpenCPN program folder and only O appears in the "program install/unistall". I don't know if there is a style guide for this in O?



Talking about protocol testing, I am a user of network, PCIe and other serial protocol analyzers and testers (HP) and from the software unit test point of view, one can argue that an external device (the computer+SW is the unit to test) or at least independent software unit (opencpn.exe is the unit to test) would be the best for the active calculations unit tests.



However, plugin-to-plugin test with a controllable and stable NMEA-stream will be still way much better for unit tests than the recorded NMEA with VDR (which is useful for final functional tests). So please keep up going!



Sorry that I cannot help you with the GUI color schemes, it is not my cup of tea. I just forked the Dashboard and all the good cross-platform behavior is inherited from there. It works also well in the night-color-modes! Copying from there is not therefore a bad idea.



Thanks for the user guide! That's sure very useful.





Hmmm... Tactics is still using .pol polar performance file (maybe there is room for improvement) and I see that your plugin, polar plugin and weather routing plugin of Sean d'Epagnier are using XML. Well, I have both, but are they compatible with yours? Should I take my boat's XML-polar file (the same I use in weather routing) and override with it your LoftyPerch.xml?

Polar plots I have found about 3 styles of file layout file type is either xml or CSV so some way of converting between would be handy I think. I intend to add a file select in the config menu. I found an open source repo of plot data i will post the link when i am back in the office p

Being able to select message types on the fly and static setting of the setpoint s is my first target.