Product Development Suggestions

Not open for further replies.


Furuno Fan
Is this an appropriate place to make product development (ie software enhancement) suggestions? If so, I have a few to start:

1) DSC - chartplotter interface. I have seen software that will automatically plot the DSC position of another vessel. It would be great if NN3D could do that.

2) DSC calling -- it would be nice if NN3D kept a "contact list" of DSC numbers that could be automatically obtained from selected AIS or DSC contacts, and it would be even better if the corresponding MMSI's could be passed to the VHF.

3) AIS targets all show up the same -- it would be great if there was a mechanism to identify particular vessels as "buddies" and have those buddy vessels show up in a distinctive way on the chartplotter (ie, maybe in red or blinking or anything other than the normal green).

4) I know that the MaxSea software records bathemetric information. It would be really nead if the NN3D also recorded it and displayed it (in the same way in currently displays chart-based bath. data).

In addition to those enhancements, it would be great to know that Furuno periodically enhances the capabilities of its NN3D software. If it does, I am unaware (although I did register my software).
Thank you for your email. The latest 3D software version (2.07) does most of the DSC functions you asked about in questions 1 & 2, we had a lot of requests for this one.
Color coding buddy AIS targets is a good idea and I will forward it along. We have talked about adding PBG into 3D and it is currently on our wish list.

Again thank you for your thoughts.


We actually send out an email newsletter on NavNet 3D for owners that have registered their NavNet 3D on I grabbed your email address and will manually add it to the email list. We send this newsletter out anywhere from 2 - 4 times a year, depending on the information that needs to be conveyed. I will actually forward you a copy of the last NavNet 3D newsletter we sent out.
I would also like to see a calling feature direct from the chartplotter screen to AIS contacts by mmsi. Also the green color of the AIS target is very difficult to see at times. Being able to change color of the target is a great idea, also turning it red if there is chance of collision at a certain range specified.
I know there are more for this thread, and i will give it thought.
I like the idea of turning AIS targets red if they present a collision danger (especially if based on user-settable criteria). I also agree that the green color is often difficult to read, at least in harbors and other areas where there is other marking on the chart.
Manufacturers are a bit limited on how they can manipulate AIS data. The IMO mandates how the symbology is displayed. If the radar is an IMO radar (anything after July 1, 2008 conforming to IEC-62388), then the standard (non dangerous) AIS symbol color can be changed within the color parameters allowed for the radar. You could do it with pre 62388 radars as well btw, as long as they are non solas or running in a non solas mode. If you are displaying AIS targets on a radar, and the targets actuate a CPA and/or TCPA alarm, then the targets automatically turn red anyway, just as an ARPA target would.

Non IMO radars would have a greater degree of flexibility pertiaing to color pallets.
Regarding AIS targets, I would like to see the ability to disable displaying the AIS target as a "ship" icon. Some targets, not clear what meta-data is necessary for the MFD to decide to do this, get displayed as a gray rectangle scaled to the dimensions in the meta-data (i.e., length/beam of the vessel). This is a cute idea, but in practice when looking at the MFD display it's difficult to integrate the triangles with the rectangles and treat them all the same. I would much prefer to have all my targets be triangles.

A few other suggestions:

1) The MFD, FI-50's and MSTZ should all use the same calculations and damping factors for displaying wind and speed data. The wind displays on the MFD are essentially worthless because the speed and direction data (even with the averaging set to 45 seconds) swing wildly in the space of 1-2 seconds. The true/apparent wind speed is not changing by +- 40% when averaged over 45 seconds; t the direction is not changing by 20-30 degrees, and the little analog speed gauge that goes up to 100+ kts is just wasting screen real estate.

2) Most of the numeric displays have too much resolution. Tenths of a degree for headings, COG, CTS, etc is not useful data. It's just clutter and the flickering data to the right of the decimal is a distraction. It's fine to use internally or to send to another device, but I can't set the autopilot to steer to 305.6 degrees, and I've never known a helmsman who can steer by hand to even a full degree of accuracy. Same thing goes for lat/lon displays, etc. etc., Reducing the resolution of virtually every piece of numeric data displayed by one decimal place would improve the ease of use and readability of the displays.

3) Implement true synchronization between the MFD and MSTZ. The current implementation is really "delete the data on Y and replace it with X". True synchonize would allow changes to be made on either system and then automatically sync the data on the other when both pieces of software are running (i.e., immediately, or at some time in the future). The system could have user set parameters on how to handle conflicts. We're all familiar with how data is truly synched between devices (e.g., your computer and your smart phone via the cloud). It's time for NN3D to really sync data, not just delete and copy.

I'd like to echo Russ's comments about excessive precision in many numeric displays and on implementing true sync between NN3D and MSTZ.

With respect to the numerical precision, in addition to the items he listed, depth needs to be addressed. Reporting depth to a tenth of a foot in 90 feet of water is meaningless - but reporting to a tenth in skinny water in the Bahamas, where you may have less than four feet below the keel, could be useful. So, allow the user to select a threshold depth below which one decimal place precision will be displayed. Otherwise, and by default, display in whole units.

I also strongly suggest a review and changes to some of the operations available on right clicking, e.g., a route.

For example, after creating a route if I select it and right click I get a list of choices. Among them are routine operations such as Rename or Details. But along with those is Delete. In rough seas or with a fat finger it is too easy to make "destructive" changes such as inadvertently deleting a laboriously created route. Critical operations such as Delete should generate a pop-up asking for confirmation and require a confirming click before the change is made. This is not needed for things like renaming, of course, as errors there are trivial to resolve. Recreating an extensive route due to one errant click is not a happy experience.

Adding to the point about precision, the FI-50 log readout is in whole miles, which is insufficiently accurate for old school DR navigation.
(Maybe I should be using GPS log these days)
Personally I would love a "restart XTE" command from the rotoknob when navigating to a waypoint. Currently you have to right click the highlighted route to do this and it can be quite a challenge at speed in a sea...
Another suggested improvement: Provide the capability to hide the inactive cursor or at least center it on the boat position. If you have cursor position displayed in one of the data boxes it can be confusing and a distraction when you are no longer interested in the cursor position.
One more: It would really be nice if the Navnet 3D instruction manual were loaded on the MFD hard drive and it was accessible from the MFD.
Another Suggestion: Why not automatically save the water depth and temperature in addition to the lat/lon when you mark a point at your current location?
High Voltage-
Good suggestions.

In case you weren’t aware you can set your track feature to change color based on depth range or depth variation.
You can also set it to change color by temperature or temperature variation. Variation is especially useful while trolling or drifting to locate the temperature rip. A couple of passes and a pattern will become evident.

Put a switch on:

The GPS WAAS alarm - very irritating if the GPS loses WAAS for a few seconds.
The Heading alarm - for some reason, the MFD will report loss of heading when if fact it is still on the N2K network.

So, please, put a config setting to ignore these alarms. Maybe for a time period? No WAAS or heading data for 3 minutes, then sound alarm.
Hardware upgrade...??

Faster cpu, solid state hard drive/larger size, Windows embedded v 7, lower power consumption.

Offer a send in, replace board, return service for a reasonable price....$500?

The screen size/resolution is fine, give us a plan for investment protection.
Windows RDP or Splashtop on the existing MFDs?

A great investment protection feature! (couple with the hardware upgrade in previous post)
Would like to see if it is the works to have other Lat Lon formats available on the NavNet 3D
All my Old numbers are in the DDD'MM.mmm My NavNet only has the DDD'MM.mmmm format available. Just adding a 0 to the end of my numbers does not work. I saw on the New TZ system it has this format along with a few other formats mine does not have. Is it in the works to add this in a software update soon.

Two things..and I am not sure the first belongs strictly under this Product Development thread:

1. Furuno has made a big call to commit to AXIS network cameras for NN3D. I think AXIS ought to be asked to reciprocate somewhat by reflecting on their website what products work with NN3d. Using the Search function on the AXIS website, 'Furuno' and 'NN3D' bring up nothing. There is a list of AXIS cameras on the Furuno FAQ site, but something on the AXIS site itself would be appropriate/helpful.

2. When booting up, my MFD12 is at full brightness until it is fully booted up...when it reverts to the last brightness setting. By that time, night vision is destroyed (ie: system dimmed for night work; then shut down for whatever reason; then re-booted still at night). I suggest the bootup routine use the last brightness setting so this doesn't happen.
Not open for further replies.