NMEA 2000 bandwidth, Garmin & Furuno issues?
Maybe you thought I was off drilling multiple holes in Gizmo’s bottom — and I was! — but I’ve also been toiling away at the lab’s test NMEA 2000 network. You see, I’d heard that Garmin’s GXM 51 XM Weather sensor might be a bandwidth hog, and also that Furuno’s NN3D MFDs generate an inordinate amount of network traffic. There seems to be some truth to both accusations, but don’t panic! (And you N2K naysayers, please save your snarking until you hear the whole story.) Yes, as you can see on the table above, removing either of these devices reduced bandwidth use of a fairly large network significantly. But even with both devices live on the network, I didn’t see any data problems, and am pretty sure these Garmin and Furuno issues will only cause real issues on very large networks. Let me break down the testing and what I think I’ve learned…
As you can see in the table, I’ve got three ways of measuring the percentage of N2K bandwidth in use at any given moment, and their measurements are all different! But at least they’re different in a consistent way. Maretron’s N2KMeter, though otherwise a very powerful diagnostic tool, was probably the worst for this task because it seems to sample net traffic at a very high rate and N2K networks seem to have sharp highs (and lows) of bandwidth usage (that don’t cause any problems). Actisense’s NMEA Reader, attached to the network via a NGT-1 Gateway, seems to sample bandwidth percentage over a slightly longer period, and hence didn’t generate the extremes N2KMeter did over 60 seconds of observation. And the Lowrance HDS, which measures bandwidth use as part of its diagnostics, seems to measure over an even longer period, and also to come up with consistently lower numbers. The Simrad NSE has the same ability and also seems to come up with low numbers relative to others.
Despite all this flakiness, the numbers do tell a story. Apparently the Garmain GXM 51 can use nearly 20% of the bandwidth at instances. The N2KMeter can look at individual bus traffic percentage, as well as frames per second, and the GSM 51 is the consistent highliner on my network with momentary scores like the 18.7% seen below, which seems to equate to 228 frames/sec. But, again, don’t panic. It’s obviously hard to say what its true average frame rate is (due to measuring inconsistencies), but its not all that much. And, by way of comparison, I measured the following maximum frame rates over one minute: Airmar PB200, 77; Avia Onboard simulating dual engines, wind, GPS, & more via Actisense NGT-1, 122; Garmin GMI 10 (every device outputs something), 3. At any rate, why Garmin chose to put XM Weather on NMEA 2000, and what it can do for you, is another story I hope to tell soon.
The Furuno MFD12 is a very different story, and, in fact, may be old news. (I don’t have the latest software loaded, but if fixed already, I trust Furuno Tech will let us know.) As seen on the N2KMeter, the MFD12 looks like a normal display with little output, but apparently it’s regularly and rapidly requesting ID info from all the other devices on the network, and you can see in the table all the traffic that generates. What it’s doing, I’m told, is not illegal, but it’s meant for problem solving, not constant use. I can also see the problem in NMEA Reader, which lists all PGNS together, unlike N2KAnalyzer, which shows them by device. PGN 126208, Request Group Function, shows up a lot when the MFD12 is powered on. (But N2KAnalyzer shows a device’s node address, which is how I knew that “MAC” 11 below is the GXM 51, while NMEA Reader is dim about specific devices; for the time being, sigh, you need both to have a maximum view of what’s going on.)
So there you go, some geek adventures into the NMEA 2000 nitty gritty. Let me emphasize again that none of this will mean beans on most boats using N2K. But it could on some, and maybe that’s why some of you may need to know about it, and why the manufacturers have to be careful.