Panbo

NN3D & N2K, sweeeet!

... written for Panbo by Ben Ellison and posted on Oct 31, 2007

NavNet_3D_Network_Diagram_lr

Yes, a first look at Furuno’s NavNet 3D had me burbling “incredibly sexy”—and I will explain that!—but today let’s talk about how thoroughly the 3D system embraces NMEA 2000. For starters there’s a standard N2K connector on each of the three NN3D displays, and the Product Guide lists lots of specific standard PGNs they can input and output (so there should be no Garmin-type data surprises). Now check out a bigger version of the NN3D “building blocks” diagram above to see how many N2K sensors Furuno itself is offering. Besides the FI-50 instruments already discussed, there’s an interesting N2K SC-30 GPS Heading Sensor (said to be reasonably priced and very accurate), an N2K Weather Station, an N2K Smart Transducer, and an N2K GPS.
   Now at least a couple of those are obviously rebranded Airmar products, but note too the odd “Ethernet…dotted line…NMEA 2000” label on the UHD Radar Sensors (mentioned yesterday). You see each of those scanners has an N2K connector on it, able to both power any of the Furuno N2K sensors and take their data, packetize it onto NavNet, and deliver it around the boat (and beyond, if and when Furuno decides to extend NavNet like, say, N2KView). The sensor data coming through the radar scanner is available to any manufacturer’s N2K device via the NN3D display’s port, and I’m told that any N2K data, even proprietary PGNs, going into that port is put onto NavNet. The installation possibilities are pretty amazing. Like radar, weather, and GPS from an antenna mast with only one power cable and one Ethernet cable. At any rate, Furuno may be one of the last of the big marine electronics manufacturers to adopt NMEA 2000, but, man, didn’t they!

Comments

Just to pick a few nits, 1) where do you see the N2K GPS?, 2) do you think they put radar target data on the N2K network?

Those nits aside, I'm leaning towards Furuno because they're using standard cabling. Simrad/B&G and Raymarine both have proprietary cabling which means rewiring in the future to switch vendors. I'm stopping that train before it leaves the station.

Regarding the transducers, everyone uses Airmar so there is no shame in Furuno lining up behind Raymarine, Simrad and B&G. The question is why the others aren't using the N2K versions of those sensors.

When I asked Furuno about the data translation between 183 and N2K, I got a directional statement, not facts. I think they would like to translate as much as possible, but it's not clear what they will translate with rev 1. But it's way more complicated that just doing a translation.

I have some questions about the network and all those sensors. Look at the scenario that Ben just painted. Let's say you connect all that stuff together. Which depth is used by your system, the depth from the fish finder, or from the depth/speed/temp transducer? And the weather sensor has it's own GPS that puts out all the GPS sentences/PGNs. So if you connect the weather sensor and the GPS, which data is on the bus? Both? Let's assume they don't put out the exact same data, will that drive your plotter nuts when it's trying to calculate your XTE? Will it confuse your pilot? Can all these sensors be configured to only output what we want them to output?

And the weather station also calculates "true" wind. Is that the same as "ground" wind? Which "true" wind is it? Is it the same calculation as is done by the MFD or some vendor's device which is also on the network?

Who / how is this abundance of data arbitrated?

Ben is probably one of the few guys who has actually put together an N2K network. How does this stuff work?

Posted by: Russ at October 31, 2007 7:41 PM | Reply

What if you want several GPS inputs for redundancy, or two speed logs. Can these networks deal with that?

Posted by: DefJef at October 31, 2007 8:06 PM | Reply

N2K definitely supports multiple Instances of the same sensor type, but there seems to be a fair bit of variation on how that's handled by different displays. Simrad seems the most thoroughly configurable. I saw at Lauderdale how two instrument displays in the same SimNet could be told to listen to different depth transducers, which could be useful on a very wide or very long vessel. But automation can be good too. The Ray E. seems to grab the first GPS it sees, but if that one fails it will look for another.

Posted by: Ben at October 31, 2007 8:23 PM | Reply

Russ, There's definitely a PGN for Tracked Target Data (Message for reporting status and target data from tracking radar external devices). But NMEA's PGN list, (http://www.nmea.org/pub/2000/NMEA2000PGNs.pdf)
doesn't give PGN numbers, so can't be correlated with Furuno's list of numbers. Drat!!

Posted by: Ben at October 31, 2007 8:35 PM | Reply

The PGN link you posted is very top level, no PGN format data but I imagine that the source id of the data is prefixed onto the actual data to support multiple sources. The question, as you point out, is how the consumers of the data select which to use.

Take an extreme case where I mistakenly tell plotter #1 to go to X and plotter #2 to go to Y, and they both output autopilot instructions to the network. Plotter #2's NMEA 183 output is wired to the autopilot, but also translates all the N2K PGNs (including what it receives from #1) and puts them out as well. Two conflicting autopilot instructions are issued every couple of seconds. The pilots are all still 183 devices. What's it gonna do?

Ironically, these kinds of problems could lead us more toward a single vendor network where these problems would presumably be rationalized with the same set of guidelines. A multi-vendor enviornment where Furuno resolves the question with one technique, Raymarine with another and Garmin with a third, may be much less reliable and more difficult to manage than with 183 where we control it with physical wiring.

Posted by: Russ at November 1, 2007 12:12 AM | Reply

"Ironically, these kinds of problems could lead us more toward a single vendor network where these problems would presumably be rationalized with the same set of guidelines."
>> that is a sobering realization.

.... "more difficult to manage than with 183 where we control it with physical wiring."
>> that is a sobering realization as well.

Posted by: Dan (b393capt) at November 1, 2007 9:31 AM | Reply

Hmm, are you sure that the dashed line means that each of the radar scanners has an N2K connector? To me that just implies that the image is sent via propriatary ethernet format (as they do now) to a processing box. If I were to guess, all that it means is that you can control some features of the radar through N2K, not that the radar signal gets sent out on the network to any non-Furuno system.

Note that when they want to indicate that a device supports both 0183 and 2000 (such as the GPS antenna) they show both boxes without a funky dashed line. From my experience in the computer industry, beware of dashed lines...

Maybe a photo of the connector will help cure my skepticism.

Posted by: George at November 1, 2007 10:20 AM | Reply

George, I haven't actually seen the connectors but the Furuno literature is pretty clear: "All NavNet 3D radar sensors incorporate a NMEA 2000 port to which certain NMEA 2000 sensors can be directly connected." I've also had the architecture explained by a Furuno product manager. I'm pretty confident about what I wrote.

Posted by: Ben at November 1, 2007 10:31 AM | Reply

Each device on an N2k network has an ID. It's just like your computer network at work (or on the internet itself). Your NN3 would likely see every GPS antenna on the network and you would specify which one you want it to listen to. Getting the ID's for each device wouldn't really be too tricky. Worst case, add one at a time and rescan. The new ID that shows up will be the device you just added.

As to what data the sensors provide (true wind, etc), that's really a question of how the sensor is made. If the weather station is really airmar's, look up how that one works.

Interesting point here is that the navnet.com website shows the existing navnet 2 GPS antenna as the recommended gps sensor. To my knowledge, it isn't N2k compliant.

Posted by: Cameron at November 1, 2007 10:46 AM | Reply

Well, OK then -- but I caution you that dashed lines in this context are always a form of weasel wording. The "certain NMEA 2000 sensors" is a weasel right there.

Has somebody who really knows actually said "The sensor data coming through the radar scanner is available to any manufacturer’s N2K device via the NN3D display’s port?" That would be a pretty bold break with tradition for one mfr to allow another's display to show their radar output. It would definitely be great, but I have a hard time imagining the bean counters letting that one through. I'd love to buy a Furuno scanner and hook it up to coastal explorer on my laptop, but then Furuno is out about $10K in display hardware from me.

(Perhaps I misunderstood what you are trying to say -- perhaps you mean that I can hook my wind gauge to a Furuno radar NMEA 2000 port and then see the data elsewhere on the NMEA 2000 network, saving me one tee connector. Is that all that you mean?)

That said, it would certainly be cool if the radar could operate as a NMEA 2000->ethernet bridge. Then I would only have to run one signal wire down the radar arch.

Posted by: George at November 1, 2007 10:51 AM | Reply

Yes, George, someone who really knows told me that. But "sensor data coming through the radar" means just that, not the radar imagery. "Certain NMEA 2000 sensors" means ones Furuno sells (others might work, but the ability of the scanner to packetize is apparently limited).

So this is not about shared radar (don't we wish), but about easier installs...one data wire from an antenna farm.

Posted by: Ben at November 1, 2007 11:35 AM | Reply

Make the installation simpler? How so, you would always connect your chartplotter to N2K as well anyhow.

I think it's more basic then that. The designer of the radar system may just want as direct access as he/she can get to the fast heading information on the N2K bus, to improve MARPA performance.

Otherwise that 10 x per second heading sensor data would first have to traverse a chartplotter software, and then the ethernet, to get to the radar units software. My understanding is that ethernet is a less than ideal relay of time stamped and time sensitive information which, especially prior to this new IEEE spec, may be less so as people jam video and audio signals onto it. Even more significantly, I imagine chartplotters running on either Windows and Linux are potential sources of delay in getting the heading sensor data off N2K and onto the ethernet bus, to be fed to the radar ... especially at the point your scrolling, rescalling charts, or otherwise opearting the radar functions on your plotter.

Althought nobody may be saying so just yet, it seems that you should plan on connecting your radar to N2K for just this reason (direct access to compass heading), while expecting the radar image to go out via internet.

Posted by: Dan (b393capt) at November 1, 2007 1:12 PM | Reply

... um, I meant to write "out via ethernet."

Posted by: Dan (b393capt) at November 1, 2007 1:16 PM | Reply

Is the radar potentially powered from N2K as well? Not sure that is a benefit considering it would eat up a good % of the power capacity of the bus.

Any chance this new revolution in radar offerings includes standardized power cabling across vendors and many sizes for radar? Then we could potentially upgrade in the future without replacing power cables

Posted by: Dan (b393capt) at November 1, 2007 1:20 PM | Reply

I received a reply from Airmar and they say that the output on their new PB200 weather station/GPS/heading sensor can be controlled so that it only transmits the desired sentences.

Regarding the radar sensor having an N2K port, at the moment it's kind of moot since the only N2K sensor they currently offer is the speed/depth/temp which presumably is not near your radar!

I suppose the new PB200 could be located near the radar on a power yacht, and in the future they will presumably upgrade some of their other sensors.

Unfortunately I think we'll be stuck with three kinds of cabling for the forseeable future. Too many 183 devices, no simple way to bring N2K into your computer (Maretron bridge is expensive compared to 183), neither 183 or N2K have the bandwidth to carry video.

Posted by: Russ at November 1, 2007 1:22 PM | Reply

"Regarding the radar sensor having an N2K port, at the moment it's kind of moot since the only N2K sensor they currently offer is the speed/depth/temp which presumably is not near your radar!"

Russ, NavNet 3D won't ship for a few months, right? So don't you think they'll have all the N2K sensors I listed and that are shown in the diagram above? (And note that diagram is an update from the printed one in the Product Guide)

Posted by: Ben at November 1, 2007 1:42 PM | Reply

It would be even easier if Furuno had used the NMEA 2000 cabling for their radar image (even if the image data is implemented with a proprietary PGN.)

Using their solution means that you have created an island of NMEA 2000 devices away from the boat's backbone, connected by an ethernet bridge to Navnet that "might" support some NMEA 2000 sensors other than what Furuno sells. Good luck adding a sensor later -- they will just roll their eyes at you and say it isn't supported. Not exactly what we were promised with NMEA 2000!

What you really have here is a NMEA 2000/NavNet bridge that is electrically compatible with the NMEA 2000 cabling, but it really cannot be called a NMEA 2000 connector by anybody except the sales department. I would expect installers to ignore this connector for any but the smallest installations, since it completely puts you at Furuno's mercy.

Don't get me wrong, I like Furuno's equipment a lot and can even see why they are doing this (so they don't have to implement both Navnet and NMEA 2000 on their instrument clusters.) It just is not a tremendously inspiring feature, and I bristle a little if they claim that it is NMEA 2000 without committing to supporting it.

By the way, keep up the good work. I'm not ragging on you; I tremendously appreciate your dedication and this blog.

Posted by: George at November 1, 2007 1:59 PM | Reply

Geez, guys, no way that NMEA 2000 has the bandwidth to carry radar imagery or the amperage to run a conventional scanner. Just wasn't meant to be.

And of course you can run an N2K backbone or T up to the antennas, and it might be the best plan. Furuno is just offering an option, that's all.

Posted by: Ben at November 1, 2007 2:09 PM | Reply

Ben,

Apologies, I had assumed it was the same diagram as in the product brochure. I see two differences: 1) N2K GPS and 2) N2K weather station. The weather station we've discussed, probably could be in proxmity to the radar on a power boat. The N2K GPS would be nice because it could also be on the radar mast, again more likely on a power boat, but possible on a sailing vessel (is my bias showing?).

Regarding George's comments, Furuno fully expects third party N2K devices to be connected and supported by the system. Most obviously the PB200 since that is a product they OEM from Airmar and only change the graphics. They also told me they would support N2K tank sensors and provide tank level displays. I don't think George is accurate it in calling the Furuno system just an N2K/NavNet bridge.

I expect that Furuno will move all their products to N2K as they update the various components in the coming year(s).

Let me be clear that I believe Furuno has made a total commitment to N2K as evidenced by their standard cabling, while Garmin, Raymarine and Simrad have all made a very half hearted and ambiguous commitment with proprietary branding (SimNet, Garmin Marine Network, etc.) and proprietary cabling schemes. Cabling is the nemesis of all wired electronics. What do you think will be easier to obtain, a standard N2K connector/cable, or a proprietary connector/cable?

That said, I believe that in a multivendor N2K network the issues of data arbirtration and rationalization that will arise have not been fully explored or addressed and I expect some bumps in the road.

Posted by: Russ at November 1, 2007 3:06 PM | Reply

Ben, your graphic replaces the plastic N2K "smart sensor" for depth/speed/water with a bronze sensor. Is it just a different graphic or is it a different sensor?

Posted by: Russ at November 1, 2007 3:36 PM | Reply

I wrote earlier "The designer of the radar system may just want as direct access as he/she can get to the fast heading information on the N2K bus, to improve MARPA performance."

I don't think the designer is fixated on getting fast heading from a Furuno N2K product.

I think it makes a lot of sense to have the N2K connector there seperate from the ethernet for the reasons I stated, and expect that to be the normal installation for this product.

And for an installation norm, that's not an expensive one to follow thru on, after all, if your going to run ethernet to your new Furuno radar, your might as well simultaneously run N2K for use with future co-located sensors while your going thru the trouble.

Posted by: Dan (b393capt) at November 1, 2007 5:31 PM | Reply

OK, I'll admit that my point is very much a nit but I think that there is an important issue underlying it. I was involved for a long time with a software standard (SQL 92, which dates me) and I have learned how this game is played. It is up to you to keep the vendors honest; they are not committing to a standard for the general good or anything like it.

I do not know what the standards are for N2K certification, but I would be surprised if "might be compatible with some other N2K systems" meets it. Hence, the dashed line on the diagram for the N2k/Navnet bridge. The bridge that Furuno is offering is a neat thing, but unless there is a committment to making it work with every valid N2K implementation then it really shouldn't be referred to as a N2K port and the radar shouldn't indicate that it is N2K. It is exactly the same issue as the Garmin, and the more that you let the manufacturers get away with it the less useful the standard will be.

I'm not demanding that it work out of the box perfectly on launch day. I'm demanding that if they call it a N2K port then they commit to spending engineering resources to resolving any compatibility issues with other valid N2K implementation. Note that it would be fine by me if they simply labled it a Furuno port that happened to look a lot like an N2K connector and didn't stick the N2K label on their radar.

Regarding radar on N2K: As I understand it, N2K is derived from Canbus which has more than enough bandwidth for a radar picture. I believe it is 1megabit/sec for up to 40 meters; traditional ethernet is only 10megabit/sec, and that can handle an office full of people sending live video around. It would have been extremely poor planning to standardize on a marine network system that couldn't handle the bandwidth from a radar, and to their credit I do not believe that the N2K committee did that. However, it will probably be some time before we see scanners that can be hooked up directly to n2K because it is not a trivial amount of engineering. There will, however, be a bunch of radars labled "NMEA 2000!!!" for marketing purposes.

Posted by: George at November 1, 2007 5:35 PM | Reply

George,

Regarding the nit, on the radar I suspect you are correct in that it's really a bridge to NavNet and they aren't certifying that they will bridge an abitrary PGN. For that matter, they aren't certifying that they will bridge arbitrary PGNs anywhere in the system. Let's see what the manuals say when they become available.

Regarding images on N2K versus ethernet, you're way off. N2K is 250Kb (download the presentation from the NMEA site). No way are you going to get video across N2K in the quality that we all want. The original Ethernet was 10Mb, but that is ancient history. Most computers purchased within the last two years are gigabit. I believe NavNet was originally 100Mb, but given the backwards compatibility of Ethernet, the new MFDs and radar could easily be gigabit and they can move up the speed of other components as they are replaced.

Furuno has made the right choices on networks. I think the problem is that N2K was conceived so long ago, and then has taken so long to be adopted, that it's almost out of date. Fortunately we have a lot of slowly changing text data that can be reliably carried on N2K. But if the N2K design had started with Ethernet we'd have a much simpler topography today, better economics and a clearer path into the future.

Posted by: Russ at November 1, 2007 7:05 PM | Reply

George-
You are reading too much into this. I went to the Lauderdale show and I talked with Furuno.
The radar is not N2K. There is a standard N2K connector on each radar to make installation of additional equipment easier. A very clever design for the MAJORITY of boaters that buy and install THEIR products. They will have a new N2K GPS sensor that plugs into it. You can also use an Airmar PB200 N2K sensor. Pretty simple and well thought out. Why are you making a federal case out of it?

And BTW- NMEA 2000 was NEVER planned or developed to handle video, just data.

Posted by: Arnie at November 1, 2007 7:28 PM | Reply

Russ, you have good points (250kbps???! That is only about 3 times better than a 9600 baud modem) but you forget that radar is not video. Imagine watching a movie on radar screen at 24 RPM. That would mean each frame would take 2.5 seconds to redraw. Note that it is silent, black and white, and low resolution. Note also that according to Mr Google TV video is 30 frames per second with full color and sound.

Now they have already decided upon N2K so I won't beat a dead horse, but Navnet was 100 mbps because cheap hardware for driving twisted pair already existed -- not because it had to be 100mbps. I see people talk knowingingly about latency, packet loss, and collision in ethernet without realizing that they are talking about issues for incredibly large networks of systems of specialized equipment that require guarenteed millisecond response time (such as telephone switches). Nothing is impossible, but it was very unlikely that any of the issues with the ethernet protocol would affect the tiny network that even the largest boat could produce. Yes, youtube videos take a long time to download but that has nothing to do with ethernet latency, and a lot to do with other issues that are way off topic.

I'm not going to criticize Furuno for not putting radar signal on N2K, but it sure seems technically possible. Perhaps Sitex/Koden will do it someday if N2K really takes off -- which it could once boats start coming prewrired for it.


Posted by: george at November 1, 2007 10:29 PM | Reply

OK George, my last post on this subject.

First, that 9600 baud modem = 9600 bps = 9.6Kb (yes technically buad = baudot code, a five bit code developed for teletypes in the 40's, but in practice when used in reference to modems it meant bits). So N2k is about 26x faster than that old modem. Not blazing, but good enough to move boat speed, wind speed, etc. around the boat.

Beg to differ, but radar is video. Maybe not NTSC video, but it's video (BTW so is a high end fish finder). My NavNet radar puts out a 640x480 picture. Let's assume they use 4 bits to get 16 colors. That's 1.2Mb per frame x 24 frames / minute (until you switch to a 6' open array and 48 RPM), divided by 60 seconds is about 490Kb of data per second or 2x the bandwidth of the N2K network. It's not happening on N2K.

Ethernet does not guarantee response time. The beauty of ethernet is not guaranteed time of arrival, it's just guaranteed delivery. It's a collision detection network, no guarantees on packets arriving on any particular schedule. That's why buffers were invented; they create the appearance of packets arriving on schedule. It's like if you watch a football game on Tivo and you don't know the outcome, it's live for all practical purposes.

Finally, I completely agree that they used 100Mb ethernet because the hardware was cheap. And they're probably using gigabit today for the same reason; it's produced in the hundreds of millions of units per year for PCs and data networks. We fortunately get the benefit of that low cost because Furuno chose to ride that cost curve and not the cost curve that would be associated with a proprietary transport (like FastNet).

Posted by: Russ at November 2, 2007 2:13 AM | Reply

Actually, Koden's radar boxes that they supply to Nobeltec and Simrad are already Ethernet from the box to the PC. I would assume that a future step would be to put the radar box in the scanner. My Koden radar box contains a +- 20x15 circuit board that could easily be miniaturized a little and then packed in the scanner.

Why would they do it over N2K? What is the value? PC's (which is what the plotters are in disguise as well) have built-in Ethernet and the network stack is utterly reliable. Putting it on N2K would be more engineering work, not less...

Posted by: Kees at November 2, 2007 4:38 AM | Reply

I believe that the new Raymarine and Furuno radars do all processing in the scanner case, as do recent radars by Northstar and Garmin. And all of these Ethernet to a hub, which means that any working display gets the output; there's no "master" in terms of radar. Open standard radar over Ethernet would be neat, but is not in sight. As for radar over NMEA 2000...I don't think so, but it did get Russ going ;-)

Posted by: Ben at November 2, 2007 7:58 AM | Reply

Well said Arnie. It appears that there are a few people jumping to conclusions without knowing the facts. Just to reiterate to those who are finding it hard to understand......the Furuno Navnet 3D radar signal is sent via the (100)ethernet to the MFD and not via N2K (as George thinks). As explained earlier the N2K port on the radar is a simple N2K connector (HUB) that will allow N2K sensors (inn the facinity of the scanner / dome on the mast) to be interfaced to the network without having to run a N2K back bone up the mast to pick up just one or two sensors. Well thought out Furuno!

Posted by: Wildfish at November 3, 2007 7:39 AM | Reply

Wildfish wrote: "As explained earlier the N2K port on the radar is a simple N2K connector (HUB) that will allow N2K sensors (inn the facinity of the scanner / dome on the mast) to be interfaced to the network without having to run a N2K back bone up the mast to pick up just one or two sensors."

Some questions on this :
1. Is it bi-directional (e.g. sensors can receive N2K information as well) ?
2. Is it dumb and vendor nuetral (e.g. will it forward all PGN's in both directions) ?
3. Will it function when the radar is off ?
4. Will it function when the chartplotter is off ? (e.g. can my wind displays in my cockpit show wind speed/direction for a sensor up on the mast that was routed thru the Furuno radar dome)
5. If I instead, keep my own N2K backbone up my mast, and connect it to the Furuno
5(a) Will the Furuno avoid transmitting my sensor N2K information thru the ehternet ?
5(b) Will the Furuno use fast heading information it sees on the N2K connector ?

Thks,

Posted by: Dan (b393capt) at November 5, 2007 10:15 AM | Reply

B393capt, those are "hard facts" questions and maybe someone close to the manufacturers (like Ben) can put those questions directly to them.

I am merely pointing out that radar images / video (whatever) that requires high bandwidth will not be transmitted on the Furuno network by N2K as some folks are assuming here.

However, you have brought up some very good points. Especially about the mast sensors (N2K) plugged into the radar N2K port.......will they transmit data to the rest of the N2K netwrk when the radar or MFD turned is off?


Posted by: Wildfish at November 7, 2007 8:14 AM | Reply

B393capt: Those are great questions. Have you considered submitting them directly to Furuno via their web site support "Ask Furuno"? I'm sure we'd all like to hear the answers.

Posted by: Russ at November 7, 2007 11:20 AM | Reply

Sure, I can post on Ask Furuno.
Done

Posted by: Dan (b393capt) at November 7, 2007 2:40 PM | Reply

Russ,

No answer yet from Furuno, other than it is a new product and they will get back to me in a few days (as of nov 11th).

Posted by: Dan (b393capt) at November 21, 2007 7:10 AM | Reply

Russ & Everyone,

Here is a response from Furuno, if you have other questions, I can forward them on this ticket.

From Furuno:

Hello Dan,

I have received some information.

1. The NMEA2000 data flow will be bidirectional.

2. It will not be vendor neutral because some vendors do not actually use NMEA 2000 but do a conversion from 0183 to NMEA2000. To work with NavNet3D a system would need to be true NMEA2000.

3. It will function with the radar off (standby) in the NavNet 3D.

4. The data will NOT flow through the NavNet3D with the unit powered down.

5. Still looking for the answer to these questions.

If you need any amplifying information on the above responses let me know and I'll do my best to find out the information for you.

I'll consider this question open until I find out additional information for you. If you do get an auto generated response please write back to keep it open. Thank you.

Posted by: Dan (b393capt) at November 21, 2007 12:28 PM | Reply

Dan - Thanks for the followup. A couple of comments on:

2. To be generous to Furuno, it seems like it is vendor neutral if the vendor is N2K compliant.

4. This is not so much a Furuno specific problem, as it is an N2K system design trap. Any data routed through a specific device, is subject to the availability of that device. The issue is not whether or not the device is powered up, it's the failure mode. I believe the disk based systems will have a shorter MTBF. When the plotter dies, signals that relied upon it die as well. Relying on the plotter to act as a router or data conversion facility (i.e., 183 - N2K) is risky.

Everything should be connected directly to the backbone, with devices contributing what they can and picking up what they need. The problem is then with legacy 183 data, somebody has to do conversion, or each 183 consumer needs to be separately supplied with something like the 183 Pas-thru box. Better would be something like the Maretron N2K/USB box, but with multiple 183 in/out connections in addition to the USB. Something totally solid state and thus very reliable, but with enough brains and flash memory that it can be updated as the PGNs evolve. There is a product opportunity here for someone, at least until we have pure N2K systems with no 183.

Posted by: Russ at November 22, 2007 4:18 PM | Reply

Russ & Everyone,

Furuno got back to me on the remaining questions I had (Thank you Gordon).

1. In regards to which fast heading source would the radar use (if connected to both N2K and Ethernet) … “The radar will bill able to use fast heading on the N2K connector and heading from the ethernet. The heading data source used will be selectable. If the primary source fails it will automatically switch to the other heading source” --- Good answer.

2. In regards to a capability where the radar (connected via Ethernet up the mast) offers the N2K port in support of masthead N2K instruments (avoiding the cost/weight of running N2K up the mast as well), I asked if this capability if this ethernet/N2K hub capability is vendor neutral, to which I got the response “At this time the only information that will be passed is from Furuno sensors due to Furuno proprietary format.” --- Not good !

3. I asked also “anychance the Airmar and Maretron ultrasonic weather stations are supported, as they are likely to benefit from this hubbing feature ?” … the answer was “Airmar is scheduled to provide the SW200 weather station for use with the NavNet 3D. It is unknown at this time if the Maretron will work with the NavNet 3D or not.” -- Hmm.

Posted by: Dan (b393capt) at December 12, 2007 11:23 AM | Reply

Dragging up old topics (i'm sorry)

b393capt

2. From my experience all N2K sentences i could put into the scanner (eg why would i put a n2k vhf or ais up there) all passed down correctly.

3. Maretron works fine :)


Posted by: Andy Murray at October 19, 2008 6:32 PM | Reply

No worries, Andy; there's no entry here too old to discuss. And hopefully some day Panbo will have forums to make that info sharing concept completely clear!

Now let me see if I understand you correctly. Maretron sensors plugged into a Furuno Radar and hence connected to the vessel's N2K backbone(s) via NavNet Ethernet are working OK? Is that true if the NavNet device where Ethernet goes in and N2K comes out is turned off (or crapped out)? And have you tried to calibrate or flash a Maretron device via NavNet?

Posted by: Ben at October 19, 2008 10:54 PM | Reply

Leave a comment