MFD engine alarming improves, but still needs more Maretron-ization

On Oct. 4th I’ll present a seminar titled “Electronic Engine Monitoring Comes of Age” at TrawlerFest Bay Bridge in Stevensville, Maryland. This Garmin 741 photo will be useful as it shows three new and different ways Gizmo’s old diesel engine can now indicate a low oil pressure problem. Thanks to the Actisense EMU-1 I installed in 2013, the simple low pressure alarm switch on the Volvo Penta can trigger an informative pop-up (and audio alarm) on all the networked Garmin screens regardless of what function(s) they’re showing. And if the engine gauge page is up, the familiar low oil pressure icon lights up and, better yet, the customizable digital psi dial can go red based not on the alarm switch, but rather on a minimum pressure I’ve set. That’s all good, but modern marine electronics can do even better…

This week I’ve been exploring the engine alarming features found in current Garmin, Raymarine, Simrad, and Furuno MFD operating systems, and I came away impressed with how well organized and comprehensive they’ve become. For instance, the screens above show how Simrad and Raymarine have put all alarm info and settings into one place, and they also suggest the dozens of specific engine warnings and alarms that can be displayed if the MFD sees the requisite NMEA 2000 message (PGN) on its network. Garmin multifunction displays also seem to understand more PGNs these days, as do the all-in-one N2K instruments from the same manufacturers. Let’s note, though, that these alarms are just on/off signals sent by the engine — with no custom set points possible — because that’s a limitation I’ll be griping about.

I also checked out MFD engine gauges, but only see minor changes from my tepid 2013 review. That’s not surprising for the Furuno TZT14, which hasn’t gotten a software update since early 2014. While some useful customization is possible — engine nicknames a small but unique one — the TZT has trouble translating some of the data on my network, like oil pressure and fuel rate/economy. Furuno, however, has been busy getting out the new TZTouch2 series, which boasts of “Fully Customizable” gauges as well as improved PGN compatability (and a favorable Panbo review by Fred Khedouri). Hopefully, TZT owners will eventually receive some of the Touch2 features via a software update.

And maybe TZTouch2 full customization will motivate Simrad to make their fixed “dashboards” more flexible. Credit Navico, though, with letting you use just about any numeric value on an N2K network, pick the source when they are multiple, and also configure min/max gauge limits and min/max warnings (the red parts). Note, for instance, how the top middle gauge is showing “ENGRM” temperature. Engine Room is one of the more arcane categories built into the NMEA 2000 standard, and in my case it’s actually a Maretron TMP100 temp sensor bolted to the engine block. 165 degrees really is when I want a head’s up, and this may be the single most valuable sensor value on all of Gizmo!

Raymarine’s gauge pages remain the most flexible in overall design, TZTouch2 aside, and the customization seems improved in ways I can’t quite put my finger on. However, RPM is still the only gauge you can configure limits on, and neither of the Ray displays can “see” my Engine Room Temperature at all. And notice all the wasted black space on that otherwise snappy looking gauge window (and others). If possible, wouldn’t you rather use those pixels for radar or fishfinding, or to go full screen with that handsome NV Bahamas chart (that just became available)?

Meanwhile, Garmin also recognizes the Engine Room Temp value on Gizmo’s network but — doh! — won’t let me add it to the otherwise fairly customizable engine gauge pages on the 8212 (the 741 is more limited). The interface designers apparently tried to make the customization easier by limiting the data choices to general Engine, Fuel, Tank, and GPS categories, but odd temperatures are collected in the Vessel category. But I can show any value on any data bar on either display, Engine Room included, and also in the “Numbers” page seen above. This is the sort of screen I often pull up when warming up Gizmo’s engine, but actually I rarely use any of the test MFDs for engine monitoring.

In fact, after at least 2,000 miles of running with EMU-1 digitized engine data, my favorite gauges are the homely Maretron DSM150 at lower helm and the bigger DSM250 above, and I sometimes use them for other underway tasks too. But that’s because I’ve developed a lot of confidence in their ability to let me know visually and audibly if anything is amiss. The screens themselves flash yellow for warnings and red for alarms, with explanatory pop-ups that I can phrase myself, but it’s the audibles that usually get my attention first.

Also, on the same N2K network are two Maretron ALM100 annunciators. The one seen above is on the main circuit panel above the steps leading from the lower helm to the galley/head/stateroom area, with the other at the flybridge helm, and I can testify that their “105 dB SPL Piezoelectric sounders” can be heard anywhere aboard, even though they’re only powered by the N2K network, and even by someone asleep with the engine running fairly hard. Which would be terrible except that Maretron alerts can be tweaked in numerous ways so that false alarms, or even unnecessary repeat alarms, can be minimized. I’ve detailed this before, and overlaid on the photo above are a couple of virtual DSM250 screens showing the high Engine Block Temp alarm setup (which pops up as “Engine Hot!”).

I’ve also written about Maretron’s great labeling feature before, but here’s a reminder screen showing that I can use N2KAnalyzer on Gizmo’s PC to give the TMP100 sensors more accurate labels than the temp category names supplied in the N2K standard, particularly when I use the sensor in a somewhat odd way. These labels, like the rest of the configuration, gets pushed to the sensor box itself and can then be seen on the DSM displays. All this can done with the DSM itself, but it’s tedious and for tasks like alert setups, which can only be done on the DSM (or with N2KView), I usually use the virtual DSM250 (which you can demo yourself on a PC).

Now I’m not saying that the big MFD manufacturers could or should emulate everything Maretron does (though I have fantasized about what, say, a Garminized Maretron monitoring setup might look like). But any one of them certainly could allow a boater like me to customize an alarm based on engine temperature, oil pressure or even an oddball sensor like the one on my engine block. By the way, the reason I find that one so valuable is that it tells me the moment my diesel is getting abnormally hot and is independent of the Volvo Penta alarm, which only tells me when the engine is way too hot anyway. And, look, many MFDs like the Simrad above already have nicely customizable alarms for some non-engine values. (Where you see two custom % or gal figures above, those are Warning and Critical limits.)

Here’s a similarly flexible alarm on Raymarine, meant for fishing, though I set it up to let me know if I ever get south of Maine again. And while I don’t have an illustration at hand, I know that Garmin already allows limited labeling (just tanks and engines as I recall), but I don’t know why any of the manufacturers couldn’t enable extensive labeling, including what a given sensor value really is about and what an alarm really means. It might just work within their own display networks, but heck, I believe there’s some sort of labeling built right into the N2K standard, though so far hardly used.

If, like me, you hope for better MFD alarming, please speak up. These are the glorious days when MFDs have become so powerful and connected that the developers often aren’t sure what feature to improve or create next!

But wait… how about something truly new in engine room monitoring and alarming? Just today FLIR and Raymarine announced LightHouse 15 support for the AX8 camera, which combines standard video detail with low res but very accurate and stable thermal sensing. The results can go to a Ray display network over Ethernet, and I understand that the interface not only shows your propulsion plant like you’ve never seen it before, but also lets you program different temperature alarms for different sections of the thermal image. More to come.