Beta Test / Technical

[Hakan]

Originally Posted by stevead

Hakan,

I'm refering to the NMEA 183 libraries that are used by OpenCPN. Look in the libs folder of the OpenCPN repository.

I would assume that every other plugin developer would use he same libraries, just for convenience's sake.

While FAA Mode is handled by the rmc & rmb classes, it is not handled in the xte class.

What I'm saying is that a plugin developer would naively assume that the whenever they parse a rmc, gga or gll sentence using the same NMEA 183 libraries that are used by OpenCPN, that they would expect that the positions are correct. They aren't. If you look in the opencpn chart1.cpp source, you will notice that even opencpn has to reparse a lat/long,

Naturally the lat/lon data according to the NMEA0183 standard has to be parsed to fit navigational use. The OCPN NMEA0183 libs are of course according to that standard. What's the problem with that? Is there something I don't understand?

[CarCode]

Originally Posted by Hakan

Naturally the lat/lon data according to the NMEA0183 standard has to be parsed to fit navigational use. The OCPN NMEA0183 libs are of course according to that standard. What's the problem with that? Is there something I don't understand?

I guess he means there is more than one NMEA file set used. As far as I can see there is e.g. one set in the main OpenCPN sources and another set in the dashboard_pi sources and they are different. Why?
Furthermore they are old and outdated. Modern GPS devices are e.g. able to transmit with 10 Hz and can use different talker IDs like $GA, $GB, $GL, $GN and not only $GP for GPS. It is time to cleanup this and update the NMEA file set to the actual standard version which is already 2 years old too but still not fully supported by OpenCPN.

[dominig]

Hello,


our boats last long and our electronic equipment are often more than 10 years old. Keeping an updated Linux on old platforms is a complex already on PC but on embedded platforms (non PC) it's a nightmare.
A new Marine Linux distro project is coming out to the public public this Dec 20, it's dedicated to marine requirements. It's a derivative from Automotive Grade Linux and the prototype was presented at CES in Jan 2020 and benefit from all development financed by car manufacturers in development tools and security.
NMEA 2000, 183 and CAN are supported natively as well as Linux OpenGL apps and Android Apps.

The Distro is maintianed for Intel and ARM architectures. A few ARM based private individual accessible low cost industrial boards are supported.

https://vimeo.com/390351628


A webinar is coming soon. Here is the announcement.



As Marine requirement is very very close of any IoT (very) long term Linux requirement with high level of security and application isolation, I thought that this webinar from the Linux Fundation might be of interest to some of you...

• The 16th december 17:00 (CET)
• Free Registration https://www.automotivelinux.org/even...e-grade-linux/

The Marine Grade Linux project by IoT.bzh addresses smart ship provides a customized flavor of AGL that addresses marine specific requirements. For signaling, NMEA2000, CanOpen, Ethercat and Modbus were added. Cloud connectivity is designed to handle random connectivity with a balance of 4/5G and satellite data link. Some core marine services as nautical charts, safe routing, or radar are still under development and should be added in the near future. Last but not least, a 30 years old ship is pretty common and maintenance/update on 15 years is required.

This presentation exposes the outcome of the three marine projects IoT.bzh is currently developing for this industry. It starts exposing gaps in business models, then exposes some of the technical specificities (signaling, SOTA, LTS, …). Finally it introduces redpesk@sea the ready-to-use “Marine Grade Linux” version that IoT.bzh will propose as Christmas gift to the maritime open-source community.
-- Dominig ar Foll Senior Software Architect
OpenCPN packager for Linux OpenSUSE

[rgleason]

Thanks Dominig. Two more specific links from that:
Redpesk-Marine Version Blueprint
Matrix Communications -What they are using for communication


This seems to be using Fedora / Centos. How is it different from any other flavor of Linux?
or is it yet another?
Redpesk appears to be wrapping github into its interface/process?


I see OpenCPN and Openplotter are listed, which is nice.

[stevead]

Originally Posted by Hakan

Naturally the lat/lon data according to the NMEA0183 standard has to be parsed to fit navigational use. The OCPN NMEA0183 libs are of course according to that standard. What's the problem with that? Is there something I don't understand?

If you've looked at the source code for the OCPN NMEA0183 libs, then you would understand. Clearly, you haven't looked at the source code.

[dominig]

This seems to be using Fedora / Centos. How is it different from any other flavor of Linux?
*RESP*

Redpesk is based on Fedora/Centos packages. Centos packages are maintained during 10 years for a given base. That s is the longest maintained distro available for free.
Redpask also reuse their building tool (Koji). Fedora at the opposite provides very early support of the latest and newest but not for long term.


Redpask provides some key differences:
- it runs on embedded boards (ARM based) where the BSP is only provided via Yocto. That is not the case for Centos.

- a security model based on Smack which is lighter that SE Linux or AppArmor and so better adapted to small (low cost) system.
- an integrated micro services model inherited from Automotive Grade Linux which ease development of applications split on several ICU (or boards) or shared with section running in the cloud. The transport changes to be lighter when used internally or fully OpenAuth/Json based when connecting the cloud or incompatible HW architecture. The APIs remains the same what ever transport is used.
- support of multizone sound system, voice priority (to auto stop music to play and alarm) and voice recognition.

- integrated debug tools and IDE supporting the micro services architecture
- out of the box support for CAN, NMEA 2000, NMEA 183. The are seen as micro services connection points removing the requirement to interpret the message out of the application. The license model allows to to support non public message type if required (frequent in automotive industry)



Redpesk appears to be wrapping github into its interface/process?
*RESP*
NO. interfaces process are wrapped in micro services which are run in isolation using namespaces. When connection to micro services comes from outside the ICU, OpenAuthecation2 can be activated. The set of API and the middleware take care of that hurdle for you.



I see OpenCPN and Openplotter are listed, which is nice.[/QUOTE]
*RESP*
If you look at he demo done at CES, OpenCPN is the demo navigation application.
This is why I dereved a new OpenCPN for Fedora port a few months ago from my OpenSUSE release. The build tools are not the same (Koji/OBS) but the process is very very similar and based on rpmbuild.

[bdbcat]

stevead....
More, with specifics, please.


Thanks
Dave

[stevead]

Dave,

Perhaps you've forgotten why you added the following function in chart1.cpp ?

static bool ParsePosition(const LATLONG &Position)
{
    bool ll_valid = true;
    double llt = Position.Latitude.Latitude;
    if( !std::isnan(llt) )
    {
        int lat_deg_int = (int) ( llt / 100 );
        double lat_deg = lat_deg_int;
        double lat_min = llt - ( lat_deg * 100 );
        gLat = lat_deg + ( lat_min / 60. );
        if( Position.Latitude.Northing == South )
            gLat = -gLat;
    }
    else
        ll_valid = false;
.....

The above corrects the error in nmea183/sentence.cpp

double SENTENCE::Double( int field_number ) const
{
 //  ASSERT_VALID( this );
      if(Field( field_number ).Len() == 0)
            return (NAN);

      wxCharBuffer abuf = Field( field_number).ToUTF8();
      if( !abuf.data() )                            // badly formed sentence?
        return (NAN);
      
      return( ::atof( abuf.data() ));
      
}

which is called by lat.cpp & long.cpp

void LATITUDE::Parse( int position_field_number, int north_or_south_field_number, const SENTENCE& sentence )
{
   wxString n_or_s = sentence.Field( north_or_south_field_number );
   Set( sentence.Double( position_field_number ), n_or_s );
}

which is called by latlong.cpp

bool LATLONG::Parse( int LatitudePositionFieldNumber, int NorthingFieldNumber, int LongitudePositionFieldNumber, int EastingFieldNumber, const SENTENCE& LineToParse )
{
   Latitude.Parse(  LatitudePositionFieldNumber, NorthingFieldNumber, LineToParse );
    Longitude.Parse( LongitudePositionFieldNumber, EastingFieldNumber, LineToParse );

which is initially called by any of the classes that parse a sentence that contains a position (eg. rmc, gll, gga) For example rmc.cpp

Position.Parse( 3, 4, 5, 6, sentence );

The problem is that any developer who uses the NMEA183 libs would naively assume that

NMEA03::Rmc.Position.Latitude.Latitude

returns a double value that is a valid position. it doesn't. It needs to be further parsed to obtain the correct value.

A possible fix is to add an additional function to sentence.cpp

// Added to parse positions correctly
double SENTENCE::DecimalDegrees( int field_number ) const
{
 //  ASSERT_VALID( this );
      if(Field( field_number ).Len() == 0)
            return (NAN);

      wxCharBuffer abuf = Field( field_number).ToUTF8();
      if( !abuf.data() )                            // badly formed sentence?
        return (NAN);
      
      // Convert a NMEA 183 position string like 13549.345 
      // which actually means 135 degrees 49.345 minutes
      // to the correct double value 135.8224 (decimal degrees)

      double value = ::atof( abuf.data()) / 100 ; // 135.49345
      int degrees = trunc(value); // 135
      double minutes = ((value - degrees) * 100) / 60; //0.8224
      return degrees + minutes;
      
}

and to make the corresponding changes to lat.cpp and long.cpp

void LATITUDE::Parse( int position_field_number, int north_or_south_field_number, const SENTENCE& sentence )
{
   wxString n_or_s = sentence.Field( north_or_south_field_number );
   Set( sentence.DecimalDegrees( position_field_number ), n_or_s );
}

the consequence being that this would break any existing uses.

And for xte.cpp, the bug is quite obvious.

NMEA0183_BOOLEAN check = sentence.IsChecksumBad( 15 );

notwithstanding the omission of the FAA Mode indicator field.

But I digress, my original gripe was the problem with the invalid links encoded in the shell scripts used to download the necessary packages for building plugins using the continous integration services (circleci, appveyor etc.).

Rule #1. Don't break the build.

[bdbcat]

stevead....
Thanks for the explanation.
The original NMEA0183 libraries are indeed getting a little creaky with age. The various proprietary sentences added in Dashboard do not help matters.
What is needed is a full redesign of the NMEA parsing logic, with dynamic extensibility for unexpected messages, and possibly better integration with the wx message queue model. Low priority back in the day, but looking more reasonable now. A pretty big piece of work...


Re the CDN change:
Upstream things change all the time, for various business and technical reasons. That's why we (developers) need to do ongoing maintenance on the build workflow. It will always be so. Leads me to:


Rule #2. Fix unavoidable breakage ASAP.


Dave

[stevead]

Problem with flatpak build of a plugin. Build failure on circle ci.

Complete!
+ flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
GLib-GIO-Message: 13:13:43.646: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
++ awk '{print $1}'
++ flatpak list
++ grep org.opencpn.OpenCPN
+ ocpnfound=
+ '[' '' = '' ']'
+ flatpak install --user -y http://opencpn.duckdns.org/opencpn/opencpn.flatpakref

GLib-GIO-Message: 13:13:44.788: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

error: Invalid .flatpakref: Key file contains line ?<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">? which is not a key-value pair, group, or comment

Which I am guessing occurs during the execution of ci/docker-build-flatpak.sh script

#!/bin/sh  -xe
cd $(dirname $(readlink -fn $0))

#
# Actually build the Travis flatpak artifacts inside the Fedora container
#
set -xe

df -h
cd $TOPDIR
su -c "dnf install -y sudo cmake gcc-c++ flatpak-builder flatpak make tar"
flatpak remote-add --user --if-not-exists flathub \
    https://flathub.org/repo/flathub.flatpakrepo
ocpnfound=$(flatpak list | grep org.opencpn.OpenCPN | awk '{print $1}')
if [ "" = "$ocpnfound" ]; then
   flatpak install --user  -y \
       http://opencpn.duckdns.org/opencpn/opencpn.flatpakref
fi
flatpak install --user -y  flathub org.freedesktop.Sdk//18.08
#rm -rf flatpak/.flatpak-builder && rm -rf build && mkdir build && cd build
rm -rf build && mkdir build && cd build
cmake -DOCPN_FLATPAK_CONFIG=ON ..
make flatpak-build
make flatpak-pkg

Attempting to open the aforementioned url http://opencpn.duckdns.org/opencpn/opencpn.flatpakref in a browser generates a 404 - Not found error

Seems like the build is broken once again !

All I want for Christmas is one (1) single up to date reference implementation of the ci (travis, appveyor, circleci) scripts that work. I am spending far too much time attempting to get the build to work than actually writing code !

[rgleason]

Steve, I believe this is due to the server being used, which Alec is fixing I believe. My plugins fail too.

[Rasbats]

Deleted!

[jongough]

I am having a problem with the contents of master.zip which is used in the android builds for plugins. The arm64 build is getting an error in the contents of master.zip:

In file included from /home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/fileconf.h:22:
/home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/filename.h:473:43: error: use of overloaded operator '[]' is ambiguous (with operand types 'wxString' and 'unsigned int')
        { return GetPathSeparators(format)[0u]; }
                 ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/string.h:1440:18: note: candidate function
    wxUniCharRef operator[](int n)
                 ^
/home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/string.h:1442:18: note: candidate function
    wxUniCharRef operator[](long n)
                 ^
/home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/string.h:1444:18: note: candidate function
    wxUniCharRef operator[](size_t n)
                 ^
/home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/string.h:1428:15: note: candidate function
    wxUniChar operator[](int n) const
              ^
/home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/string.h:1430:15: note: candidate function
    wxUniChar operator[](long n) const
              ^
/home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/string.h:1432:15: note: candidate function
    wxUniChar operator[](size_t n) const
              ^
/home/circleci/project/OCPNAndroidCommon-master/wxWidgets/include/wx/filename.h:473:43: note: built-in candidate operator[](const char *, long)
        { return GetPathSeparators(format)[0u]; }
                                          ^

Is there a workaround or a solution to this problem?

[Rasbats]

Two plugins have a menu that does not appear with MacOS Catalina.These are Weatherfax and PhotoLayer. Does anyone know of a plugin that uses a plugin menu and has found that it works on MacOSX?

Thanks.

Mike

[Rasbats]

On the Mac:

Compiled the latest code from the master branch of Github.com/opencpn/opencpn.

For some reason it gave me v5.0.2, without the plugin installer. Had a lot of problems previously compiling v5.2.4 due to libarchive. It failed.

Is there a source I am missing for compiling the latest code with the plugin installer?

Mike