What's the current 'state of the art' on bilge monitoring?

[wkearney99]

It's been on my to-do list forever... to have "something" in place to help me keep better tabs on how the plethora of bilge pumps are performing on our EB47. Engine room, mid-bilge, forward bilge, galley gray tanks, black water, etc.

There have been a bunch of different approaches to this in the past. Either simple counters, panels that monitor just one or two, but little that really paints a clear picture of what's going on with the pumps. How frequently were they running, and for how long? Short-cycling kills pumps, perhaps even more so than them running for extended times.

What's the latest-and-greatest on this these days? Anything new lately?

 

[mcarthur]

Not sure about SOTA, but I'm trying to coordinate digital switching with monitoring for bilges.
Each bilge would have a non-mechanical switch and a pump. Both are wired back to a digital switch unit (Maretron). The unit is N2K, and with the switch and pump separate, the pump is programmed to turn on when the switch goes high, or you can manually turn it on via N2K switching.
While the pump and switch separation is a risk in case there's a problem with the wires or unit, really bilge pump operation should be checked regularly anyway.
Benefits of this include being able to monitor each pump for amperage, and also provides a count of number of times it's turned on and the time it was on for each one.
All this would be overkill for 1-2 bilges, but we have 8: catamaran, 4 areas in each hull.

 

[O C Diver]

I had a panel made for my helm station for all four bilge pumps. Each pump had a green indicator light to show the pump was on in the Auto position or Manual position. There is a brighter yellow light to indicate the pump is running in either the Auto or Manual setting. There is a counter with a zeroing button that holds the count in memory, regardless of whether power is turned off from the panel. Each pump is independently fused to a separate panel in the engine room. The boat has two compartments each with a small primary and large secondary pump. As the large secondary pumps are several inches higher, those each have a buzzer to indicate activation. They are also tied to the Siren alarm system so I receive a text and an email whenever they would activate. I thought that was a pretty thorough standalone system.

My panel was made by Aqualarms.



Ted

 

[sunchaser]

There a plethora of ways to monitor bilge pumps. Rule has a system, use a backbone, get a cell phone app tied into your 12 volt panel etc.

To me, any water in the bilge is a bad thing and should be tracked and fixed post haste. Thus employ a belt and suspenders approach. Lift the hatch, visit the ER and or install a camera for direct eyes on monitoring. A faulty float switch negates the purpose of bilge pump monitoring system.

 

[lwarden]

This would be a simple and fun project for an Arduino if you are so inclined to DIY.

 

[twistedtree]

I've done a bit of a hybrid, hopefully getting the best of both worlds.

- Each pump has the typical Off-Auto-ManualOn switch, left in the Auto position under all but exceptional circumstances.

- There are two stage float switch made by Ultra, and seem to be the most reliable float switches. The first stage/level turns on a small bilge pump, and the second stage/level turns on a large bilge pump. The second pump is optional, but the associated alarming is import and in the next part.

- When either stage of the float switch is activated, it signals a monitoring system, Maretron in my case. I have dry bilges so any pump operation at all is cause for immediate attention, both are set up as full Alarms, not warnings, and they make noise and send emails. These alarms also trigger counters, and a cumulative runtime.

I like having the activation of the pumps as simple as possible with as few things that can prevent them from working correctly. Contrast this to mcarthur's setup where the float switch, the detection module, N2K, and the power control module all need to be working correctly for the pump to run. All I need is for the float switch to work, so much less opportunity for failure. I'm still subject to the same N2K failures, but only for monitoring, not for actual pump operation.

 

[wkearney99]

I no desire to interfere with how they're currently operating. They're each on individual breakers with a manual mode. That's all working fine. They're critical to the boat being 'not sunk' so I'll keep them powered as simply as possible.

Monitoring them presents options. Is the RIM100 the Mareton unit you're using? What's handling the collection of data and alerts?

I have my main N2K network on it's own breaker along with the lower helm. The upper station is on a second breaker to allow powering it off separately (this to avoid having the gauges lit up all the time if I'm running from below). I'd imagine something similar could be done with a power tap for just the RIM100 to allow it to remain powered without all of the other sensors consuming power. Being mindful of voltage differential issues, of course, as N2K is a finicky beast about that.

 

[SteveK]

Are we talking about monitoring on the boat OR monitoring off the boat. In my case when I am on the boat I am aware. It is off the boat I want to be alerted to unusual activity.
Currently I have for many years what is called BRNKL. It works as long as there is a cell service.
Bilge pumps? have a two pump setup in the ER, one float switch to smaller pump to maintain, second float switch mounted higher to larger pump for that day when all hell breaks loose.
I can program the alert for repeated events and/or length of pumping.

 

[twistedtree]

I no desire to interfere with how they're currently operating. They're each on individual breakers with a manual mode. That's all working fine. They're critical to the boat being 'not sunk' so I'll keep them powered as simply as possible.

Monitoring them presents options. Is the RIM100 the Mareton unit you're using? What's handling the collection of data and alerts?

I have my main N2K network on it's own breaker along with the lower helm. The upper station is on a second breaker to allow powering it off separately (this to avoid having the gauges lit up all the time if I'm running from below). I'd imagine something similar could be done with a power tap for just the RIM100 to allow it to remain powered without all of the other sensors consuming power. Being mindful of voltage differential issues, of course, as N2K is a finicky beast about that.

Yes, I use a RIM100 and N2KView to collect data and do alerts. Alerts get sent out via email over the boat's internet connection, not via a Maretron SIM device. I have the computer that runs N2KView set up to auto reboot once a week. That plus setting the IPG100 up as a WAN device with fixed IP address is the only way I have been able to finally keep the whole thing running for more than about a month. It's taken 15 years to get to that point. All this results in a love/hate relationship with Maretron's products, shifting rapidly towards the hate side because they just aren't keeping up in general with technology, and are becoming increasingly incompatible with other N2K devices because of their unique approach to selecting data sources.

 

[wkearney99]

Ugh, I didn't much like the N2Kview software. It's clunky, at best, and (if I'm remembering right) overpriced for what it offered. I also have an IPG100 but never really made much use of it.

I've ordered a RIM100. Does it do the collecting on itself? And can I bring up the counters on a DSM410? I'd be ok with putting a page (or several) on my DSM410 displays that showed counters. But I'm not yet familiar with what data is available on the RIM100 and what the DSM410's can display.

It's one thing to have counters, it's another thing to put them in context over time.

I do have a Raspberry Pi aboard with an N2K interface. I've not put much effort into utilizing it. This could be an incentive. Grafana has some excellent features for graphing data and I have the HDMI from the pi fed into one of my TZT3 chartplotters.

I haven't added much in the way of new devices, what's Maretron been giving you trouble with?

 

[twistedtree]

I don't believe the RIM (or any of maretron's sensors) stores any data. They just sense then send on the N2K bus. I haven't used one of the DSM products in well over a decade, but as I recall they can display most of the same data as N2KView. But I'm not sure about graphing. Maybe, but I'm not sure. And I don't know if you can send email alerts from a DSM. I would guess not, but don't know.

N2KView is very clumsy to work with, as you note. That's one complaint. But the real killer is their unique and incompatible way of selecting data sources. For any type of data, say GPS info or battery voltage, they do it exclusively based on an instance number. Sometimes it's a device instance, and sometimes it's a data instance, but in either case that number needs to be globally unique across your network. Nobody else requires that, and that's not how the standard says to differentiate and select data sources, nor how to use Instances. The result is that it's difficult, if not impossible to get Maretron's display products to display the data you want. And if you ask about it, Maretron and other vendors just point the finger at each other saying the other is wrong. And NMEA representative just give you a blank stare when asked about it, and say to always use certified products. Well, certification doesn't test for this, so it's of no use.

By way of example, I have four solar charger controllers, an inverter, and two BMSes, and Maretron's display products (N2KView and DSMs) can't differentiate between any of them. Through some backflip hacks, I can get it to reliably display one BMS, but everything else is a mangled mess. I have been complaining to Maretron and NMEA about this for going on 10 years and neither seems to care. Given the standard is now 25 years old, I just accept that it will never change, and I am increasingly moving everything away from N2K. I have never done any control via N2K, only monitoring. Control, and probably half of my monitoring is now on Modbus devices and communications. And I haven't used N2K for Nav data for over 10 years now. So N2K just keeps getting pushed into a smaller and smaller corner each year.

N2K had so much potential, yet has been one of the greatest disappointments of marine electronics. Doing something with Grafana, NodeRed, SignalK, etc. is very tempting, but so far I haven't been able to muster the motivation to open that can of worms.

 

[wkearney99]

Doing something with Grafana, NodeRed, SignalK, etc. is very tempting, but so far I haven't been able to muster the motivation to open that can of worms.

I hear you on the 'muster the motivation'. A thought I had was to see what it would take to get collected and/or 'calculated' data to be shown on N2K displays. As in, use a pi with an N2K interface to create a 'fake' device of sorts that the DMS410 could use as a data source. But with HDMI output from the Pi into a plotter it's not like force-fitting data into a format usable by 4" displays would be any more helpful.

Another was to look into what it would take to have the Pi generate "alerts" that the plotters could display. But I've not looked into how (or even if) the Furuno plotters I've got could accept and display externally generated alerts. That would probably be the most effective long-term. Have the Pi do the collecting, and have a few Grafana pages visible via HDMI and use alerts on the displays to raise attention.

 

[twistedtree]

I generally like the functionality of N2KView, especially the user configurable screens. And I'm happy to dedicate a computer and screen to it. I just want a more modern, usable, and compatible implementation. I scour the trade shows each year, but keep coming up empty handed.

 

[Wdeertz]

N2Kview sends a sms/email warning if any bilge pump operates for more than 15 seconds and an alarm if any bilge runs continuously for 45 seconds. My bilge is dry so any bilge activity is reason for investigation but didn’t go with lower thresholds to avoid false alarms. Also have high water alarm which sounds a loud alarm and sms/email if not on the boat.

 

[mcarthur]

...
I like having the activation of the pumps as simple as possible with as few things that can prevent them from working correctly. Contrast this to mcarthur's setup where the float switch, the detection module, N2K, and the power control module all need to be working correctly for the pump to run. All I need is for the float switch to work, so much less opportunity for failure. I'm still subject to the same N2K failures, but only for monitoring, not for actual pump operation.

I agree, and was tempted to go the simplicity - and I may yet. But under my way I can monitor* the amperage of each bilge pump which is valuable for detecting possible flow problems.

*well I can if I'm running n2kanalyser, but getting that data showing up in n2kview is just insane, and I'm yet to succeed. @twistedtree - I may be following in your footsteps yet! I'm interested in how the Modbus stuff is going, otherwise I'll be heading more towards the DIY and home assistant for both control and monitoring if I ever throw Maretron (definitely not impossible!)

 

[twistedtree]

@twistedtree - I may be following in your footsteps yet! I'm interested in how the Modbus stuff is going, otherwise I'll be heading more towards the DIY and home assistant for both control and monitoring if I ever throw Maretron (definitely not impossible!)

The Modbus stuff is actually working quite well. I primarily use it for power monitoring and control, and it does that very well. I also export some data on N2k for display on N2KView for convenience. Programming PLCs and HMIs is positively stone-age, along the lines of 1980 BASIC programming. But programs are inherently pretty simple, so it works, and that's the best part. You turn it on, and a few years later it's still running just like the day you turned it on. I've had no issues at all with modbus compatibility, either with wired Modbus or Modbus/TCP.

Because it's so reliable and well proven, I'm comfortable using PLCs, modbus, etc for controlling stuff on the boat, where I'm not comfortable using N2K for that. So my PLC/Modbus system monitors all my AC power sources (shore cords and generators), detects power and automatically connects the load panels (inverter, non-inverter, and HVAC loads), automatically controls the isolation transformer boost switch for dealing with 208 vs 240V shore power, and my new favorite - automatically adjusts the VIctron Inverter input load limit based on the capacity of the power source, and what other loads are connected. So the only manual operation is to plug/unplug shore cords, and start/stop generators, and the system does all the rest, assuming I have it in Auto mode. It can all be controlled manually too. And it even does generator autostart when the batteries drop below a set point. It's nice to know that I can leave the boat and if the shore power fails, the inverter will keep everything running. And if the batteries get low, the generator will recharge them. And when shore power is restored, everything will switch back. I know a lot of people don't like automation, but for me it comes down to on simple question. Is it reliable? Automation that works is awesome, and automation that doesn't work sucks. So far this all works.

 

[mikehar]

I don't believe the RIM (or any of maretron's sensors) stores any data. They just sense then send on the N2K bus. I haven't used one of the DSM products in well over a decade, but as I recall they can display most of the same data as N2KView. But I'm not sure about graphing. Maybe, but I'm not sure. And I don't know if you can send email alerts from a DSM. I would guess not, but don't know.

N2KView is very clumsy to work with, as you note. That's one complaint. But the real killer is their unique and incompatible way of selecting data sources. For any type of data, say GPS info or battery voltage, they do it exclusively based on an instance number. Sometimes it's a device instance, and sometimes it's a data instance, but in either case that number needs to be globally unique across your network. Nobody else requires that, and that's not how the standard says to differentiate and select data sources, nor how to use Instances. The result is that it's difficult, if not impossible to get Maretron's display products to display the data you want. And if you ask about it, Maretron and other vendors just point the finger at each other saying the other is wrong. And NMEA representative just give you a blank stare when asked about it, and say to always use certified products. Well, certification doesn't test for this, so it's of no use.

By way of example, I have four solar charger controllers, an inverter, and two BMSes, and Maretron's display products (N2KView and DSMs) can't differentiate between any of them. Through some backflip hacks, I can get it to reliably display one BMS, but everything else is a mangled mess. I have been complaining to Maretron and NMEA about this for going on 10 years and neither seems to care. Given the standard is now 25 years old, I just accept that it will never change, and I am increasingly moving everything away from N2K. I have never done any control via N2K, only monitoring. Control, and probably half of my monitoring is now on Modbus devices and communications. And I haven't used N2K for Nav data for over 10 years now. So N2K just keeps getting pushed into a smaller and smaller corner each year.

N2K had so much potential, yet has been one of the greatest disappointments of marine electronics. Doing something with Grafana, NodeRed, SignalK, etc. is very tempting, but so far I haven't been able to muster the motivation to open that can of worms.

I wonder if they’ve lost the ability to update the n2kview software. It’s written in flash/actionscript, which is no longer supported by adobe. I think they totally screwed me with the last IPG update, now my n2kview can not connect directly to the IPG, I have to connect via the POS cloud service, and don’t get me started on that pile of crap.