Question back for you, Richard - How serious are you about wanting to do predictive analysis? Like you, I hoped I could do some of that graphically. I have been capturing screenshots of graphs generated with N2KView while UNDERWAY since 2009 (examples attached) and it’s proven beneficial for confirming suspicions usually driven by other evidence - Not at all predictive. For example, after finding EEGT temps running hot, I could reference the archive to see that they didn’t run hot last season in similar conditions, etc. Predictive work, in my experience, necessitates logging the desired metrics to a database. With actual data values, I crafted some simple algorithms in a spreadsheet and this provided an interesting tool to drive investigations ahead of other surfacing evidence. Lately though, I have been packaging up subsets and feeding it to xAi along with a developing set of explicit queries to learn more. I anticipate commercial developments on this front in the not-too-distant future; the key though will be supplying the right amount of data ongoing to make this as predictive as possible.
So, what is the best way to capture and log NMEA2000 backbone data?
The most comprehensive, flexible, and cost-effective approach I am aware of is to log data into Influx-DB on a general-purpose computer (NUC or Raspberry Pi) which collects Bus Data using SignalK. You can then use Grafana to develop graphical outcomes on your dataset or export subsets for analytical work that I described above. Steve Mitchell has a good article on how to set up such a device. https://seabits.com/set-up-signal-k-and-grafana-on-raspberry-pi-with-pican-m-nmea-2000-board/ - for an overview of Signal K, see https://signalk.org/overview/
Currently, I use N2KView for data collection - Rather than capturing everything, I am able to do this on a modal basis (e.g., underway), and interval-controlled (every x minutes), and single events triggered with an on-screen “button”. The latter works great for sea trial data collection. N2KView writes the collective sets of named mechanical, thermal, and electrical metrics to named .CSV file(s) which can be opened directly for review and analysis in a spreadsheet or uploaded for Ai analysis. N2KView, of course, also generates graphical presentations of recent data and handles all the local and remote alerting.
So what about MConnect?
I did a lot of work with one over the last 2 years - here’s why it is no longer hooked to my bus (aside from the fact that my bus is full):
1. It lacks the capabilities of doing any data logging and likely never will.
2. It lacks many critical features necessary for actual vessel monitoring, in particular alerts, etc.
3. It has a limited set of UI designs, none of which appeal to me - all too hard to read and/or gamey.
4. It has the ability to design your own UI if you are good at Photoshop and have dozens, if not hundreds, of hours to put in. But when you do this UI work, some of the controls become compromised, and some lose their more sophisticated functionality.
5. The development interface is very basic (barbaric) and requires lots of futzing to “get what you intend” as a result.
I worked hard on testing and helping Maretron write a converter for existing N2KView configurations. They know my N2KView design is very likely the most complex out there, and after many rounds, they were able to successfully convert about 90% of it. Impressive, but I didn’t care for any of the graphic UI presentations and am still surprised that none of those offered to mimic the original N2KView look.
While not marketed as such, it’s pretty clear MConnect was created to capture large volume boat manufacture (OEM) deals who, like auto makers, want to develop their own branded look for dashboards on their production boats. These companies have the talent or the money to finance the development of a one-time UI that is a unique look and feel to match their boats’ style.
N2KView isn’t just full-featured; the development aspects are far more accessible to the novice, and the UI complements the look of TZ Pro and Rosepoint CE. (See attached image)
Bottom line, N2KView lets me do selective data logging. Mode-driven, interval-driven, and manually driven. To do this and other more sophisticated monitoring, you need to run N2KView on a Mac or Windows-based NUC. I am not a fan of the BB devices for many reasons. As mentioned, an additional bonus with such is that you don’t need phone apps or to open and manage Internet ports, etc. - I simply log on to the NUC using a preferred Remote Desktop App that supports VNC, and I have instant access to everything - N2KView, CE, TZPro, Vessel Security System, Cerbo GX, and more all through a single portal. This works while aboard even without the Internet or remotely when the Internet is provided. I use a small, low DC-powered industrial-grade NUC as an always-on device running Windows. It’s able to host Signal K, N2KView, TimeZero, Rosepoint CE - so instant access to all sorts of planning and data while aboard via the LAN as well as remote via WAN. This avoids all the clutter and nuisance of a bunch of Apps on our phones and pads. This PC also acts as a first-line backup for Navigation if the larger Navigation Computer should fail while underway.
Happy to explain in more detail and help you craft the N2KView elements needed to log data.
Carl & Melody Gulledge
MV Ellipsis
Selene 5906