N2K and heavily loaded network

Hi Michael,

During development of my packet sniffer it didn't take long before I encountered interleaved packets. The CAN standard makes sure that no bandwidth is wasted as each send can send the individual frames just fine. Most packets are "fast packets" that span multiple frames, so this can occur more quickly than you think.

The amount of displays in the system is largely irrelevant for this, it's the sensors and transducers that make up the load. In your case the 3 displays aren't your issue, the 9 senders are.

Apparently the Offshore displays (are we talking their MultiTank or Tank Gauge?) are more susceptible to this. If they use a small micro controller the amount of memory they can spare for reassembly is probably limited.

If you can monitor the amount of traffic that would be interesting. Have you got an Actisense NGT-1, Lawicel or Airmar N2K interface to your PC? In that case you could use my packet logger or Airmar's WeatherStation software to log the packets.

Also some systems can calculate the load in %, that would give us a quick estimate of your bus load.

Anyway, the workaround is to limit the frequency at which messages are sent. Most devices allow this in their configuration or setup.

I shall upgrade my packetlogger program soon so that it shows bus load in % and packet interleave levels.

Hi Steve, Unless there's something going on that you didn't explain -- like one or more of those gateways pushing a LOT of PGNs onto to your backbone -- I would classify your N2K system as small to medium. I don't think there should be any problems getting all data to every node, and if there are problems I would suspect the culprit is the display, not the network.

By the way, what do you mean when you say the displays "miss" data? Are the values jumping around?

I've never tested any Offshore Systems gear, but think that Russ Irwin, who posts here sometimes, has been using both their transducers and displays for a while. I sort of recall that he had some trouble with them, too. Russ?

First, as Kees says, it's the data generators that size the network, not the displays.

I have 9 tank level sensors, one depth/speed/temp transducer, a Maretron gateway and a Furuno MFD all dumping data onto the network. There are a number of data displays, but just one Offshore 3330 display. This drawing is slighly out of date, but pretty close (click on the drawing for a better view) http://www.newmorning.info/page12/page23/page26/page26.html.

I have other problems with the Offshore Systems components, but the 3330 display doesn't drop any data. Do you have this same display, or another Offshore display? Do both displays exhibit the same problem? And per Ben's question, what exactly are you seeing when you say it "misses" data? Tank level data usually isn't very dynamic.

I'm not sure what the Garmin display is displaying, but does it drop data also?

On the surface, the explanation you cite does not sound like the problem, but it should be easy enough to test.

First take the 3 N2K gateways off the network and leave the engine off, that leaves only your tank level senders. Is the problem still there? On both displays? If not, then add the other elements back on one at a time, first the engine, then the gateways and see which straw breaks the camel's back.

Hi All,

Thanks for the replies:-
I display 4 fuel tanks in 1/4 segments on the 3330 screen and each tank is calibrated to provide volumetric data. So I get, randomly, a name or names of tanks missing, and or qty of litres missing. I have found that re-starting the N2K power 3 times normally gets all the data there!! No they are not jumping around other than variances by 1% which I assume is transducer accuracy? The boat is on the hard so the levels are stable and not moving, do others experience this sort of fluctuation?

I have 2 3330 displays and I have seen the issue on both however have not confirmed it by visiting both screens in the same period to see if its the same missing data or different, I will do so.

The Garmin does not lose data, neither does N2K view, however neither of them can "see" the proprietry volumetric data in the fuel transducer. (A great failing of N2K in my opinion to not distribute calibrated data, just % height in the tank which is useless for non rectangular tanks

The common thread suggests that it is the transducers, so I will disconnect all the gateways and try the one by one approach.

Thanks for the feedback

Michael

If I understand you correctly, the missing data is labels and volumes? I've seen it take a minute or two for the tank labels to stabilize on my displays. I'm fairly certain that with Offshore, those labels are stored in the display (did you have to enter them separately in each display?), so any problem with labels is a function of the display; same with volume data. I now have 3 Maretron tank level sensors on the network and the Offshore display does not display labels or capacity data for them, only the tank number and % full.

That said, I have four fuel tanks with Offshore sensors which I can display in the same 1/4 segments that you describe. The tank level accuracy is awful, but the bad data is reliably displayed.

If 1% fluctuations are the worst you see, you should be very happy. If my experience is any indication, you'll see much bigger issues when you are in the water and in a seaway. I'd wait to be in the water and on passage before you reach any conclusions about accuracy.

If you have an Offshore sensor on you primary fuel tank / day tank, I suggest you do some careful verification of the lower level readings before you ever trust it below 25%. If you want more information you can reach me through the contact page on my web site.

N2K is a disaster with respect to calibration and labels. It's all proprietary so there is no interoperability. It's time to recognize the limitations of N2K and accept that it failed its mission. It's 2010 and time to start work on a truly interoperable networking standard that will serve commercial and recreational vessels so we can all (consumers and manufacturers) enjoy some economies of scale.

Some manufacturer has an opportunity to establish themselves as a leader by developing and promoting an open standard for the industry that meets the needs of a multi-vendor vessel in the 21st century.

Oh no, no, no! Not ANOTHER "standard"!!! In the real world, where stuff is on the shelves and people are starting to understand and want to spend the extra money for technology, this idea is poison. This is "shoot the messenger" thinking. No one has ever designed and delivered a flawless technology. This is the step in development when engineers have to stop dreaming about something new, and work at making it work!

Every manufacturer dreams of setting a new standard, for glory, profit, residuals and licensing, and every other manufacturer will work their tail off resisting that standard. Commerce mimics carnivores. [remember were you heard that!]

I used to have that cartoon above my desk: "There comes a time in every project when you have to shoot the engineer and ship the product."

I'll suggest a corollary: "There comes a time in every product when you need to hire an engineer to design it's replacement".

The computer world is full of open standards that benefit everyone. USB, Ethernet, Wifi, and SATA are just a few. When was the last time you bought a product with one of those standards and worried about whether it would connect to another vendors equipment with the same standard?

When was the last time you tried to create a multi-vendor N2K network without first buying a cable adapter and accepting that it will not be fully functional (e.g., no calibration, no labels per above)? The "N2K" displays that Michael is struggling with don't even have N2K connectors, they have screw terminals. These forums are riddled with people struggling to get basic interoperability, after they've agreeed to compromise functionality.

NMEA183 has survived so well because it's truly interoperable. It's a pain and it's limited, but a 183 connection between two vendor's equipment always works.

Even if N2K were fully interoperable, 240Kb is not a very interesting speed. It is slower than data networks of 30 years ago. Note that Michael was told that his problem was related to network speed. Note that all the vendors have created their own high speed networks. Furuno treats N2K like a serial port, it's not their backbone network.

Surely you would agree than N2K will have to replaced. The only point of real discussion is when. I suggest that a 240Kb network without any industry agreement on even physical connection is far past it's prime.

Some clarifications, hopefully:

PGN 127505, Fluid Level, has fields for Instance (tank number), Type (six types in a standard look up list), Percentage, and Tank Capacity.

Fluid % height and volume end up being the same thing once you calibrate the linear sensor to the possibly non-linear tank shape. All the N2K level sensors and analog-to-N2K adapters that I know of (Maretron, Garmin, Lowrance, & Offshore) have routines for making the % value reflect actual volume.

Yes, you have to use the same brand display or PC software to configure a sensor. There is a rudimentary calibration routine built into N2K but it's hardly in use yet. But the calibration values live in the sensor or adapter, so the values in the standard Fluid Level PGN are the same to every display, which means they should be able to show tank #, fluid type, percentage, volume used and volume remaining. Not all do offer all those values, but they could. Some also want tank capacity entered in their own setups instead of reading it from the PGN. I don't know why, but it all works once you put the same number in the display.

The Maretron TLM100 also outputs PGN 126998, Configuration Information, which is described thusly at the NMEA site: "Free-form alphanumeric fields describing the installation (e.g., starboard engine room location) of the device and installation notes." (I notice that Airmar outputs 126998 from its sensors too.) A user or installer can put up to 70 characters each in two fields using N2KAnalyzer. I haven't experimented with the possibilities yet, but it appears to be a standard N2K feature even if only Maretron is making much use of it now.

But maybe Offshore Systems is using PGN 126998 for tank levels more detailed than Fuel 1, Water 2, etc.? I don't know, but remain very doubtful that the incomplete labeling problem, which I've never seen in any testing, has anything to do with bandwidth. I really loaded up my test network recently -- including frame hogs like the Garmin XM Weather sensor and the MFD12 (displays do output PGNs, and can demand them from other nodes, excessively even, but that's another story). By several measures I only achieved about 50% bandwidth capacity, and didn't see any odd results.

I agree with Russ that there is an opportunity for a manufacturer to open up, but it's on the level of high bandwidth sensors like radar and sonar. I totally disagree about NMEA 2000. It doesn't need to be replaced and the chances of it being replaced in anything like the near future are about nil.

Theoretical capabilities aside, on my boat, all 9 tank level sensors have been calibrated and labeled with their respective vendor's displays and calibration protocols. The Marteron display only shows instance and tank level % for the Offshore sensors, and the Offshore display only shows instance and tank level % for the Maretron sensors. But this is a minor issue. The important thing is the actual accuracy of what they are reporting.

On New Morning, both Martetron have Offshore fuel sensors have exhibited major flaws in level reporting at critical times. Based on my experience, and the experience of at least one other yacht owner who just removed all his Offshore sensors, I suggest you get a good analog sensor like WEMA or Vetus and put a Maretron N2K adapter on it if you want N2K output.

I have WEMA tanks sensors and gauge on Gizmo, Russ, and can often see a 10-15% difference in levels depending on whether I rotate the knob from a fuller tank or an emptier one. I spoke with WEMA person in Miami and he acknowledged that it's a problem and offered to sell me a new, improved gauge. Of course the tank level sensor accuracy has nothing to do with the data networking, except that with NMEA 2000 you can see it wherever you want and combine the data with other values (if your displays allow). At any rate, good luck finding perfection in this area.

It is sort of cute though how you're now prescribing perfection to Bluetooth, USB, WiFi, and NMEA0183. Maybe you can explain why the controls on my Bluetooth headset won't change tunes on my iPhone but will on my Palm Centro (though I had to buy patch software to get them to work on the Palm at all), or why my Bluetooth GPS works with the latter but not the former? USB is fairly predictable and reliable these days but it sure as hell wasn't in the early days, and enormous resources have been plowed into it.

As for NMEA0183, you've got to be kidding. There are threads on here and many other places about issues interfacing recent, high quality gear, and the protocol is nearly 30 years old. It doesn't even have a consistent wiring standard, let alone a common plug. By contrast, the patch cables needed for the ONLY two non standard N2K connectors (SimNet and SeaTalkNG) are trivial to install and are orders of magnitude more robust than any 0183 connection I've seen.

It's also cute that you're using Mike's likely misdiagnosis to back up your insistence that NMEA 2000 should have more bandwidth. It was designed to work in conjunction with high speed Ethernet marine networks, and it's doing that fine on many boats right now. I'd be surprised if Mike's system uses more than 25% of his bandwidth, and it's probably a lot less. Like I said, I've never tried Offshore Systems gear but what you and Mike say about non standard display connectors and especially "proprietry volumetric data" makes me think they went off the ranch a bit.

Ben - is the problem with your WEMA system the sensors or the gauges?

My problem with the Maretron TLM100s is that when I tranfer fuel to my day tank (4gpm pump), as the tank nears 80%, the Martetron sensor quickly lowers its reading until it reports 0%. This is when the level is still well below the 2" deadband. This means the fuel transfer controller is effectively disabled since it's being told 0% and will keep pumping until the source tank is dry. When I stop the fuel transfer pump and wait 1-2 minutes, the readings return. I suspect that foam in the tank is confusing the sensor. To fill the tank, it takes another couple of cycles of transfer, stop, settle, read. Filling the day tank is now a manual operation. Maretron has no explanation.

My results with the Offshore sensors were much more erratic. Readings on the day tank would jump up or down by 20-40%, and stay there for extended periods (i.e., days when on passage) finally correcting after I was anchored for 12-24 hrs. On another occassion I was moving about 1nm from one anchorage to another and ran out of fuel while the sensor had reported 25% for the previous week. Offshore replaced the sensor at no charge, but the problems persisted.

I'd be happy if the readings were good +- 10%.

Russ, it does sound like you've been through the mill with ultrasonic tank sensing. While your specific frustration with the Maretron unit is somewhat unique, that same problem would surely vex anyone trying to carefully fill a fuel tank. If it does happen in that common situation, it seems like Maretron has to resolve the issue.

I suspect my WEMA problem, which is not critical, is just the gauge, but won't know for sure until I install another way to read the sensors.

PS readers, see the "Russ Gauge":
https://www.panbo.com/archives/2008/06/n2k_fuel_transfer_control_aka_the_russ_gauge.html

Surely Maretron would loan you a TLA100 for evaluation?

Russ, I do have a TLA100 hooked up to the test network and a cheap tank level lever. When I wrote about what's in the Fluid Level PGN yesterday, I'd just actually looked at a functioning one (via N2KAnalyzer). I just haven't tried it on the boat.

Well I for one will be curious to see how it works with your WEMA sensor. WEMA / TLA100 is the next iteration in the seemingly endles quest to know how much fuel is in the day tank.

I'll have some more input on tank senders to add come summer, when our new boat is launched. It is going to use Vega Bar 14 pressure based sensors mounted at the bottom of the tank. My boat builder says these work much better than anything else they tried, especially on shallow tanks such as ours -- our tanks are 2-3 times wider than high. They're industrial, not marine, components so they (a) work and (b) are much cheaper than a marine version would be.

The disadvantage is you need something to read the 4-20 mA current loop output and translate it to NMEA 2000.

Kees, yes you do need a 4-20 mA (common in industrial applications) -> NMEA2000 converter. What do you plan to use? I've long said that there is a need for generic NMEA2000 voltage or current sender adapters.

This tank thing is a big issue for me. We have five tanks to monitor and five Maretron TLMs is a big expense (don't even get me started on the 9 ACM100s I'll need).

Hi Adam,

Hm, I just noticed I never documented this on my blog. I shall do so shortly -- but at the moment I'm running short on time with the boat building process in its final stages.

My situation was similar / worse. With 2 diesel tanks, 1 day diesel tank, 2 water tanks, 3 grey/black water, 1 sea water tank we're up to nine tanks. Using up to 20 mA each is 180 mA at 24v is 4 Watts just for the tank meters...

What I'm using is a WAGO System field bus controlled by a small Linux server. The WAGO system is equipped with as many I/O modules as needed. I'm using 9 digital outputs to enable one of the tank meters, and then I use a current loop measuring module to measure the current flowing through that sensor. In this way the current is reduced by 9 and possibly more when I reduce the duty cycle.

Once I get my own system into operation I intend to put it on the market. It will only be cost effective for new builds, most likely. A small WAGO server with 8 outputs and a current loop A/D converter will run to about �500. The costs per port go down as you use more modules (as the base cost is amortized over more ports).

I don't know anything about NMEA 2000, was reading through this posting to learn something about it. Is it really limited to 240kb? Is it designed to share that one backbone across all connected equipment?

NMEA 0183 allows you to segment the network (AIS does not need to go to every device or 10 Hz heading updates are not required for every device either). So you can reduce the traffic on the "common" segement. And RS422 the spec behind NMEA 0183 will easily do 112kbs over 2000 feet of cable and more on shorter runs.

Most devices that support 2K still support 0183. So what is the advantage?

NMEA 0183 and RS-422 are really old at this point. But at least there is a generic standard that permits the use of other industrial (read non-marine) equipment to help with integration issues.

Any real future standard will probably need the same thing.

What's wrong with Ethernet and TCP/IP? You could use SNMP (network management standard) as a guide for simple things, and more complicated stuff like Nexrad data may require more thought. But the overall standards are already in place. That would really reduce the engineering effort.

I just can't see what I'm reading here is where we want to go forward in 2010.

Keep reading, Bob. In fact, NMEA 2000 is based on an industrial and vehicular standard called CANbus, which is quite appropriate for a marine sensor network. The bandwidth is sufficient to do things NMEA 0183 could never, ever do, and without the fuss of segmented one-to-many connections. (For examples check out Maretron's N2KView or the new Simrad NSE CZone stuff.

N2K was not meant for high bandwidth tasks like radar, but was meant to work in conjunction with marine Ethernet networks. Many boats today have N2K and Ethernet networks bridged through multifunction displays (i.e. dedicated marine computers). It can work quite well.

The physical layer of N2K is DeviceNet, which is often used with CANbus, but not always. I don't believe you'll find a more rugged and EMI resistant cable and connector system anywhere else on a boat, certainly not involved with NMEA 0183.

I've come to realize that many critics of NMEA 2000 come from the PC networking world where Ethernet and TCP/IP are a religion. But they really don't have much experience with critical, environmentally exposed sensor networks. Put N2K in front of an engineer who has worked on factory robotics, or ABS brake systems, stuff like that and they tend to say, "Yeah, good choice."

Thanks for the explanation Ben. I looked at some other threads here and discovered I stepped into a topic that's been beaten to a pulp...so after this post I'll leave it alone....

I read up offsite too and I understand how and why we have N2K today. And I agree there are numerous strengths for the marine market in the topology.

There appear to be some weaknesses though, the primary one would appear to be bandwidth. Every high bandwidth need must be solved outside N2K. And that means more limited or more complicated and costly interoperability.

Most of the other applications of the underlying N2K architecture are more closed. For example, GM making a car, integrates all the required networking before it reaches the dealer. And there is generally little need for additional equipment when new - or during the life cycle of the vehicle. A boat is a completely different proposition.

The bottom line - I stand on my original assertion that N2K is not the basis for the future - by itself. There needs to be additional standards, preferably open ones, to address the many areas that N2K just won't handle. This way the consumer and the marine installer get less expensive and easier to install equipment.

I'm all for open standards, Bob. The irony is that Ethernet has become the standard low level protocol for high bandwidth marine data, but the data layer, and often even the physical layer is proprietary. One manufacturer's waterproof Ethernet cable often won't plug into another's waterproof Ethernet port. And even if they did, the radar at one end wouldn't work with the MFD at the other.

As I said N2k was never meant to do all the data tasks on a boat by itself, so it seems unfair to reject it on that basis. Also, vehicle CANbus is more interoperable than it might seem at first glance. Check out the On-Board Diagnostics (OBD) standards, for instance, which are now going exclusively to CANbus.