[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘NMEA2000 and issue #176

From: Gary E. Miller
Subject: Re: ✘NMEA2000 and issue #176
Date: Sat, 8 Jan 2022 12:35:19 -0800

Yo Joachim!

On Sat, 8 Jan 2022 20:21:58 +0100
Joachim Hippeli <> wrote:

> On Thu, 30 Dec 2021 11:37:47 -0800
> "Gary E. Miller" <> wrote:
> > Yo Joachim!
> >  
> Hi Gary,
> > WATCH_NMEA does not really watch NMEA.  It is not the right tool
> > for NMEA2000.  
> WATCH_NMEA is the only tool to get GPS messages at all from some
> GPS receivers.

We are going in cirlces here.  Last timme I', going around the loop.

WATCH_NMEA hass zero effect on any receivers.  It only tells gpsd what
to send.  Any gpsd client can use WATCH_NMEA.

WATCH_NMEA should really be WATCH_NMEA0183, since you are on NMEA2000
you are getting a marginal pseudo NMEA 0183.  Maybe what you want,
but not what you need.

> Please try the example in my bug report and you
> can see why. WATCH_JSON does not work.

I thought I already explaind that I haev no NMEA2000 equipment, so I can
not try your example.

> > > Maybe I'm overlooking something in the code but I see no way to
> > > get messages which aren't related to GPS and AIS through gpsd to a
> > > client.  
> > I could show you were many such things are, RTCM, IMU, etc., but
> > that would be a distractation.  
> Driver_nmea2000 decodes a fixed set of messages, handled in the
> hnd_NNNNNN() functions.

Yes, we have gone around this circle before, last time I'm gonna do this.

> All other CAN-Bus messages were already
> discarded and because I'm talking only about driver_nmea2000 

Of course.

> you
> should read my last sentence as "... which aren't related to GPS and
> AIS through *driver_nmea2000 and* gpsd to a client".

And, once again, that is an incorrect statement.  Last time I'm gonna say
it.  gpsd decodes things from NMEA2000 that are not GPS or AID.  Things
like depth, wind angle, etc.

> > > -- but to late.  
> > Too late for what?  
> A deep knowledge of what driver_nmea2000 does is necessary to
> understand what the problem is and what my patch does.

I just went by what you said it does, which you did not deny or correct.

? I can't
> explain this in one short sentence but I have explained it very
> detailed in my bug report.

And I detailed my objectsios in the bug report.  Until you address my
objections, this is the last time I'll respond.

> > The negative impacts are noted on that issue.  No rebuttal has been
> > given.  
> All messages which are currently delivered will also be
> delivered when my patch is active . Even new messages would
> be delivered when their decoding function is added to
> gpspgn, aispgn, pwrpgn or navpgn.  So I can't see a negative
> impact, all existing software should not see any changed
> behaviour, except that it gets more often a "connection" to
> a GPS receiver when it uses gps_stream(..., ...,

And this list has already gone over the objections, which you refuse to

> "nmea2000://canX") but I learned this is forbidden anyway.

Not forbidden, just way sub-optimal.

> > Believe it.  You just complained that gpsd was discarding messages,
> > and now you say it should discoard messages?  
> "gpsd was discarding messages" is a oversimplification. Please
> read my bug report.

You said so yourself.  And you admitted it borke existing applications,
which is a no-go.

> And I still don't believe it. Maybe you are not aware how many
> messages are transmitted on a J 1939 conform bus. There are
> bitrates of 250000 or 500000 bits/s and a bus load of 70 % is not
> unusual. Almost all messages have nothing to do with GPS, AIS or
> common status information defined in NMEA2000.

Yes, of course.  Not sure why you bring that up.

> could give you a first
> glimpse what is going on on such buses.  And this is only a
> small fraction.  There are more standards and yet more
> proprietary messages.  There is specialized software for
> that. Also, the communication is usually bidirectional. It
> makes absolutely no sense to route such connections over
> gpsd.

Yes, of course.  Not sure why you bring that up.

> Would you really expand gpsd if someone defines a
> new PGN?

Happens all the time.  Check the git log.

> > Which, as you know, is not NMEA2000.  
> But they can and do transfer NMEA2000 messages.


> > Cool.  Can you provide the real world data captures I have asked
> > for?  
> You can find the files nmea_bad.log and nmea_good.log in my
> bug report.  Those are real world examples. I have filtered
> out tens of thousands messages to make your debugging task easier
> (and because other messages may contain confidential
> information) but they are captured on a real system.

If you ahve been following along, you will know I can not use them
because the gpsd NMEA2000 regressions are not working at this time.
I'm working on that.

> > > - It costs too much CPU time.  
> > Say what?  The one thing gpsd does NOT do, is take CPU time.  
> Have you ever tested Gpsd on a system with two heavily loaded
> CAN-Buses?

Nope, and that would not be a gpsd problem.  I'd be happy to help
mitigate that problem that ony you seem to have.

> > > Gpsd consumes already about 20 or more percent CPU on my I.MX6  
> > Then you are doing something really wrong.  
> There is another flaw in driver_nmea2000.

Just one?  I'm sure there are hundreds.  And I'll stop here, since you
continue to go around in circles, instead of addressing the original
topic, and are not getting off topic.  If you want to change the subject
then please start a new thread and/or issue.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpFPg5vCCiPc.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]