We run Dirona like a small apartment with little regard for power consumption, power load or power source. Right now we are moored at St. Katharine Docks in London plugged into 32A/50Hz power. But we run the same way whether we are plugged into 50A/60Hz power in the US or if we were anchored off anywhere in the world. And we can monitor and control our systems remotely, no matter where we are and where the boat is.

This is achieved through a combination of a software automation system with support for load-shedding and auto-start, and hardware that includes cycle-agnostic chargers and both 120V and 240V inverters. Our automation system is managed through a core Maretron NMEA200 system and custom software that we have written running on Windows and several Raspberry Pis. But much of the same result can be achieved through off-the-shelf hardware and software. What follows in an overview of our system and how to achieve it on an existing boat or on a new boat build.

 

Getting the Power System Right

In my opinion the first thing you need to do is to come up with a base power design. If you have a dated design, even with great reporting, monitoring, and remote control, the systems won’t do what you want. I would start with that as a first phase of the project.

As an example and as a source of some ideas, here’s what we did: A More Flexible Power System for Dirona. With this system we can run on shore power connections that deliver less than our peak power requirements, our 60Hz boat can run on 50hz, we can run on poor quality power (200V rather than 240v for example), and we can failover to generator when the shore power fails even when the boat is un-attended.  Boats of any size can support a version of what we did.

My recommendation is to iterate a bit on this and get a design that will meet your needs and support the features you want. If you have an old system that needs upgrading, this will be a big investment and take a lot of wiring pulling. It’s can be hard work but, if you intend to keep the boat for years, it’s worth doing. This is the core infrastructure, so you will want to get it right.

As part of the overall power design, keep in mind that we will be wanting to centrally control major circuits with contactors so there needs to be room for appropriate-sized contactors, or you could choose a set of breakers that can be externally switched. I went the former path but, on a new install, I suspect the latter is a nicer setup. Whatever you choose, you want the capability to be able to centrally control all circuits even though you might only execute that option on ten or so.

 

Monitoring, Display, Indicators, Alarms, and Control

The next phase of the system is to choose a solution for monitoring, displaying, indicators, and control. Many solutions are out there and they are mostly very expensive. You just need to be certain that you can configure them yourself and they have the flexibility you need. Because my day job is at least partly finding small incremental costs that multiply out to millions, it’s hard for me to go for the expensive solutions. It just doesn’t feel right.

We decided to use Maretron for all aspects of the control systems: monitoring, display, warning indicators, alarms, and control (see Maretron N2KView on Dirona for details). This requires you to install NMEA 2000 but a single wire running the length of the boat is no big deal and, once you do that, you can put tees in at key locations and easily expand the system as needed.

In addition to the Maretron systems, we also have some custom systems and software: 1) a central database, 2) a program that takes data from the NMEA 2000 bus and puts it in the database, 3) a program that gets data not on NMEA 2000 and puts it in the database, and 4) another program that makes decisions on the basis of that data in the database and acts on it. But in the early days we had none of these custom software systems. You can go a very long way towards high levels of monitoring and automation without depending upon any custom software. And the entire package will be much simpler using only commercial off the shelf systems. Maretron alone can support much of the functionality we have. I’ll lay out how to do the system without these custom additions and then we can loop and look at what these can add to the system.

Assuming you decide to follow this path, you will have completed and implemented your power system design, installed NMEA 2000, and have N2KView installed on all your devices. This coupled with an IPG100 (the server side of N2KView that also supports N2KView mobile) allows you see all data on the NMEA 2000 bus, to alarm based upon it, to light indicator lights based upon device state or health, and to send SMS or email on problems and sound alarms. This is already a very complete system but you will likely want to add more data to NMEA 2000 and implement remote monitoring. Note that adding NMEA 2000 to an existing build is easy. Almost all of the NMEA 2000 system in Dirona was installed by me post-build.

 

Adding Data to NMEA 2000

Using Maretron N2kview, you can’t display, alarm, or control a device that is not on the NMEA2000 bus. The best ways to get data onto the bus is a fairly lengthy discussion, but the good thing about NMEA 2000 is you can add or change devices or sensors at will. For a weather station, we use a Maretron WSO100. For tank monitoring, we mostly use and recommend FPM100 with Setra pressure sensors. For digital engine monitoring we use a J2K100. For analog engine monitoring we use Northern Lights Wavenet but many solutions are out there that convert between analog engine monitoring and produce NMEA2000 data. In a future post I will write up all of our sensor choices, what we have learned, and why but we mostly use Maretron and mostly are happy with them. Doing this topic justice is a page or so more of detail.

 

NMEA 2000 Problem Determination

What I really like about Maretron is the components are inexpensive enough that I have spares for 100% of it. If anything goes wrong, I just replace the failed component and move on. Swapping in a spare is super-simple for problem-determination and makes a really big difference. Anyone can replace parts but debugging a complex closed system can be very challenging. The combination of a digital meter to detect physical NMEA 2000 wiring faults (I use the Maretron N2kMeter) and a good set of spares makes the system easy to figure out and problems usually get solved quickly. I haven’t even had the meter out of the cupboard for nearly two years.

 

Integrating Non-NMEA 2000 Devices

Some devices are not on NMEA 2000, so you can’t read their state. For example, the fire system on Dirona is not on NMEA 2000. It’s a stand-alone self-contained system. We instrument these by putting a small relay on the triggered state and then sensing that relay using a Maretron SIM100. Anything with off/on state is referred to as digital input and each Maretron SIM100 supports 6 channels of digital input.  With this you can track the state of most non-NMEA systems on your boat.

Non-NMEA 2000 devices also need to be turned off and on. This is referred to generically as Digital Outputs and simply is the ability to turn devices off and on. This can be done by one or more Maretron DCR100s. Each DCR100 supports 6 channels of digital output that can each turn a device off or on. So, if you wanted to turn the air conditioning off and on via any device on the boat, you would have a DCR100 driving a large contactor that is turning the HVAC system off and on. The combination of SIM100s to read data and DCR100 to turn devices off and on really make N2KView a powerful control system. I also use Raspberry Pis for digital input and output and I’ll cover the application of these in a separate post. Note these are not needed for digital input and output—the combination of the SIM100 and the DCR100 can cover both requirements fully.

 

Remote Monitoring and Control

If you are “building along” at this point, you have very good monitoring, indicators, alarms, warnings, email, sms, and control system via Maretron. Through the IPG100, N2KView and N2KView Mobile, you can turn devices off and from any Android, IOS, or computer on the boat. And you can install specialized panels and displays. For example, I’ve got a DSM150 in the engine room showing all fluid levels.

If something goes wrong on any monitored system on the boat, N2KView can send email or SMS. Additional remote monitoring solutions include Maretron’s Telemetic Cloud service. Assuming the boat is always connected by some communications provider and that provider allows calls into their network, you can use Dynamic DNS (DDNS) to allow a remote version of N2KView to securely check and control on your boat systems. It’s cheap and it works well. But most marina WiFi systems have firewalls to prevent incoming, external traffic coming into the boats, many cellular providers have similar restrictions and only allow this under special contracts, so neither of those work universally nor are they available world-wide. .

What we ended up doing is using our satellite provider KVH. We leave the KVH V7-HTS system always on and we subscribed to the KVH static IP feature. With this, our system is always remotely accessible so long as it is the KVH V7-HTS coverage zone, and N2KView will work from anywhere in the world. We can see any system on the boat on whatever device we have at hand, and we can control them as well.

 

Adding Systems

There might be other systems you want to add. For example, solar or wind generation or generator auto-start. For each project you need the basic infrastructure to be extensible enough to be able to integrate into the control system. When adding solar for example, the base power system has be sufficiently flexible to allow this addition and the monitoring and control systems has to be rich enough to be able to monitor and control this new system. Each new system has to be integrated with the Maretron N2KView system.

 

Auto-Start

An example system you might want to add is auto-start. The combination of a Dynagen TG410 controller and some way to send a “start” signal is a good approach and what we did on one of our engines. I wrote up the installation of the TG410 at Two Generators When You Only Have One.

The TG410 allows you to start and stop an engine with a digital signal. Then all you need is a signal to start or stop the generator. You can add this logic to the Maretron system and send the signal using a combination of N2KView making the start/stop decision and the DCR100 sending the signal. Or, even simpler, most inverters come equipped to deliver this signal. In fact, we have exactly this approach as a 3rd level of backup on Dirona: the Mastervolt inverter will send a start signal to the generator controller.

A More Flexible Power System For Dirona describes some of the options you can support with the combination of auto-start and a well-thought through underlying power system.

 

What About the Raspberry Pi?

I use the Raspberry Pis to get digital input, digital output, temperatures sensing, and to display text warnings and issues. My use of Pis is simple and is only 500 lines of code  in total so it’s a great choice for hobbiests. I’ll write up how it works in a subsequent article. But, the combination of 1 or more Maretron SIM100s (digital input), DCR100s (digital output), and TMP100 (temperature sensing) is an easier to implement and probably a more robust solution.

 

What About the other Systems Dirona?

Dirona has thousands of lines of software beyond those described here, so let’s look at what additional features are supported beyond the use of Raspberry Pis described above:

• Database Writer: Takes all data off the NMEA 2000 bus and writes it to the database so that there is a permanent record of data every 5 seconds. We have everything going back years in a nearly 70GB MariaDB database. This data is useful in checking trends, seeing when the generator temp started to rise for example, and for more complex decision making than that supported by N2KView. Maretron’s VDR100 Vessel Data Recorder provides similar functionality and I plan to install a VDR100 on our new tender.
• Dirona Monitor: There is some data not on the NMEA 2000 bus that we want to acquire and write to the database. This is the role of DironaMonitor. For example, it stores in the database status and operational data from our KVH V7-HTS satellite system, our network router, and all data acquired by the Raspberry Pis.
• N2koutput: This program reads the database and implements logic to do more complex control operations than can be supported by N2KView. N2KView supports simple “if-this-then-that” logic but, for more complex control systems, I implement them in N2koutput. In our case N2koutput handles auto-start and load shedding, and synthesizes NMEA 2000 devices that don’t actually exist in the network such as total fuel level (sum of all the actual tanks rather than an actual tank level). I also synthesize an indicator light for our engine room fire system. N2kView without any custom software or programming skills can support many, if not most of these features, although with less flexibility and control.

 

Auto-Reboot

I have a few other unusual features or control systems that have been implemented over the years. For example, the navigation computer is vital in our model and, if it crashes, many things don’t work. We can’t live with it not running so one of the Raspberry Pis keeps an eye on it. If the navigation computer becomes unresponsive, the Pi will force a system reboot and recovery.

I didn’t add these other software system until I had used the core system for several years. The system works great without them and I wouldn’t recommend adding them without an important problem that you just can’t solve any other way. The good news is there less flexible but perfectly adequate solutions using easy to use N2KView support but, if there does come a need, it’s good to know that this can be added without changing anything else. Think of it as a safety net where all problems can be solved if needed. No matter how complex, you could have it implemented in software if it couldn’t be solved with the off the shelf systems described above.

 

Pay Up Front

Our strategy on control systems is to focus on making the boat easier to operate, safer to use, or to require less attention and check lists. We are willing to put up with more complexity in system installation or configuration of it allows us to focus less on these systems over the long haul. If we ever make a mistake in how we are operating boat systems, we look first for how we can automate the action away. Human error is, by far, the most common problem in boat operation so, where possible, get humans out of the equation. When automation isn’t practical, we focus on warnings, alerts, and alarms.

Take bilge water as an example. A very common cause of boat loss in the commercial fishing industry is bilge water building up due to a leak or system fault. The operator doesn’t notice it until the boat gets lethargic and unresponsive to rudder input. Before the problem can be solved, the boat is lost. The first level of defense are automatic bilge pumps so the right thing just happens. The next level of defense is warning the operator. Bilge pump counters, and high water alarms all warn the operator in time to mitigate the problem before the problem becomes more serious.

Our control system focus is to accept complexity of installation and configuration in order to allow the boat to be simpler or safer to operate day to day. We would rather pay up front than be taxed every day. So we have gone bigger on control, warning, or alerting systems than many boat owners, but it’s an approach that works well for us.