mariokonrad / marnav Goto Github PK

This is missing in class mmsi.

mmsi::value_type mmsi::sar_id() const
{
	if (!is_sar_aircraft())
		return initial_value;
	return value_ % 1000;
}

There are few other related C++ projects.

https://github.com/raffmont/signalk-server-cpp

https://github.com/epsilonrt/piduino

https://github.com/SignalK/SensESP

Just as an idea.
I think using those (at least first two) it would be possible to create marine multiplexer server for pi which would support many types of sensors (in similar fashion to SenseEsp)
but connected directly to Pi instead of ESP32.

Unfortunately https://github.com/raffmont/signalk-server-cpp
is not actively maintained but it could be a core of such server (it is based on marnav)

Thanks

I am trying to copile this project with an Visual Studio 2017 compiler, but got an error on utils/bitset.hpp 148 line.

I'm trying to compile marnav under macOS High Sierra 13.10.6 with AppleClang version 9.1:
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
Just adding the following lines in CMakeLists.txt :
elseif("${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang")
message(STATUS "Compiler: AppleClang")
In ### compiler check solves the issue.
Unfortunately I had the following compiler error:

mmbp:build raffaelemontella$ make
[ 2%] Built target extern_gmock
[ 4%] Built target extern_benchmark
[ 4%] Building CXX object src/CMakeFiles/marnav.dir/marnav/nmea/name.cpp.o
/Users/raffaelemontella/dev/marnav/src/marnav/nmea/name.cpp:265:67: error: constexpr variable 'talkers' must be initialized by a constant
expression
static constexpr const std::array<entry, talker_id::num_talkers> talkers = {{
^ ~~
/Users/raffaelemontella/dev/marnav/src/marnav/nmea/name.cpp:266:3: note: non-constexpr constructor 'pair<true, false>' cannot be used in a
constant expression
{talker_id::none, "used for vendor extensions"},
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/utility:422:5: note: declared here
pair(_T1 const& __t1, _T2 const& __t2)
^
1 error generated.
make[2]: *** [src/CMakeFiles/marnav.dir/marnav/nmea/name.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/marnav.dir/all] Error 2
make: *** [all] Error 2

Any suggestion?

Hi,
I want to use the library with a standardized AIS equipment. When I use nmeatool to read data, checksum of some ALR packets is labeled with error as in the below

However, when i checked the raw serial data , it comes with white spaces in the sentence after (AIS:).

I figured out that the device calculates it with white spaces. What does the standard says about this character issue?

message text for this kind of message corrupting while encoding.
this code will result AIS SART ??????? string. decoding by over ais library do same result so reason in encoding part.
Compiler: Visual Studio 2015 x86

const char AisSartMessage[] = "AIS SART activated";
using namespace marnav;
ais::message_14 broadcast;
broadcast.set_mmsi(utils::mmsi(cs));
broadcast.set_repeat_indicator(IsRepeat);
broadcast.set_text(AisSartMessage);
auto payload = encode_message(broadcast);
{
auto message = ais::make_message(payload);
if (message->type() == ais::message_id::safety_related_broadcast_message) {
auto report = ais::message_castais::message_14(message);
auto messagetext = report->get_text();
assert(messagetext==AisSartMessage);
}
}

RMB does not have a status indicator. The last field before checksum is arrival status. Here is the format of the RMB sentence in the spec.

https://www.gpsinformation.org/dale/nmea.htm#RMB

This is the field I am referring to.

Hi,
Thanks for a great library.

What version of ctags are you using? Perhaps a comment about required version and a link to installation instructions could be provided?

Details

I'm trying to build the documentation using make doc on Ubuntu 18.04. The first error is

CMake Error at cmake/Documentation.cmake:20 (add_dependencies):
  The dependency target "tags" of target "doc" does not exist.

I find that the tags target is created by CTags.cmake, and the file indicates that i might be missing ctags and/or cscope

find_program(CTAGS_PATH ctags)
find_program(CSCOPE_PATH cscope)

if(CTAGS_PATH AND CSCOPE_PATH)
	message(STATUS "Found ctags: ${CTAGS_PATH}")
	message(STATUS "Found cscope: ${CSCOPE_PATH}")

, so I tried installing it.

sudo apt install ctags cscope

This gives me "Exuberant Ctags 5.9", but make tags (or make doc) outputs the error

ctags: Unknown option: --extras

Including doxygen and the proper ctags and cscope in your docker images could be a sufficient solution for me personally, as I'm only looking for a way to generate the documentation.

Hi,

Thank you for this really good library. I am using it to cast NMEA frames in my developments.

But, I encountered some troubles when I used it with my locale french computer. During NMEA parsing (from string to numerical values), a call to the std::atod is made to convert string to double. But this function depends on current locale and causes troubles and throws exception :

terminate called after throwing an instance of 'std::runtime_error'
what(): invalid string to convert to double: [250.5]

I had to modify my current locale by "std::setlocale(LC_ALL, "C");" to avoid errors. Is it possible to integrate this modification in your code?

Thanks again for your work.

VRI

Hi,
Fetching the value from a temporary utils::optional::value raises a compiler error:

// message is a const std::unique_ptr<marnav::ais::message_01>&
double rot = message->get_rot().value();

(...)/optional.hpp:106:27: error: cannot bind rvalue reference of type ‘double&&’ to lvalue of type ‘double’
  T && value() && { return data_; }

Inserting a std::move solves the problem:

T && value() && { return std::move(data_); }

I want to build up a multiplexing system, which writes AND receives messages from TCP (only write right now, but doesn't matter), NMEA-0183-Devices and one Seatalk-Bus.

I am able to receive seatalk messages (convert them to NMEA) and from NMEA-Devices.

The problem is, that i also want to WRITE to these buses. TCP is no problem.

But the examples (with default_nmea_reader or seatalk message_reader) only show message-receivers, but no writers. OR if there is a writer, it's is not a receiver.

Could you give an example how to do both?

When building marnav from the latest released package (0.8.0), marnav will fail to link the various generated executables. I'm on Ubuntu 18.04, with GCC7.

The error received is:
c++: error: -E or -x required when input is from standard input

Having a poke through the CMakeLists file, I can easily spot the issue (at line 30 from the packaged version):

### version handling
if(NOT ("${CMAKE_BUILD_TYPE}" MATCHES "Release"))
	set(PROJECT_VERSION "${PROJECT_VERSION}-${GIT_COMMIT_HASH_SHORT}")
endif()
message(STATUS "Project Vesion: ${PROJECT_VERSION}")

The git commit hash is missing as I'm using the packaged sources. Without ${GIT_COMMIT_HASH_SHORT} being set, the version gets set to '0.8.0-' which leads GCC to incorrectly think that I'm going to provide additional input from the terminal due to the trailing dash.

I now realise that this will only be a problem when using a non-release build type but as CMake defaults to not filling in the build type, I'm sure that I'm not the only soul who would hit this rather minor issue.

Thanks for your time.

On early stage of application running global variables created and call this code, but static dictionary for 6-bit encoding still not ready, so code gives corrupted data without any error. This minor level bug, but can affect on some situations. Maybe exception on try to encode on not ready dictionary needed.
class test
{
public:
test(){
using namespace marnav;
ais::message_14 broadcast;
broadcast.set_mmsi(utils::mmsi(cs));
broadcast.set_repeat_indicator(IsRepeat);
broadcast.set_text(AisSartMessage);
auto payload = encode_message(broadcast); //this data broken
}
}
test globalvariable;

hello and thanks for your neat works.
you've supposed that mmsi is 32 bit but there are 64 bit mmsi also.
I've tried to correct it, in utils::mmsi you've declared a type with name value_type, I changed it to u_int64 but in ais message classes (message_1,2,...) you've defined bitset<..., u_int32> mmsi, so conversion is cumbersome.

Safety Messages NMEA ammendement

MOB, SMV, SM1, SM2, SM3, SM4

http://www.nmea.org/Assets/20130816%20nmea%200183%20safetynet%20amendment.pdf

Examples:

$CSSM3,123456,005213,798,0,3,14,00,2012,04,05,14,30,3400,N,076,W,300*hh
$CSSMB,008,001,0,123456,FROM:Maritime Rescue Coordination Centre xxx^0D^0ATO:*hh
$CSSMB,008,002,0,123456, ALL SHIPS IN xxxxxxx^0D^0ASAR SITREP NO: 02^0D^0AFIS*hh
$CSSMB,008,003,0,123456,HING BOAT 'xxx' WITH THREE PERSONS ON BOARD DEPARRTED*hh
$CSSMB,008,004,0,123456, FROM xxx ISLAND ON^0D^0Axxx AT NOONTIME AND SINCE TH*hh
$CSSMB,008,005,0,123456,EN NO INFORMATION ABOUT HER. PARTICULARS ...^0D^0ASHI*hh
$CSSMB,008,006,0,123456,PS SAILING IN VICINITY ARE KINDLY REQUESTED TO KEEP A*hh
$CSSMB,008,007,0,123456, SHARP LOOK OUT^0D^0AINFORMING MRCC^0D^0AREGARDS^0D*hh
$CSSMB,008,008,0,123456,^0A DUTY OFFICER*hh
/g:1-9-1234*hh/$CSSM3,123456,005213,798,0,3,14,00,2012,04,05,14,30,3400,N,076,W,300*hh
/g:2-9-1234*hh/$CSSMB,008,001,0,123456,FROM:Maritime Rescue Coordination Centre xxx^0D^0ATO:*hh
/g:3-9-1234*hh/$CSSMB,008,002,0,123456, ALL SHIPS IN xxxxxxx^0D^0ASAR SITREP NO: 02^0D^0AFIS*hh
/g:4-9-1234*hh/$CSSMB,008,003,0,123456,HING BOAT 'xxx' WITH THREE PERSONS ON BOARD DEPARRTED*hh
/g:5-9-1234*hh/$CSSMB,008,004,0,123456, FROM xxx ISLAND ON^0D^0Axxx AT NOONTIME AND SINCE TH*hh
/g:6-9-1234*hh/$CSSMB,008,005,0,123456,EN NO INFORMATION ABOUT HER. PARTICULARS ...^0D^0ASHI*hh
/g:7-9-1234*hh/$CSSMB,008,006,0,123456,PS SAILING IN VICINITY ARE KINDLY REQUESTED TO KEEP A*hh
/g:8-9-1234*hh/$CSSMB,008,007,0,123456, SHARP LOOK OUT^0D^0AINFORMING MRCC^0D^0AREGARDS^0D*hh
/g:9-9-1234*hh/$CSSMB,008,008,0,123456,^0A DUTY OFFICER*hh
/g:1-9-1234,c:1333636200*hh/$CSSM3,123456,005213,798,0,3,14,00,2012,04,05,14,30,3400,N,076,W,300*hh
/g:2-9-1234*hh/$CSSMB,008,001,0,123456,FROM:Maritime Rescue Coordination Centre xxx^0D^0ATO:*hh
/g:3-9-1234*hh/$CSSMB,008,002,0,123456, ALL SHIPS IN xxxxxxx^0D^0ASAR SITREP NO: 02^0D^0AFIS*hh
/g:4-9-1234*hh/$CSSMB,008,003,0,123456,HING BOAT 'xxx' WITH THREE PERSONS ON BOARD DEPARRTED*hh
/g:5-9-1234*hh/$CSSMB,008,004,0,123456, FROM xxx ISLAND ON^0D^0Axxx AT NOONTIME AND SINCE TH*hh
/g:6-9-1234*hh/$CSSMB,008,005,0,123456,EN NO INFORMATION ABOUT HER. PARTICULARS ...^0D^0ASHI*hh
/g:7-9-1234*hh/$CSSMB,008,006,0,123456,PS SAILING IN VICINITY ARE KINDLY REQUESTED TO KEEP A*hh
/g:8-9-1234*hh/$CSSMB,008,007,0,123456, SHARP LOOK OUT^0D^0AINFORMING MRCC^0D^0AREGARDS^0D*hh
/g:9-9-1234*hh/$CSSMB,008,008,0,123456,^0A DUTY OFFICER*hh 
/g:1-9-1234,s:egcterm1,n:213,c:1333636200*hh/$CSSM3,123456,005213,798,0,3,14,00,2012,04,05,14,30,3400,N,076,W,300*hh
/g:2-9-1234,n:214*hh/$CSSMB,008,001,0,123456,FROM:Maritime Rescue Coordination Centre xxx^0D^0ATO:*hh
/g:3-9-1234,n:215*hh/$CSSMB,008,002,0,123456, ALL SHIPS IN xxxxxxx^0D^0ASAR SITREP NO: 02^0D^0AFIS*hh
/g:4-9-1234,n:216*hh/$CSSMB,008,003,0,123456,HING BOAT 'xxx' WITH THREE PERSONS ON BOARD DEPARRTED*hh
/g:5-9-1234,n:217*hh/$CSSMB,008,004,0,123456, FROM xxx ISLAND ON^0D^0Axxx AT NOONTIME AND SINCE TH*hh
/g:6-9-1234,n:218*hh/$CSSMB,008,005,0,123456,EN NO INFORMATION ABOUT HER. PARTICULARS ...^0D^0ASHI*hh
/g:7-9-1234,n:219*hh/$CSSMB,008,006,0,123456,PS SAILING IN VICINITY ARE KINDLY REQUESTED TO KEEP A*hh
/g:8-9-1234,n:220*hh/$CSSMB,008,007,0,123456, SHARP LOOK OUT^0D^0AINFORMING MRCC^0D^0AREGARDS^0D*hh
/g:9-9-1234,n:221*hh/$CSSMB,008,008,0,123456,^0A DUTY OFFICER*hh

Hello,

I use this marnav library to parse and to create nmea sentence. on my project.

Today, I observed a problem to generate an AIS message 1 sentence.
I have no problem to generate AIS sentence if the latitude and longitude are positive (respectively North and East) but if I try to set a West longitude, the sentence are create without longitude value... It is similar to generate a South latitude.

I check different version to set negative value but none works :

ais::message_01 pos_report;

pos_report.set_lon(geo::longitude{3.3118});  // work correctly
pos_report.set_lon(geo::longitude{-3.3118}); // ko
pos_report.set_lon(geo::longitude{3.3118, geo::longitude::hemisphere::west});  // ko
pos_report.set_lon(geo::longitude{-3.3118, geo::longitude::hemisphere::west}); // ko
pos_report.set_lon(geo::longitude{3,31,18, geo::longitude::hemisphere::west});  // ko

If someone has a solution, I'm interested :)

Thanks,
Ronan.

The "more example here" link in README.md yields a 404

Here is a sample type 1 message, which is parsed incorrectly.

!AIVDM,1,1,,A,15RTgt0PAso;90TKcjM8h6g208CQ,0*4A

The following website parses this message correctly.

http://www.maritec.co.za/tools/aisvdmvdodecoding/

Expected:

Longitude:123_23.7230'W
Latitude: 48_22.8980'N

However this library throws exception because it extracts longitude as 323.99704333333335

I have tested with a couple of systems and it seems that they do support ms (or at least decimals).
Should we add it here nmea::time ?

See gpsd documentation as an example.

The "more example here" link yields a 404

You're probably aware but I just wanted to make sure, I didn't see it in the source code:
NMEA has added a new sentence to the 4.10 spec for Man overboard.
$--MOB, blah, blah,blah,,,,,,0*2F

I know the whole legality of 'Reverse Engineering' a proprietary spec is tight rope to walk, derivative work, , but the technical bulletin I found from NMEA on the Man overboard sentence specifically states it's a public document if you want to research it.
"I specifically did not put a link to the document here to maintain your legal cleanliness"
It's easy enough to find...

Hope this helps, I only bring it up for completeness...

Cheers,
TR. Martin

Specs are here:

https://www.pentestpartners.com/security-blog/hacking-navtex-maritime-warning-messages/

Example:

Source messages look like this:

    $CRNRX,007,001,00,TD02,1,135600,27,06,2001,241,3,A,==========================*09
    $CRNRX,007,002,00,,,,,,,,,,========^0D^0AISSUED ON SATURDAY 06 JANUARY 2001.*29
    $CRNRX,007,003,00,,,,,,,,,,^0D^0AINSHORE WATERS FORECAST TO 12 MILES^0D^0AOFF*0D
    $CRNRX,007,004,00,,,,,,,,,,SHORE FROM 1700 UTC TO 0500 UTC.^0D^0A^0D^0ANORT*70
    $CRNRX,007,005,00,,,,,,,,,,H FORELAND TO SELSEY BILL.^0D^0A12 HOURS FOREC*16
    $CRNRX,007,006,00,,,,,,,,,,AST:^0D^0A^0ASHOWERY WINDS, STRONGEST IN NORTH.^0D*15
    $CRNRX,007,007,00,,,,,,,,,,^0A^0A*79

The syntax is as follows:

$CRNRX <number of lines in message>,<message identifier (B1B2B3B4)>,<line number>, <frequency>, <day of month>,<month>,<year>,<time in UTC>,<error rate> then a 2 byte XOR checksum

Preceded by ZCZC and terminated with NNNN

The Message Identifier is made up of

    B1: transmitter identity
    B2: subject indicator
    B3&B4: serial number of the subject indicator

Thanks

extend() method checks the capacity() of vector instead of size(). I have fixed this in my branch with commit 8115b4b but this branch also has Visual Studio 2017 changes so I can create clean pull request.

This issue is revealed by running the test-ais-sample which asserts on access beyond the size of the data vector in bitset from bitset(const_iterator first, const_iterator last) -> append() -> append_block() -> extend(). This bitset constructor already increases the capacity of the data vector and adds the data itself but for the remainder bits uses append() for some reason. Maybe this whole path should be refactored to just use the append()?

In ensure_checksum() of nmea.cpp we are calculating checksum and considering it as actual checksum. we are providing wrong information here, calculated checksum must be the expected checksum and actual checksum is the one we received from the message. in case if we pass a wrong checksum(34) and actual checksum is (44) we will be getting below message

checksum error: (actual:44, expected:34)

but it must be printed as

checksum error:(actual: 34, expected:44)

I have switched my CI builds to the current marnav codebase and it reveals a build failure specific to GCC12 on ARM64: https://app.circleci.com/pipelines/github/nohal/nsk_pi/13/workflows/89dce313-bcb0-4363-93ee-fae1205148e2/jobs/150?invite=true#step-102-4362

marnav::nmea::make_sentence should infer whether or not the string passed to it has checksum or not. Just check whether the string passed to it terminates with ",*..". This will make it easier to use and consistent with other NMEA parsing libraries.

Described here:

https://continuouswave.com/whaler/reference/DSC_Datagrams.html

More links:

See https://github.com/adrianmo/go-nmea/ (DSC, DSE)

https://www.cruisersforum.com/forums/f13/nmea-0183-sentences-dsc-dse-124887.html

https://continuouswave.com/whaler/reference/DSC_Datagrams.html

https://web.archive.org/web/20190303170916/http://continuouswave.com/whaler/reference/DSC_Datagrams.html

https://github.com/mariokonrad/marnav/blob/master/src/marnav/nmea/dsc.cpp

https://github.com/mariokonrad/marnav/blob/master/src/marnav/nmea/dse.cpp

Thanks

void rte::append_data_to(std::string & s) const
{
append(s, to_string(n_messages_));
append(s, to_string(message_number_));
append(s, to_string(message_mode_));

if (n_messages_) {
	for (uint32_t i = 0; (i < n_messages_) && (i < max_waypoints); ++i) {
		append(s, waypoint_id_[i].value());
	}
}

}
look like n_messages_ may not affect on waypoint output cout, if i not miss something.
Also look like format has differences, look like field RouteId missing:
//route send from navico maris ecdis sensor monitor(NMEA mode)
"$IIRTE,1,1,c,2,001,002,003,004,005*0F" "$IIWPL,4102.038,N,02900.753,E,001*6B" "$IIWPL,4102.449,N,02901.939,E,002*69" "$IIWPL,4103.268,N,02902.623,E,003*6B" "$IIWPL,4103.268,N,02902.623,E,003*6B" "$IIWPL,4103.268,N,02902.619,E,004*65" "$IIWPL,4103.820,N,02902.875,E,005*66" "$IIWPL,4103.820,N,02902.875,E,005*66"

here after "C" exists additional filed for route id

Hi
I have got problem to compile marnav tag 0.14 with GCC14

And I have had to add a line
#include
inside some src files :

/include/marnav/ais/binary_data.hpp
/include/marnav/nmea/checksum.hpp
/include/marnav/nmea/date.hpp
/include/marnav/utils/mmsi_country.hpp

I was on the way to propose a patch for this but I have discovered that you already did this for them in your commit from 2023/05/04

Since lots of linux distribution are switching to GCC14 I think a new tag would be useful (simpler than having to clone the source from your last commit)

Hoping this will help
Thanks for your useful job

Philippe

According to the spec origin wayPointId is before destination wayPointId. But these are swapped in the implementation.
Here is the spec.

https://www.gpsinformation.org/dale/nmea.htm#RMB

Here is the implementation.

Hi,

First of all thanks for providing nice library.

My GPS module feeds the lib with fallowing data:
"$GPGSV,3,1,09,09,74,265,,04,63,066,14,06,50,261,,03,32,123,31*7B"
As You can see SNR field is empty.

Because of uninitialized satellite_info (marnav/nmea/gsv.hpp) snr member has garbage value (252 in my case).

Please consider initialize satellite_info structure or change members type to optional.

Thanks.

Hi,
First of all, Thank you for the good Library 👍

I have a small question.

The return type of sog in the rmc sentence is utils::optional<units::velocity>. I think this by default converts the data into meter per second because of the to_base convertion in the basic dimention. But the data type of the sog variable is utils::optional<units::knots>. How can I get the sog data in knots?

"$IIMWV,30,T,1.85,M,A"

std::unique_ptr<sentence> mwv::parse(
    const std::string & talker, const std::vector<std::string> & fields)
{
    if (fields.size() != 5) <== This will be 4 without checksum
        throw std::invalid_argument{"invalid number of fields in mwv::parse"};

Hi,

Could You please check use case for from UT below. It is failing.
Probably because of falsely positive satellite_info structure.

TEST(MarnavNmeaTests, GsvGetSatEmptySats)
{
    auto sentence = marnav::nmea::make_sentence(
        "$GLGSV,3,3,10,83,11,003,,83,11,003,,,,,,,,,*64");
    auto gsvSentence = marnav::nmea::sentence_cast<marnav::nmea::gsv>(sentence);

    EXPECT_EQ(3u, gsvSentence->get_n_messages());
    EXPECT_EQ(3u, gsvSentence->get_message_number());
    EXPECT_EQ(10u, gsvSentence->get_n_satellites_in_view());

    {
        const auto sat = *gsvSentence->get_sat(0);
        EXPECT_EQ(83u, sat.prn);
        EXPECT_EQ(11u, sat.elevation);
        EXPECT_EQ(3u, sat.azimuth);
        EXPECT_FALSE(sat.snr);
    }
    {
        const auto sat = *gsvSentence->get_sat(1);
        EXPECT_EQ(83u, sat.prn);
        EXPECT_EQ(11u, sat.elevation);
        EXPECT_EQ(3u, sat.azimuth);
        EXPECT_FALSE(sat.snr);
    }
    {
        const auto sat = gsvSentence->get_sat(2);
        EXPECT_FALSE(sat.has_value());
    }
    {
        const auto sat = gsvSentence->get_sat(3);
        EXPECT_FALSE(sat.has_value());
    }
}

This function (marnav/src/geo/geodesic line84) only returns azimuths from -pi/2 to pi/2 rad because of atan function used instead of atan2.
It also returns a 0 distance for points on the same longitude (angles 0 and pi).

Hello
I'm packaging some marine programs for a Linux distribution (OpenCPN and its plugins)
For this we use our system libraries
I intended to package opencpn-nsk-plugin which uses marnav... as a BuildRequire
So I need to build and package marnav
And then problems appear :

• if I build and package marnav as it is in your source, I get conflict since our fmt version is different from yours
• if I try to build marnav upon a more recent fmt version it's not possible since two required headers don't exist anymore in recent fmt version : no more posix.h nor locale.h in fmt include (they still exist in your extern/fmt/include/fmt folder) (version6)

Would it be not to much difficult for you to use a more recent version of fmt ? for compatibility with recent linux distributions

Thanks for this
Philippe (filochard)