gpsd-dev
[Top][All Lists]
Advanced

[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: Thu, 30 Dec 2021 11:37:47 -0800

Yo Joachim!

On Thu, 30 Dec 2021 09:52:30 +0100
Joachim Hippeli <joachim.hippeli@bhtronik.de> wrote:

> I'm the issuer of https://gitlab.com/gpsd/gpsd/-/issues/176.
> In my bug report I have explained in detail what I found out
> about this problem. Maybe you should take a look at it.

Cool.

> Please let me answer your questions and comments here in
> one summarized mail:
> 
> On Mon, 13 Dec 2021 17:04:22 -0800
> "Gary E. Miller" <gem@rellim.com> wrote:
> >
> > I don't know why anyone uses gpsmon.   
> 
> I use gpsmon in my bug report so that you can reproduce the
> issue.  Gpsmon is one of the few clients which support NMEA
> (-n, WATCH_NEMA) mode and only in this mode I can receive
> messages from certain NMEA2000 receivers.  (I know the exact
> reason, it has to do with MODE_2D in driver_nmea2000.c but
> this is more a topic for a separate ticket.)

I think you misunderastand what gpsmon is doing.  To start, it is not
really a gpsd client.

WATCH_NMEA does not really watch NMEA.  It is not the right tool
for NMEA2000.

> On Tue, 14 Dec 2021 01:26:01 +0100
> Reinhard Arlt <reinhard.arlt@t-online.de> wrote:
> >
> > 1.) A solution to respect only n2k gps and ais messages is
> > absolutely the wrong way. On a boat, you want to see as much info
> > from the nmea2000 bus as possible, and convert them into JSON and
> > nmea0183 messages.  
> 
> 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.c decodes a certain set of PGNs. All other PGNs
> which aren't recognized by one of the hnd_NNNNNN functions() were
> always discarded

Not really, and easy to improve.  They are not decoded because we
do not have the expensive, and proprietary, dcumentation.  With doc,
anything can be added without a lot of work.

> -- but to late.

Too late for what?

> I described what I found out in
> detail in my bug report. Maybe I'm wrong but I can't see any negative
> impact.

The negative impacts are noted on that issue.  No rebuttal has been
given.

> > Not just nmea2000, pretty much all of gpsd is about
> > finding, and passing on data, not losing it.  
> 
> NMEA2000 messages can coexist on busses which transfer also
> completely different messages.

Of course.

>  I can't believe you want
> deliver e. g. ECU-to-ECU messages over gpsd to gpsd clients.
> Gpsd hasn't even the data structures for it.

Believe it.  You just complained that gpsd was discarding messages, and
now you say it should discoard messages?

> > > I have never seen an iso address assignment on a boat in
> > > the wild, even it is mentioned in the n2k standard as a
> > > possibility.    
> >
> > And I've never heard of any either.  But now issue #176
> > wants to extend the gpsd nmea2000 code for the ISO case.
> > I'm unclear on the real world use case.  
> 
> I'm a developer of software communicating over J1939 and ISO
> 11783 busses.

Which, as you know, is not NMEA2000.

https://www.merriam-webster.com/words-at-play/plural-of-bus

"The plural of bus is buses."

> Sometimes, third-party GPS receivers supply
> NMEA2000 messages on those busses (not on powertrain busses
> of course).  I try to use gpsd for delivery the NMEA2000
> messages to various clients (self-written or written by our
> customers).  So, yes, it's a real world use case.

Cool.  Can you provide the real world data captures I have asked for?

> On Wed, 15 Dec 2021 10:39:58 -0800 "Gary E. Miller"
> <gem@rellim.com> wrote:
> >
> > Your use case is only going to get more common.  gpsd
> > supports multiple serial devices, and separates them by
> > device "path".  I guess nmea2000 should do that too?  
> 
> Theoretically this could be a way. But it fails for two reasons.  

Not theoretical.  gpsd already does that.  Not perfectly.

> - "path" is not used while in WATCH_NMEA mode 

Another reason not to use WATCH_NMEA.

> - It costs too much CPU time.

Say what?  The one thing gpsd does NOT do, is take CPU time.

> I have embedded Linux boxes
> with two serial GPS receivers and two CAN-Busses.  Gpsd
> consumes already about 20 or more percent CPU on my I.MX6
> systems though all clients select one particular device via
> the third parameter of gps_stream.

Then you are doing something really wrong.

> I think the CPU time
> would increase too high if I route the messages from all
> receivers to all clients and do the filtering inside the
> clients.

No one suggested that.  Are you suggesting that?

> On Tue, 14 Dec 2021 01:25:26 +0100 Reinhard Arlt
> <reinhard.arlt@t-online.de> wrote:
> >
> > gpsmon -n localhost:2947:nmea2000://can0
> > 
> > is not an allowed command!
> >   
> This statement answers my biggest question. I always
> wondered why no one else encounters this problem. But all
> makes sense if I do something outside the spec.

Not just outside the spec, but not doing what you think it does.

> >   gpsmon -n
> > 
> > is enough.    
> 
> Unfortunately, I think that (gpsmon -n translates to
> gps_stream(..., ..., NULL)) is not an option for me. 

Stop trying to use gpsmon, it is old, buggy, unmaintained, and does
not do what you think it does.

> On Tue, 14 Dec 2021 01:26:01 +0100 Reinhard Arlt
> <reinhard.arlt@t-online.de> wrote:
> >
> > a restart of the bus and all devices is always a good
> > idea, as you never know, if an other device is off bus
> > afterwards!  
> 
> ... a restart of the whole system only because a peripheral
> device is switched on or off is not an option for me.

Until recently, gpsd has required restarts.  Working on that, but
expect bugs.

So, after all that bike shedding.  If you stop misusing WATCH_NMEA, and
gpsmon, what ccould be changed in gpsd JSON to solve your problem?

Better yet, what exactly is your problem?  You only allude to:
   too many messages
   too few messages
   messages not informative

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  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: pgpi8prz1ugbW.pgp
Description: OpenPGP digital signature


reply via email to

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