New Plugin NmeaConvertor

[rgleason]

We are going to need more detail to be able to repeat this. What is the line? If you are using a vdr file we need that. Also are you using just one ?

[rgleason]

Where is the question going?

[wholybee]

Originally Posted by rgleason

We are going to need more detail to be able to repeat this. What is the line? If you are using a vdr file we need that. Also are you using just one ?

I am using real NMEA data.
The line is:
$XXHDT,$IIVTG1,$IIVTG2

I Change it to:
$XXHDT,$??VTG1,$IIVTG2

As soon as I do that the output field in the window displays "nodata" and before I can change it back OpenCPN crashes.

Since I am able to compile this now (on both Windows and Mac) I plan to look at the source this evening after work. Maybe I can find something. I'm not a pro, but at least it is another set of eyes.

[rgleason]

wolybee, excellent. your sentence & use of wildcard looks good to me. Maybe Dirk has some thoughts. Great that you are using real data, we need that testing. Would it be possible to make a recording and attach it so I can try? AYC (at your convenience).

[wholybee]

Rick and Dirk,
Attached are 3 nmearecordings. The first two demonstrate issues with nmeaconverter_pi, and thus also include the converted sentences.

The third is a seperate raw recording that can be used for testing. Also below are links to .mov files of a screen recording creating the files. The first is demonstrating the crash when I use wildcards. The second demonstrates anomalies in the converted sentences.

Open nemarecord2.txt. Look at line 141. The string "noData" appears where there should be a numeric value. Next look at line 147. I sometimes see this error #IND0000

If you use notepad++, do a "find all in current document" for XX. You can see how it _mostly_ works, but sometimes creates bad sentences.

I also see sometimes in the edit window output string some of the math functions in the nmea sentence. Using the formula for TWS/TWA. I haven't been able to capture that in a recording yet, but it happens. Sometimes it crashes when it does, other times my dashboard TWA just goes to random directions. I will keep trying to find how to reproduce that, as it creates the most "ugly" results when it happens.

I just started looking at the code, just starting to see how it works. I have a ways to go, it's been 20 years since I looked at c++ Some suggestions:

For now, I would drop wildcard support. It is probably less useful because one can always open the nmea debug windows to see what is available. Unless you wanted to take data from multiple sources and use them both for some reason.

Functions should not be evaluated while typing in the edit window. I suggest an "apply" button, after which the function is checked for validity. If not valid, inform the user. Conversion of invalid functions while typing seems to be the source of many of my crashes. I've been getting around it with cut/paste.

After conversion, there should be a sanity/validity check of somesort. Numeric fields should not contain any text. How might dashboard or another plugin, or an autopilot respond to that? Perhaps noData could be replaced with a 0?

There should be a default precision. Does a wind direction need to be carried to 8 places? How might an instrument respond to that? But, you also need to be able to deal with lat/long.

A great solution would be a table of sentence formats. If the output sentence is in the table, format it to the correct precision, and data types. Also, while the format table might not fix the underlying bugs, I would at least prevent bad sentences with "noData", "#IND0000", or math functions bits in the output sentence.


https://www.dropbox.com/s/8mefyihy5d...crash.mov?dl=0
https://www.dropbox.com/s/o68htgy9fx...odata.mov?dl=0

[rgleason]

wholybee, thank you! This plugin is the basis for a very powerful tool, your suggestions are good.

Did you have checksum checked? I assume so. I wonder what those anomalies are from.

Here is an idea based on yours, Dirk may have some easier or better ideas.
1. An "Apply" button.
2. Perhaps two windows: an Input window where the formula is entered and a result window where there is a first example after hitting "apply" which converts the first instance of live data being input to Opencpn, and then the next when Apply is hit again.
3. Then there will need to be some Edit changes made to the formula again, hit apply, use the formula to convert the next instance that applies, and see the result, and do this until it looks right.
4. Then hit OK to run it.

Oh there is a problem with this, we are entering the formula into the Preferences section. Well its an idea.

I think I understand the purpose of the format table, but need to understand it better. Is it looking at the underlying nmea data stream and being created?

I am going to have to look at your report and files later, so I might have better questions later. Thanks!

[rgleason]

I've looked at both mov. and learned something. There are problems and that there is a display area (I must have forgotten that. I am going to have to get back to this later.

[wholybee]

An example table with a few entries:
"$XXMWV","%d,%s,%d,%s"
"$XXHDT","%d,%s"
"$XXGGA","%.4f,%s,%.4f,%s,%d,%d,%.2f,%.1f,%s,% .1f"

So, if the resultant sentence matched one of the 3 entries above, use the format string to output it. We would need to come up with a list of common sentences to include. Perhaps the table could be read from a file an advanced user could edit.

If the sentence was not found in the table, it could output it without formating, just as is done now.

[rgleason]

I see. Thanks.

[rooiedirk]

I think I fixed the chrashing/hanging. Is in github now. Work OK on my machine including the wildcards. See screenshot.

[rooiedirk]

@wolybee,
Did a quick test with your datafile (with the last code in git), and I don't see anything strange anymore.
As for the "nodata", this could happen if you have the setting for say every 1seconde a transmission, and if there was no new data coming in before that 1 sec was over.
So if you are using incoming data, you should use send after all data is refreshed.

[wholybee]

Excellent! Great job getting that taken care of.

From my testing, I would give the go ahead to move out of beta. I now have a reliable TWS/TWA. It doesn't seem to crash anymore, and the output is stable.

Some suggestions for version 1.1

I would consider removing the "noData" string. It creates an incorrect sentence, which should never happen, and could cause problems with other plugins or hardware. A sentence with missing data is valid, and happens in real life. So if the data is missing, I would suggest that the noData string not be inserted. As an alternative, set a noData flag and add an indicator showing that data is missing on the edit dialog.

I also looked at the code for quite a while last night.

A NMEA message starts $ or ! followed by 5 alpha chars. So you should never output otherwise. I would pad strings shorter than that at the beginning of the string. So, your example $test would become $Xtest. $HDT would become $XXHDT. Anything more than 5 chars should be truncated $ABCDEFG would become $ABCDE.

Rather than counting the number of digits after the decimal to determine precision, I would consider using a table of format strings as I mentioned earlier. I think it would be simpler. Just skip the whole process of counting and formating that you have now, instead look for the datatype in the table, and if it exists apply that format.

Again, thank you. I hope to see this out of beta soon.

[rgleason]

I've been testing nmeaconverter with

SART-Test-Sequence-Copie-Lepinard-ecrmb-ecapb.txt (attached)
played with VDRplayer started with Launcher_pi or VDR_pi

with these to see what the values were

• Nmea Debug Window (options>connections>check show nmea
• Tactics_pi
• Dashboard_pi

for each of the examples in the Nmeaconverter_pi Manual
and it appears to be working as expected.

I believe Dirk has asked that it be released. Windows version is here NmeaConverter_pi
Thank you wholybee and dirk!

[Schnapsy]

I tried to change the sentences of my old Furuno sounder ($SDDBT,0021.7,f,0006.6,M,003.6,F) with the following formula:
$IIDPT,$SDDBT3 with the last version...

As a result (copied with VDR) I get the following result :

$SDDBT,0021.7,f,0006.6,M,003.6,F
$IIDPT,noData*5D
$SDDBT,0021.7,f,0006.6,M,003.6,F
$IIDPT,noData*5D
$SDDBT,0021.7,f,0006.6,M,003.6,F
$IIDPT,noData*5D
$SDDBT,0021.7,f,0006.6,M,003.6,F
$IIDPT,noData*5D
$SDDBT,0021.7,f,0006.6,M,003.6,F
$IIDPT,noData*5D
$SDDBT,0021.7,f,0006.6,M,003.6,F
$IIDPT,noData*5D

Where is the error?

[rooiedirk]

I did try to get your sentence send from a VDR file. Didn't work, likely because there is now checksum.
If I have your DBT sentense also send from the converter it works as intended, and also if I connect my own sounder it works as it should.

$SDDBT,9.8,f,2.9,M,1.6,F*0B (from my echosounder)
$IIDPT,2.9*49               (from nmeaconverter)
$SDDBT,9.8,f,2.9,M,1.6,F*0B
$IIDPT,2.9*49
$SDDBT,9.8,f,2.9,M,1.6,F*0B
$IIDPT,2.9*49

I did however find a bug in the code causing a wrong/none checksum to never pass. Updated now in git.
Hope it does help.

Dirk

PS make sure that in OpenCPN connections the checkbox for "Control checksums" is unmarked, as it will block your sentence without a checksum.