New Plugin NmeaConvertor

[daveNZ]

Checksum question.
This sentence in the Preferences dialog box.....
$GPRMC,000532.39,A,3649.13831,S,17445.94387,E,0.00 ,33.4,240320,,E,A
results in that sentence with checksum '*39' being appended sent from OpenCPN.

But checksum generator https://nmeachecksum.eqth.net/ gives a checksum of *09

Any ideas? (I've checked the sentences are 'the same' and don't have the extra space)

[rooiedirk]

Two points. In your sentence above there is a space after the 0.00. Second the plugin is removing the leading zero's from the first number.

[daveNZ]

thanks. I had removed the space in the NMEAconvertor dialog box (but forgot to check in this thread) but the removal of leading zeroes explains the difference in checksum, and I hadn't noticed that.
many thanks.

[rgleason]

For future checksum questions, there is an page of Online Nmea tools
https://opencpn.org/wiki/dokuwiki/do...l:online_tools

[Dsanduril]

Just for reference, the space after the 0.00 is an artifact of this forum. In the posted version the forum software places a space after any "word" (continuous string of characters) that is > 50 characters. This space won't/doesn't exist in the edit box, only in the final post. I opened a thread about it with forum help, not much/anything that can be done.

This drove me nuts for probably a year. Bottom line, when debugging long NMEA sentences here on CF, anyone working with a posted sentence must remove the space character at the 51st position in the sentence (and presumably out at 100 as well, but I haven't encountered that).

[Edit] maybe I shouldn't be so categorical, it could be browser related although I have tried 5 different browsers. And it could be related to the way NMEA sentences are built. Either way, for many/most, posting a sentence > 50 characters results in a space in the final post.

[bcn]

You might want to use the code brackets in this cases when citing NMEA outputs

[code....  

[/code....

Instead of "...." use the closing square bracket "]"

[Dsanduril]

Here's a quick test.

$GPRMC,000532.39,A,3649.13831,S,17445.94387,E,0.00,33.4,240320,,E,A

$GPRMC,000532.39,A,3649.13831,S,17445.94387,E,0.00 ,33.4,240320,,E,A

Plaintext:
$GPRMC,000532.39,A,3649.13831,S,17445.94387,E,0.00 ,33.4,240320,,E,A

Indeed, the code box seems to work Although getting every user having problems with NMEA to know to use it...

[bcn]

The code box will avoid the conversion of characters into smileys as well

[arnolddemaa]

Hello,
My available GPS shows no magnetic variation in the Nmea line $NRMC. I do need this to control the outdoor repeaters. Opencpn now also has a table with variation. Unfortunately I don't know how to read this in the Nmea converter. Fortunately, the connected H5000 computer also has such a table. And it correctly sends out $SDHDG. HDG contains the correct magnetic variation. So I made the following line:

$XXRMC,$GNRMC01,$GNRMC02,$GNRMC03,$ GNRMC04,$GNRMC05,$GNRMC06,$GNRMC07,$GNRMC08,$GNRMC 09,$SDHDG04,$SDHDG05,$GNRMC12

It seems to work correctly:
Input:
- $GNRMC,121750.000,A,5149.5290,N,00407.1208,E,0.00, 196.04,230420 ,,, D*77
- $SDHDG,237.0,,,1.2,E*30

Output:
$XXRMC,121750.000,A,5149.5290,N,407.1208,E,0.00,19 6.04,230420,1.2, E,D*77

The problem is that the leading zeros are missing at the position coordinates (00407.1208 -> 407.1208). This gives a wrong position for position applies that 5 digits must exist for the point.

Question is it possible to do something with a format or as a solution to make the filtering of the leading zeros adjustable.

Greeting,
Arnold de Maa

[bcn]

The standard states for lat:

Fixed/variable length field:
degrees/minutes and decimal – three fixed digits of degrees, two fixed digits of minutes and a variable number of digits for a decimal fraction of minutes. Leading zeros always included for degrees and minutes to maintain fixed length. The decimal point and associated decimal fraction are optional if full resolution is not required.

[arnolddemaa]

Originally Posted by rooiedirk

@Tico,
You could try:
$ECWCV,$ECRMB12,N,int($ECRMB5)
Not sure however if it will work, and you will loose the leading zero's

No sorry I need the leading zero's it is an position coördinaat

[rooiedirk]

I just added some code to fix the leading zero problem. The bad news is, that you need to be able to compile your own version of the plugin.
https://github.com/RooieDirk/NmeaConverter_pi


The plugin looks now if a number starts with a "0", and if so the number of digits before the "." is used in the output. If a formula with more numbers is used the max no of digits is used. So ..... 0.23*0001 .... will output 0000.23.

The same trick works for the decimals. ... 0.23*1.0000 ... gives 0.2300

[arnolddemaa]

Originally Posted by rooiedirk

I just added some code to fix the leading zero problem. The bad news is, that you need to be able to compile your own version of the plugin.
https://github.com/RooieDirk/NmeaConverter_pi


The plugin looks now if a number starts with a "0", and if so the number of digits before the "." is used in the output. If a formula with more numbers is used the max no of digits is used. So ..... 0.23*0001 .... will output 0000.23.

The same trick works for the decimals. ... 0.23*1.0000 ... gives 0.2300

Thank you for the quick respons. The problem for me is the compiling. Maybe there is an other person who want to compile this nice piece of code for me. I use Windows 10 on my maritieme pc.

Best Regard Arnold

[CarCode]

Originally Posted by rooiedirk

I just added some code to fix the leading zero problem. The bad news is, that you need to be able to compile your own version of the plugin.

What about an icon for nmeaconverter_pi?

[bcn]

Dirk...


please take into account that following the NMEA0183/IEC61162 standard the leading zeros in the case of lat (four digits) and lon (five digits) are mandatory.

(I confused lat with lon in my previous post)


Example RMC

$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxxxx,x.x,a,a,a*hh<CR><LF> 

......

Leading zeros always included for  degrees and minutes to maintain fixed length. The decimal point and  associated decimal fraction are optional if full resolution is not  required. 

What I don't know if you can catch this from the plug-in or if the user shall take care using the implemented work-around.


Hubert