Control Systems on Dirona

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.



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.



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.


If your comment doesn't show up right away, send us email and we'll dredge it out of the spam filter.

20 comments on “Control Systems on Dirona
  1. Brian Smith says:

    James, are any of your sensors NOT hard-wired to the Pi? IOW, are you using wifi, or Bluetooth, or any other wireless communication for any of this? I’ve recently built a moisture sensing system with Arduino (for those hard-to-inspect places on Smartini that water sometimes gets), and now I need to get the info to MySQL on my Pi (still in the box – can’t wait to open it up!). My plan is to use LAMP on the Pi, and a really slick looking Arduino library called MySQL Connector Arduino. It lets you connect an Arduino to a remote MySQL db and issue all the common queries (in my case, only INSERT) directly. I’m hoping to be able to wake up the Arduino once an hour (maybe I’ll go to every 5 seconds one day!), read all the sensors, connect to the Pi, and upload the sensor readings, all in about 5 seconds, then go back to sleep.

    Have you tried doing any wireless connections like this? Any words of wisdom? Thanks!

    • Good hearing from you Brian. Your projects sounds like a good one. Yes, certainly WiFi work great on a Pi. I often use this Nano WiFi adapter with Raspberry Pis and it works great:

      These days all the production Pis are hardwired on the thinking that the Pi needs 5v and, if I pull 1 2 core cable with power and ground, I can just as easy pull a cable with a few more cores and deliver both ethernet, power, and ground. Either way, I need to pull a single small cable. I’ve ended up using ethernet on all of them but WiFi works just about as well.

      Since I have ethernet throughout the boat, it’s as available as power so I use it. If ethernet is harder to get than power to some of these locations you want to monitor on Smartini, the WiFi adapter will work great in the Pi. Easy to set up and easy to use.

  2. Chris Barber says:

    Hi James,
    Great article summarizing a lot of related information. I’m hesitant to ask this, not wanting to bog things down in deep technical discussions, but would you mind commenting on the following:
    1) what database are you using?
    2) more detail on how you extract certain Maretron sensor data off the bus to feed to the database writer; e.g. I guess you’re getting all the N2K data via the IPG100? (I don’t have one at the moment in my system) and this presumably produces messages on the IP network that are easily identifiable as those specific temperature sensor values? I ask this because I looked at the N2K data through the USB interface and while I can see the temperature readings as NMEA0183 messages, they are not directly mappable to their corresponding sensors.
    Thanks so much

    • Chris, I use MariaDB as the database. It’s a simple little embedded application but the database actually sees right around 100 requests per second so it’s fairly busy. And, since we store every data point every 5 seconds and have for many years, it’s now grown to over 70GB but it runs well and requires no attention.

      To get data off the NMEA2000 bus I use Kees Verruijt’s Canboat ( It’s rock solid, easy to use, and well written.

      When you said “I looked at the N2K data through the USB interface and while I can see the temperature readings as NMEA0183 messages, they are not directly mappable to their corresponding sensors.” tell me more about what you mean? NMEA0183 sentences are text based and pretty easy to parse. NMEA2000 PGNs are binary and show temperatures in Kelvin but still are not that difficult to parse. Let me know what you are trying to do.

      • Chris Barber says:

        Hi James,
        I just figured out my decoding problem! As usual, going back to look at the data again to make my reply to you prompted another train of thought that led to the answer. I love serendipity.

        So here’s the recap:
        The data coming off the usb interface (maretron’s usb100 or whatever it is) looks like (in my example) temperature values encoded into XDR ‘183 messages in which I can clearly see my specific temperature readings; six temperature channels on the TMP100, six XDR messages. The actual practical problem I had was that the labels in each message were identical! The first two channels from the TMP are for exhaust gas temp, and those were both labeled identically; the remaining four channels for ordinary temperature were labeled as “ENV_INSIDE” or something to that effect, all four of them identical. Even though I’d already verified with the N2K Analyzer app that each of the six channels had a unique label programmed to the device. And these labels in the ‘183 messages didn’t look anything like my programmed labels. At this point there’s no way to tell which value goes with which sensor.

        So just now I reprogrammed all the labels again just to see if anything would change in the messaging coming off the serial port, and sure enough it did. Apparently the USB100 is programatically altering the configured labels to fit the short message format of the ‘183 protocol and also apparently altering the text by adding a prefix such as “ENV_” or “EGT_” or whatever, which to me just wastes four precious character positions.

        When I changed my labels again this morning I made them shorter (I wasn’t actually thinking about truncation, I was just sick of typing things in!) and at that point they still were different from each other after truncation and therefore I could actually see the effect of this difference in the received messages.

        Now I have four temperature messages that I can map to four physical sensors! Thank you for inadvertently prompting me to stir the pot again and discover the solution!

        I’ll take a look at your MariaDB. Are you running that on a Linux machine or what? Left to my own devices I’d probably use SQL Server simply because of my 15+ years of accumulated experience with it but the Express version which is free will top out at 10GB database file size and we’d likely run that out over years of data accumulation without some kind of archiving process.

        Oh, also thank you for the tip on the Canboat interface. I’ve used several canbus interfaces for PC over the years, most are crazy expensive (company paid for them, not me!) and generally don’t live up to my expectations.


        • Chris Barber says:

          Oh, I forgot to say, this result suggests that the N2K analyzer is using some proprietary messaging to obtain even the most basic data off those gadgets, since there’s no way it would be able to differentiate them any better than I could with identical labels. Clearly there is plenty of proprietary messaging going for N2KA to do its job and program the configurations into the devices; I’ll get to the bottom of that too, with a serial port sniffer. As someone famous once said, “this is not my first rodeo” :)

          • Hey Chris. It’s actually not proprietary. All devices have instance numbers that you can assign so, if you have 10 temperature sensors, you would want to configure them with different instance IDs. Unforntutatly, to save space the instance numbers are not included in the PGNs sent out by the device so, as you discovered, they all look the same. There is a protocol dance to needed to build a table NMEA device instances and NMEA2000 device source address. NMEA2000 devices register on the network and get assigned a CANBUS network addess. All messages go out in CANBUS format and include the source address so the devices actually do all look different on the network. The challenge is knowing which message is from the device in which you are interested if those PGNs don’t include instance ID and most don’t.

            In order to match these up, your program needs to build a table of CAN source addresses and device instance IDs. If you listen long enough on the network and watch for PGN 60928 (ISO Address Claim). This PGN includes a lot of unique instance data on the device including the source address and instance ID. However, the challenge is this PGN is sent at device startup but won’t be subsequently sent unless asked for. So, you can send PGN 59904 (ISO Request) with an argument of 60928 with a destination address of 255 (all devices). What you are doing here is requesting that all devices send their ISO Address Claim data. In a few seconds, you’ll have the full table and be able to easily figure out which data on the network came from which device.

            Just listen for ISO Address Claim and build a table of Instance IDs to CANBUS source address. And, if you send ISO Request for ISO Address Claim you can build the table in seconds rather than waiting for all the data. A more primitive approach is to start up N2kanalyzer since it frequently sends the ISO Request for the ISO Address Claim. If it’s running, you’ll get your table of address to instance ID maps very quickly. Although this looks proprietary, it’s actually just N2kanalyzer doing the CANBUS standard protocol dance described above.

            On your point that you would likely just use Microsoft SQL Server, I worked on the SQL Server development team so know it well and was lucky enough to work on the same team as the optimizer team so I had great informal support. So I used SQL server for the central boat database for a decade. But, when I left Msft, I moved to using open source products and replaced SQL Server with MySQL and, more recently, I’ve moved to MariaDB. It’s all running on the Navigation Computer which is Windows since we run some commercial navigation software that is Windows based but everything else on the boat where I have a choice is Linux.

            • Chris Barber says:

              Hi James,

              Thank you so much for this detail. it would have taken me many hours or days to deduce all this from sniffing the bus. I suspected there was something like this going on. And thank you for being part of making Sql Server such a great product during your time at msft. It’s served me (ugh, sorry, unavoidable!) incredibly well over many years. No LAMP for me; I’ll stick with WISC. :)

              • Chris said “No LAMP for me; I’ll stick with WISC”.

                Nothing wrong with using commercial software unless you choose your commercial software provider wrong and they know you are stuck with them. While it’s certainly true that there were a couple of more complex queries that ran well on SQL Server that I needed to be more creative on when using MySQL. But, at least from my perspective, there is great advantage to having the source and owning your future. If you want to move to ARM, no problem. If you decide you want to run the system on a much smaller resource foot and ship it in a appliance format where you care about hardware costs, no problem. If you want to deploy parts of the system on an embedded device, no problem. C# is a beautiful language — exceptionally well designed — except for the fact that it has a declining user base and doesn’t run on as many important platforms.

                There is upside to commercial software but there are some pretty compelling upsides to learning and using open source software. MariaDB probably isn’t as good as SQL Server but it’s good enough and the price/performance is unbeatable. Linux is far better than windows when looking at development productivity, ability to scale down to low resource foot prints, and at least anecdotally, my windows system uptime between reboots is just about always less than the Linux boxes I’m running.

            • Chris Barber says:

              BTW I knew those instance numbers are on the N2K side; I was just saying that I don’t see how any of that gets across to the 183 messaging. The only reason I was looking at the 183 was low-hanging fruit. It’s right there on my serial port and I could read it for zero effort and zero cost. I really have no practical intention of using it when the canbus is just one more gadget away. CanBoat should get me there.

              • NMEA0183 is a one-to-many physical bus where only one transmitter is permitted on a bus and there can be any number of receivers. Consequently, the protocol doesn’t bother to support multiple devices of a single type on the bus and instead transfers the problem to multiplexers and other devices that can transmit aggregated navigation data. It seems to be up to those data aggregating devices to decide which instance is interesting further on down the line.

                CANBOAT is a particularly nice implementation. From the time Keese made it open source back in 2012, it’s hardly changed at all. It’s rock solid, well engineered, and reliable. You’ll like it.

      • Chris Barber says:

        ok, not quite right the first time. The N2KA lets you configure two attributes on each temperature channel: Source, and Label.

        Source is selected from a fixed list of about 32 items. “Source” is a poor name for this attribute, since it really acts as a label. It is the name of the selected Source that actually appears in the ‘183 messaging, and it is the attribute to which you associate a display gadget in N2KView. If you have a meter or whatever reading the value of one of these temperatures and you change the Source attribute on that channel, the meter will stop reading values from it. These source names are e.g. “Inside”, “Outside”, etc.

        In the ‘183 messages they are translated to e.g. “ENV_INSIDE_T”.

        The Label attribute never appears in the ‘183 messages.

        The Source selection includes a number of “User Defined” choices. Choosing any of these causes the corresponding temperature message to never appear on the ‘183 comms.

        So my conclusion is that there is really no practical way to monitor a complex set of temperature readings using ‘183 for data coming from the TMP100. There are just not enough choices in the Source attribute, which is the only thing that appears on the ‘183 message, to differentiate a significant number of temperatures.

        I just ordered an Actisense NGT1 which is the interface gadget that CanBoat is meant to go with. Maybe this will look better without the distortion of the ‘183 translation layer. Other than a CANalyzer (about $90), the NGT1 is the least expensive way to get your pc connected to the N2K bus. I’m glad to have found this thanks to your advice.

        • No, each device on the network has a unique CANBUS address and are unique on the network but it’s a stateful system. You can build a table of devices and their unique manufacturer number and assigned instance IDs to current CANBUS source address. Once you have that table, all PGNS are easy to recognize and you know what they apply to. Described in my comment below in more detail but the short answer is: Just listen for ISO Address Claim and build a table of Instance IDs to CANBUS source address. And, if you send ISO Request for ISO Address Claim you can build the table in seconds rather than waiting for all the data. Or you can “cheat” and just run N2kanalyzer which frequently sends the ISO Request for ISO Address Claim and you can then just passively listen for a minute or so to build up your table of source address to device instance ID mappings.

  3. Evan Bauman says:

    James – thanks for the writeup on your NMEA system. You’ve set a great model for the rest of us that are beginning to work with Maretron NMEA monitoring.

    Can you comments on the Setra pressure transducers that you use in the various applications? I’ve got a couple of the new Maretron submersible sensors in my fuel tanks. One shows rock solid data on my displays but the other blinks in and out. I’ve swapped the transducer channels on the FPM100 and the fault remains on the channel so I know the problem is not with the transducer. Currently working with Maretron tech support to figure this out but I can already tell that an N2KMeter is in my futiure.

    • I’ve used ultrasonic and pressure sensors and have been frustrated by the ultrasonics and just love the pressure guages. For measuring fuel I install A tee on a lower house and read the pressure there. As long as there isn’t high flow, and there isn’t unless pumping fuel, this works very well and is very stable. I plan to use the drop in sensor for black water where ultrasonics only rarely work. I’l probably go to drop in pressure sensors on the grey water as well although the grey and freshwater ultrasonics have been remarkably reliable. If I really like the drop in Maretron sensor, I might replace all all of them (grey, fresh, and black).

      For the rest of the pressure sensors I use the Setra Model 209: These use used on Dirona to read: 1) wing fuel level, 2) supply fuel level, 3) port side fuel level, 4), stbd side fuel level, 5) hydraulic pressure, and 6) transmission pressure. I like the Setra due to accuracy and never faulting but what attracted me to them is the wide variety of pressures supported so you can chose one that covers the range but uses the full range. Enough but not too much gives better accuracy.

      The FPM100, I would drop in a spare and, if it works, flash the old one with new firmware and, if that fails, send it back to Maretron. In my opinion, it’s not worth the investment to chase down obscure issues and as soon as you see another working, you know the problem. This approach makes problem determination an investment of minutes rather than hours.

      • Evan Bauman says:

        Interesting that you have had problems with the ultrasonic transducer for blackwater applications. My first Maretron sensor was their ultrasonic which I installed on my blackwater holding tank nearly 5 years ago. it’s still going strong. I did install with the optional focus tube. Perhaps that makes the difference in reliability? I’ve been tempted to add one to my fresh water tank and will if the original sensor ever dies.

        • I’ve tried everything with the black water sensor including using a focus tube and nothing has been effective but it does work under some conditions. Some toilet paper seems to lead to excellent readings and, as a consequence, we have gone through periods where it is working 80% to 90% of the time. My theory is some toilet papers yield a rough surface on the fluid and don’t reflect well while others dissipate more thoroughly and leave a smooth surface that allows the black water sensors to work well. In Australia, we went through a batch of toilet paper that was excellent. Here in the UK we have gone through a period where it is working great but we changed materials a month back and it’s back to never working. If I could figure out what toilet paper works and what doesn’t, I would go with it but I’ve not come up with any way to predict what will work. My plan is to move to the submersible when I’m next in the US and can pick one up.

  4. Gerhard says:

    32A/50V power ?? should it be 250V

    • It should read 50hz rather than 50V: 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.

      I made that update. Thanks for pointing it out.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.