+5

JFIN Source Address flexibility or GFIN Identifier wildcards

Vincent Thiele 6 years ago in IQANdesign updated by Florent Mirieu de Labarre 5 years ago 6

We work with NMEA 2000 devices and have had a great deal of issues with the dynamic Source Address nature of the standard. On startup the devices will jockey for Source Addresses and, depending on what's powered on or connected at the time, the Source Address scheme will be different.


We've made due so far with GFINs and using an ajust parameter for the Source Address to build the Identifier, but this requires one of two things to reconnect to a module: 1) blindly cycle through addresses until we find the right one, 2) connect a CAN analyzer to the bus and find the right address. Also, GFINs don't allow for the "Don't Care" option for priority that JFINs offer, which has also been a problem with manufacturers using different default values.


What I'm proposing is kind of the best of both worlds, where we can have the Identifier flexibility of the GFIN, but with the wildcard capability of the JFIN. That, or native NMEA 2000 support...

I forgot to add. If we had wildcard capability in the GFIN or Adjustable Source Addresses for JFIN (by channel, not on initialization or constant) then we could monitor and respond to the ISO Address Claim messages (PGN 060928) to find the components on the network. To do this right now, we would need 254 GFINs or J1939 modules to monitor all of the Source Addresses for this message.

Or it possible that the source adress of J1939 is parametrable.

Yes, you can have the source address as an integer parameter or integer math channel.

As long as they are located inside the Initialization group.

We can't use an Initialization group to set these parameters if the can messages are in an external function. Has this changed in v5.04?