Re: ✘NMEA2000 and issue #176

[Joachim Hippeli]

Hi all,

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.

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.)

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.
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 -- but to late. I described what I found out in detail
in my bug report. Maybe I'm wrong but I can't see any negative impact.


> 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.  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.


> > 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.  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.


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.  

- "path" is not used while in WATCH_NMEA mode 

- It costs too much 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. 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.

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.

>   gpsmon -n
> 
> is enough.  

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

Also, ...

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.