Re: ✘NMEA2000 and issue #176

[Joachim Hippeli]

On Thu, 30 Dec 2021 11:37:47 -0800
"Gary E. Miller" <gem@rellim.com> 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. Please try the example in my bug report and you
can see why. WATCH_JSON does not work.


> > 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. All other CAN-Bus messages were already
discarded and because I'm talking only about driver_nmea2000  you
should read my last sentence as "... which aren't related to GPS and
AIS through *driver_nmea2000 and* gpsd to a client".

> > -- 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 can't
explain this in one short sentence but I have explained it very
detailed in my bug report.

> 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(..., ...,
"nmea2000://canX") but I learned this is forbidden anyway.

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

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.

https://www.isobus.net/isobus/ 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. Would you really expand gpsd if someone defines a
new PGN?

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

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

> > 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. It has to do with
creation of new devices for each J 1939 source address where
each one opens its own can socket. But because it is more
complicated to explain than my original problem I want to
describe this only when someone has understood that original
problem.

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

Isn't this the consequence of using gps_stream(..., ..., NULL)?

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

At least "... is not an allowed command!" should be
mentioned somewhere in the documentation. IMHO the description of
gps_stream() (e. g. in https://gpsd.gitlab.io/gpsd/) is a good
place for that. Would have saved me a huge amount of working
hours.



> Stop trying to use gpsmon

I have already explained that I don't use gpsmon in real
live. I use gps_stream(..., ..., "nmea2000://canX")

> it is old, buggy, unmaintained

This should be mentioned in the documentation. The second
and third paragraphs of man gpsmon(1) are way to unspecific.

> If you stop misusing WATCH_NMEA,

Without WATCH_NEMA I get no messages at all. Try
nmea_good.log

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

Sometimes no messages when using gps_stream(..., ...,
"nmea2000://canX"). See my detailed explanation in my
bug report and try to reproduce my examples. But beware
of using the Linux "vcan" device. It behaves different.

________________________________


www.bhtronik.de

Schönseer Str. 55
D-92526 Oberviechtach

Sitz Oberviechtach, RG Amberg HRA 2943, Rechtsform GmbH & Co. KG
Pers. haft. Ges.: BHTronik Verwaltungs GmbH, Sitz Oberviechtach, RG Amberg HRB 
4446
Geschäftsführer: Baumer Christian, Hanauer Thomas

NOTICE: This e-mail message (including any file attachment) is intended only 
for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged and/or confidential. If you are not the 
intended recipient, any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by reply e-mail or a collect 
telephone call and delete or destroy all copies of this message and any file 
attachment. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that they are virus-free and accept no liability for any 
damage sustained as a result of viruses.
Please consider the environment before printing this email