Some questions on NMEA with OpenCPN - regarding Temp/Hum/Pressure

[makki99]

First of all: Hello to all of you!

I'd first want to introduce myself, Software-developer addicted to GPL/OSS, love sailing - though have no own boat (yet?).
I don't want to offence anyone, just being known as a member of the community for clear speach (hope thats translated ok, means: I say what I think, haven't studied any diplomatics..)

Now on topic: I worked on a (affordable!) sensor for Temp/barometric pressure/humidity and found some things not working/displaying in OpenCPN; no problem, I like Qt, understand some of the source and I'm happy to submit some patches..

But I'm new to OpenCPN and NMEA and pretty confused by some things, mainly where to start; I have hacked in some things now, but I want to get it right, not just "works for me".
- Could it be, that all NMEA0183-decoding is duplicated in the plugins (dashboard,logbook)?
- Whats the status of $--XDR in OpenCPN? There are some commented fragments, but..
So sending $IIMDA, $IIMTA, $IIMHU, $IIMMB seems to be the best thing now (and some need to get into OpenCPN, no problem on that); though, as I read all of them are deprecated and so I wonder what $--XDR one should send? (Lets say I have 5 temperatures, in,out,Battbank1,2,..)
My first post, so please be patient
Whats the best way to contact developers with patches and should things in nmea0183/ really be done multiple times in ocpn and dashboard, .. plugin?

What I'd expect is getting barometer, temp etc. for sure into dashboard, logbook but also get a history of the barometer and there I'm still really unsure on how to send/implement things in OpenCPN..

Makki

[nohal]

Makki...
Welcome...
So far nobody had enough interest and sensors available to dive into this AFAIK. When I had a look at it some time ago, it was a bit of a mess looking what NMEA messages different producers of the environmental sensors use. Most of them were using the deprecated ones.
The best way to submit patches is to fork https://github.com/OpenCPN/OpenCPN and send pull requests there.
The code duplication between the core and plugins is there "by design" - makes less sense for Dashboard, but for third party plugins, having it's own code asures that the changes in the core don't influence the plugin (of course even I am constantly breaking this rule in my plugins and of course they sometimes simply don't build anymore) In an ideal world, the only connection between the core OpenCPN and the plugin, code wise, should be ocpn_plugin.h
If you have any questions or suggestions to discuss, all the manpower working on OpenCPN is hanging out here. And we sooner or later read all the posts.

Pavel

[bdbcat]

maki99/Pavel...

The other reason the NMEA0183 specifically is duplicated in PlugIns is that it would make a very untidy library due to the large number of parameters that would need to be carried around by a single class.

Imagine the nightmare of code like this:

class NMEADecoder
{
public:
---
~---
struct *NMEA_PARAMETERS Decode(char *message);
};

What the heck would NMEA_PARAMETERS structure look like? It would have every possible NMEA parameter in it. Even with some unions, it would be a large mess.

So, we resort to sentence-by-sentence classes. And I judge there would be way too many to export from the core. Always one more needed, maybe, like --XDR in this case.
So the PlugIn developer may have to do some decoding in any case. Let him choose and implement whichever sentences he cares about by himself.

So that's the logic behind the design.

Dave

[makki99]

Originally Posted by nohal

So far nobody had enough interest and sensors available to dive into this AFAIK.

Thanks, thats also what I felt
But as a sailor, i could imagine that reading the barometer of the last hours - could be really interesting ..
So let me change at least this first (I'm doing environmental sensors for some years now, but "onshore")
Whats understood by existing Displays? Example NMEA-sentences
If not: what should a new sensor T/H/P output better? (I really can tell this one, what to talk, whatever you like )

When I had a look at it some time ago, it was a bit of a mess looking what NMEA messages different producers of the environmental sensors use. Most of them were using the deprecated ones.

A bit of a mess is very nice language As an IT-guy starting about 1990, i'd call NMEA rather a really big mess.. (Let me get onto NMEA2000 later..)

Still, it's IMHO now up to us here to fix it, so whatever we decide upon is a better "Standard" than this leaky crap..
I want a sensor that works with common equipment and OpenCPN, thats "Standard" then (Sounds arrogant? well, yes! but it's for now until another one comes up )
Just fix it, dont whine around this is the way things work..

The best way to submit patches is to fork https://github.com/OpenCPN/OpenCPN and send pull requests there.

Ok..

The code duplication between the core and plugins is there "by design" - ..

Well, I think I already seen that
No problem, Question:
where do you want to see parsing of $xxMMB etc?
I'm really happy to implement whatever is now "state of the art", as this is factum but I also want to know what you think about "could be better" NMEA is crippled, I know that..

In an ideal world, the only connection between the core OpenCPN

There is no ideal world, I know: no issue, I just wanted to ask in advance to submit useless code

If you have any questions or suggestions to discuss, all the manpower working on OpenCPN is hanging out here.

Good to know, I promise I wont bother you - rather do anything to support OpenCPN (ask me for Qt, compile-time issues under Debian/Ubuntu and if there is no other way even Windows until -7).

@Dave: I'm no "Chief-Programmer", really I just wanted to ask but it looks somewhat redundant, to duplicate simple things like NMEA-parsing.
OO-Gurus would encapsulate this..

I'd do it the same, but I still know, its not the best way
If we think about PGN/NMEA2k now, it's up to us to think about - I dont know enough about NMEA now but..

Makki

[bcn]

Originally Posted by makki99

If we think about PGN/NMEA2k now, it's up to us to think about - I dont know enough about NMEA now but..

Makki

With respect to N2K the place to have a look is here:
Canboat/canboat Wiki · GitHub

Dashboard: Although the dashboard is a generic concept that can show data from any source (when available in OpenCPN) my understanding is that it should be focussed on navigation, and not being a general instrument for every imaginable type of data. Atmo pressure fits here. Level of something in some tank I would not like to see, engine temperature or electrical consumption (A) neither.

The latter kind of data might go into a "glass bridge" concept - and should perhaps be considered as a seperated plug-in. And these are data that we might encounter on the N2K bus (coming back to the beginning).

My 2.5c

Hubert

[Littlechay]

Originally Posted by bcn

Dashboard: Although the dashboard is a generic concept that can show data from any source (when available in OpenCPN) my understanding is that it should be focussed on navigation, and not being a general instrument for every imaginable type of data. Atmo pressure fits here

I agree, atmospheric pressure, temperature, true wind speed and direction are the main tools that you have for on the water navigation decisions based on weather (weather routing) and these can easily be made available in the Dashboard. Ideally those should also be available as a history, say 24 hours, so that trends can be identified.

Some of that data is already available although I can't get the true wind history dashboard to work, it doesn't seem to use the same sentence that the gauges use.

The more modern instruments seem to use the MDA sentence and similar.

I have an airmar PB200 and am very happy to test any developments in this area.

Currently I log 0183 data using GPSGate and process it in R to produce my wind, temp and pressure history.

[makki99]

Originally Posted by Littlechay

Currently I log 0183 data using GPSGate and process it in R to produce my wind, temp and pressure history.

Hmm, this looks exactly like what I want - but I didn't find the sourcecode of "GPSgate" or how to run it under Linux
So I'm trying to learn git(hub) now and just make it in OSS, the only EULA I accept anymore is GPL

Still, I'd appreciate some more test-data from other sensors of that kind (temp/hum/baro,..) - plain NMEA-sentences, no explanation needed - besides what the true values are/were..

@Hubert: I think I got that, but whatever the dashboard displays is up to the user. Fancy extras like battery-temperature are very off-topic there.. But I'm struggling on how to display (in any mean) multiple temperatures at all..
Now let me fix the barometer first, maybe I understand more after that..

Makki

[makki99]

I played around now but it still looks -honestly- very ugly..Github-forking, well, that could be done.

So getting from asking to waiting for answers: what exactly do you like?
Parsing some NMEA isn't rocket-science (and you might have noticed, I didn't even want to, I just searched for "the right way" to send this weird stuff..)
But as proof-of-concept, OpenCPN will surely be the first to read it

While digging through, other vendors even publish NMEA-sentences in their docs with wrong checksums to further confuse users. thats really scary!

Looks good, but please give me some NMEA-sentences with that (Subject) for testing..

Michael

[Taarnskov]

Littlechay, the graphs that you shows her are exactly what I am looking for as a plugin to OpenCPN. An overview of the development in the weather compared to grib files and weather fax is just what is needed to estimate the optimum weather window for a departure. I hope we with your help can this kind of plugin.

Best regards, Lars

[Littlechay]

Originally Posted by makki99

Looks good, but please give me some NMEA-sentences with that (Subject) for testing..

Michael

Attached: a log file with one hour of NMEA data,RMC and MDA sentences.

Chris

[makki99]

Thanks Chris, I hope this helps me to make my first commit a little bit more mature! It went through fine..
(though, I still want some more examples..)

@Lars: Anything could be done using OSS, OpenCPN is a really nice thing! but first I want to find out, what the world really needs Thats the reason why I asked for your opinions..

Makki

[Littlechay]

Originally Posted by makki99

Thanks Chris, I hope this helps me to make my first commit a little bit more mature! It went through fine..
(though, I still want some more examples..)

Makki

Examples of what? I'm logging a lot of data but run that particular log with only those two sentences. Or do you mean that you need similar data from other sources/sentences?

I forgot to say that my system does not have a humidity sensor so you won't see any data there.

Chris

[makki99]

Originally Posted by Littlechay

Or do you mean that you need similar data from other sources/sentences?

Yes, meant that.. NMEA doesn't seem to be an exact documented science, so some testing might be worth it when implementing new things.. Even found different opinions on how to calc the checksum on the net (I'll stick with ocpn now)

Regarding pressure/barometer I'd also have the history from a few hours inside the chip already, but no idea how to output that using NMEA. So for a first shot, some history in the dashboard at least..
Created a fork on github (https://github.com/Makki1) but don't expect too much the next days as I first have to lign up the sensor doing the output.

Thanks though, I think I have an idea now, how it should work.

Michael

[markdj]

I've just found this thread. I have a NASA marine wind instrument and have been displaying the wind and direction data up on the side panel of opencpn for many years but I have noticed that the angle is not correct and the nmea sentence XDR for air temperature, is not working.

Is it possible to calibrate the wind direction that is displayed in opencpn ?

Can XDR be added for air temp?