Our NavNet 3D black box began showing screen anomalies the night before we arrived in Reunion and blue-screened as we neared the dock, reporting an nv4_disp device driver problem. This is an Nvidia device driver–almost certainly we have a hardware problem. NavNet 3D is a Windows XP Embedded device, so we don’t have direct access to the operating system. We tried booting up in Safe Mode, but that blue-screened as well. We tried booting up in VGA mode and that hung. James created a Linux boot partition on a USB jump drive and we booted it up on that, mounted the Windows drive and renamed the faulty device driver in the hope that Windows would use the default Microsoft driver as a fall-back. That hung as well. From Linux booted off the USB, James was able to run graphics and system memory tests and unfortunately they are fine. It’s very probably we have a faulty graphics card.
The graphics card is an Elsa Gladiac 776 GS 256MB. It went out of production around 2006, so finding a replacement on the small island of Reunion wasn’t likely.
We went to Plug n Play, a Le Port-based computer store, in an attempt to buy a low-voltage relay for another project. It turns out Plug n Play is a boutique computer builder focused on exotic, liquid-cooled gaming systems. Their systems are beautiful to look at and can run north of 5 GHz. They don’t stock the electrical components we were after, but pointed us towards a local supplier, Max Electronique, who did. Since the Plug n Play staff know graphics systems incredibly well, we asked about the Elsa Gladiac 776 GS that we need. Of course the adapters they sell are far higher performing and weren’t built a decade ago, but they got on the phone to help us and found a local server sales and service company that might have a compatible graphics adapter. Hopefully they find sucess in their used parts bin.
In addition to working on finding us a compatible used graphics card, Plug n Play offered to test our card to ensure it was a hardware problem rather than a driver issue. That was really kind of them. Our graphics adapter wasn’t able to light a pixel, whereas a similar current-generation Nvidia driver in the same box worked great. It’s now certain we need a graphics adapter.
Even with the failed multi-function display black box (MFDBB), the navigation systems on Dirona have enough redundancy that almost all the navigation data was available. We found that if we removed the graphics card from the MFDBB, even though the MFDBB was running without monitors, it would boot up far enough to start all the rest of the equipment in the network and all RADARs and sensors were available. These we could access through our PC-based chartplotter program, MaxSea, so were still are functional even without the full NavNet 3D system. And if the MFDBB fails entirely, we can bring the system up on a second NavNet 3D device, an MDF8, installed on the flybridge.
The one thing missing was NAV mode, which we really like for longer trips. NAV mode essentially asks the autopilot to steer to a pre-programmed course rather than just in a specific direction. It’s particularly useful in cross-currents and strong winds, or when travelling longer distances.
We initially got NAV mode working through a direct NMEA 0183 connection from the MFDBB to our autopilot. With the MDFBB inoperative, NAV mode also was inoperative. The MaxSea chartplotter system running on the nav computer also is able to drive an autopilot in NAV mode, so our plan was to setup the system to run off MaxSea but to also be able to run off the MFDBB in case MaxSea fails.
In the picture below, James is monitoring NMEA 0183 output from the nav computer to ensure the proper data is being sent. We were able to feed the autopilot from the nav computer to get NAV mode working, and wired it in so that we can change between NAV mode from the MFDBB or from the PC. So it’s now fully redundant as well.
Since we had the systems opened and were making some NMEA 0183 changes, we went through and eliminated any unnecessary NMEA 0183 bus traffic.
In our normal operating mode underway, we have two screens attached to our PC, one showing MaxSea in chartplotter mode and the other showing Maretron instrumentation. And we have two more screens running off the NavNet 3D system, one showing RADAR and the other showing a mixed four-box window with a depthsounder, a monitoring camera view, and close-range RADAR and chartplotter windows. With the MFDBB failure we go from 3 navigation display screens and 1 Maretron instrumentation screen down to 2 navigation display screens and a 10″ Android screen showing Maretron instrumentation. This is not ideal, but is functional, and actually is pretty good.
James — I was reading this article last night on Panbo (http://www.panbo.com/archives/2016/01/kees_cool_sloop_merrimac_home_of_canboat_and_more.html) and when I got to the part that the owner of the featured sailboat developed CANBoat software to control and monitor his NMEA systems, I knew I was in over my head.
But I thought you might be interested in this (if you haven’t already checked it out). It is free open source software that “provides NMEA 2000 and NMEA 0183 utilities. It contains a NMEA 2000 PGN decoder, can read and write N2K messages.” And from what I can glean, it can be loaded on tablets, smart phones and when configured properly, can send alerts to devices off the boat. Website: https://github.com/canboat/canboat
Yes Tim, we do use Kees’ software for our lowest level of NMEA2000 network access. He’s done a masterful job of producing a tight little solution to read and parse NMEA sentances. You may be right that CANboat can do alerting and other higher level functiond. I haven’t seen that. When we picked it up in the very early days, it was a 100% focused on NMEA network access and it does a great job of this.
Overall, it’s a nice small package that does what it suppose to do without hassle and, in those rare times when some changes are needed, it’s not that hard to implement them. CANboat is a nice solution.