Re: ✘n2k and issue #176

[Gary E. Miller]

Yo Reinhard!

On Tue, 14 Dec 2021 01:26:01 +0100
Reinhard Arlt <reinhard.arlt@t-online.de> wrote:

> i have learned quite a bit, since i have written the n2K code for
> gpsd many years ago.

We all have.

> And feel, that i was (at least a bit) pushed out of this group, as
> "my" data structures for attitude are removed from gpsd.

"removed" or "replaced"?  One of the problems with gpsd is the large
amount of code duplication.  As new features get added, old ones get
mutated to avoid that code duplication.  In theory.

I expect no functionality was lost, otherwise the regression tests would
have caught it?  Except nmea2000 is the only input source with no
regression tests.  That needs to get fixed.

> First a few comments:
> 
> 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.

Not just nmea2000, pretty much all of gpsd is about finding, and passing
on data, not losing it.

> 2.) The source address a of a n2k device is static. It is only
> allowed to change the own address, if you lose an address claim, or
> your device gets a new address during an ISO address assignment.

Is that the same, or different from, the SAE J1939 Address Claim Procedure?

> On a proper working n2k bus, you can only lose the address claim, if
> a new device is added. As the address claim is broken by design (it 
> violate a basic can rule), 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!

Uh, OK.

> I have no experience with the ISO bus, but i assume, that changing
> the devices on the bus will happen here more frequently.

So we are talking about two different things?  NMEA2000 and ISO XXX?

> The central problem comes form the nmea.

More than a few...

> A "normal" device on a n2k
> bus can always get the info of the devices on the bus with a dummy
> address claim. But you need a vendor id and a device id for that
> purpose, and the nmea charge you quite a bit for it. And even more
> worse, you will lose the device id, if your device is not certified
> after a few month.

Ouch.  So what do we do about it?

> My suggestion is: Tracking of the (j1939) address claim is not a big 
> thing. And adding a timeout for devices, that do not send messages
> any longer also not.

Why do we care?  As long as gpsd reports the CAN address with the
data, then it is a client problem?

> I can write this code, but i still think, that it is not needed.

I can see gpsd should keep the address data, and collect PVT data
by address, in case there are two GPS on the bus.  Beyond that, why?

> 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 am clear that the nmea2000 code needs some regression tests if it
is going to be changed.

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

pgp1YhAnyEgEi.pgp
Description: OpenPGP digital signature