Maxsea TZ, NAIS-300, Maretron USB100 all on N2K

[s/v Jedi]

Okay, let's do this as a list in random order:

You don't need a box to translate AIS from N2K to 0183 because your AIS already outputs that same info in 0183. Also, maybe a Furuno MFD will convert N2K AIS to NavNet?

The reason to start supporting the actisense first is probabl be ause it's much cheaper. Both Actisense and Maretron will feed every PGN so both are complete. The thing that is bothering you is the conversion to 0183, not the gateway between N2K and MaxSea.

There is no problem with your autopilot because it does not need to be driven by your computer. It will take all needed info off your N2K network and also feed PGNs for heading and rudder angle onto the N2K network. The only extra action required, is set a bearing manually. Your AP is top of the pop and will compensate for drift, ie. steer straight line over ground. It simply uses GPS sensor data from N2K for that. It can also take info from the wind sensor and steer by that.

Furuno is using Ethernet (NavNet) as their primary interface. Interfacing with MaxSea using NavNet works very good, so I would advice to give in and take that option. Change radar to Furuno 3D and there is your box that does all the conversions you need. It also gives you radar inside MaxSea. It also allows you to go wireless, using standard Wifi for the link between MaxSea and NavNet.

I have the whole range of Maretron sensors and mainly use the USB100 to upgrade firmware in the sensors and debug the network. The 0183 conversion is considered an extra to the direct N2K gateway by Maretron I think. When you use the USB100 to feed MaxSea, you are better off than 99% of the cruisers who use just a cheap USB GPS. I want all data to work and got that using the plotter/radar display.

I have had good contact with Maretron and think they would be willing to change the firmware of he USB100 to make the AP work. AIS targets isn't so hard either but I don't know if internal memory allows for much expansion. Try to get into contact with Rich Gauer. He's the president of the company and open to suggestions. I may send him the request if I find time... for me it's "just back-up" though.

cheers,
Nick.

[goboatingnow]

I've developed can bus solutions in the past.

Theres a few things to bear in mind.

NMEA gave no thought to 0183 to N2k conversion, so everyone does it slightly different. There isn't a one to one mapping between 0182 sentences and 2k PGNs either. The same problem is now being experienced with N2k to Ethernet convertors as well.

2K is mainly a broadcast network. Yes, but only mainly there's also request data pairs and their associated messages. Then there the whole issue of private PGNs. It's a fairly complex protocol in total, not to mention the farce that NMEA has made of can bus message prioritisation

NMEA are very slow with updates to the PGNs. They were particularly caught out with AIS PGNs. Hence many companies ended up with poor, incomplete or private n2k AIS implementation. Now that the standard is there this should disappear over time, but your mileage may vary.

NMEA gave very little thought to N2k to pc gateways., in fact they initially had decided that they wouldn't support them where they were direct user programmable n2k , i suspect they felt it was a way around certification. They now have the third party gateway spec, but it's woefully incomplete.

At the time in the mid 80s when 2k was being considered CAN had burst onto the scene and was the protocol de jour. NMEA took so long deliberating that in effect Ethernet overtook the networking scene. Still CAN is still cheap to design in then an Ethernet setup. Both the gap is rapidly closing.

There are so many things wrong with what NMEA did its incredible, when you compare the SAE J 1939 ( of which NMEA 2k is a derivative) with N2k you begin to see what a poor job NMEA dId IMHO. Not to mention the active termination resistor farce.

Things like multi vendor common setup methodology, alternative wiring like hub and star, lack of redundant design, lack of routing or internetworking, lack of standardised source selection, still no digital switching PGNs etc.

Then on top of this their major industry players, people that are represented on their n2k panels, have being playing fast and loose with the spec, Furuno being one of the worst miscreants, having resorted to n2k " compatible" because they wanted things not in the spec. Then add all the slightly different cabling standards and it's a pigs ear quite frankly.

What NMEA should do is throw the protocol fully into the public domain under open source agreements that would allow user pressure to force manufacturers to play ball. Right now because the average user can't understand what's gong on, it lets manufacturers obfuscate and hide between smokescreens.

The fact is as more and more N2k system get more elaborate all these problems are going to be more and more visible and incredibly frustrating for users.

Dave

[DotDun]

So, just in case anyone that has influence is listening.......let's come up with the ultimate network.

Utopia communication system for Marine use:

1) Ethernet, 802.11, & IP
2) Support power over Ethernet (15w per device, star wired)
3) Replicate N2K on IP
4) Drop all the proprietary config crap, put a web server in each device for config/firmware management
5) Standardize radar communication using N2K over IP


Add you drothers here ________________

[twistedtree]

Originally Posted by DotDun

So, just in case anyone that has influence is listening.......let's come up with the ultimate network.

Utopia communication system for Marine use:

1) Ethernet, 802.11, & IP
2) Support power over Ethernet (15w per device, star wired)
3) Replicate N2K on IP
4) Drop all the proprietary config crap, put a web server in each device for config/firmware management
5) Standardize radar communication using N2K over IP


Add you drothers here ________________

To me, the goal with #3 is a standard encapsulation of N2K within IP. No translation required or desired.

I think much of the current issue being discussed is a result of trying to translate N2K into 0183 which to me is very much moving in the wrong direction. Native N2K support is what's needed so we can dump 0183 once and for all. The problem being faced is how to present those PNGs to an application in a standard way. 0183 is ASCII text to flowing it in over a serial port is easy and what everyone does. Could N2K PNGs be done the same way? I assume they are binary, not ASCII? If there is self-describing delimiting between PNGs, it should be workable over a serial line, right?

I think your config proposal, though desirable, may be more problematic. Supporting a mini web server in a low-cost, low-power, very simple N2K device may be impractical. Also, is there a standard way to send and receive TCP packets over N2K. Crap, now we are encapsulating the other way around - probably a bad idea. I think this one is much harder.

Yes, standard radar data would be great, including standards for transport over N2K and Ethernet.

[DotDun]

Originally Posted by twistedtree

I think your config proposal, though desirable, may be more problematic. Supporting a mini web server in a low-cost, low-power, very simple N2K device may be impractical.

Gotta disagree here. Linux kernel with full TCP/IP stack and web server are common place in some very inexpensive equipment. Look at the Apple TV or Roku, they are both $99 boxes and have 10 times the functionality and horsepower that any N2K transducer needs. How about all the Linksys, DLink, etc. boxes? All way more power than needed for marine transducers.

[twistedtree]

Originally Posted by DotDun

Gotta disagree here. Linux kernel with full TCP/IP stack and web server are common place in some very inexpensive equipment. Look at the Apple TV or Roku, they are both $99 boxes and have 10 times the functionality and horsepower that any N2K transducer needs. How about all the Linksys, DLink, etc. boxes? All way more power than needed for marine transducers.

But that's my point. Or maybe we are miscommunicating? Devices like you describe are much more powerful and have a lot more memory than I would expect in an N2K transducer. I could see increasing the computes and memory to support a web server easily doubling the manufacturing cost of such a transducer. I suspect many N2K devices are nothing more than a small PIC, and I doubt they could run enough SW to be a web server. For an N2K device like Maretron's DSM250 display it's probably not a big deal to add a web configuration server, but for a tank level sensor, pressure sensor, trim tab indicator (I'm trying to think what I have on board), GPS, Weather sensor? And the N2K stuff is miniscule volume compared to Linksys, Netgear, Apple, etc., so they have that cost disadvantage too.

I haven't build such a thing in a while, but would hosting a web site really be practical in a transducer?

[DotDun]

Originally Posted by twistedtree

But that's my point. Or maybe we are miscommunicating? Devices like you describe are much more powerful and have a lot more memory than I would expect in an N2K transducer. I could see increasing the computes and memory to support a web server easily doubling the manufacturing cost of such a transducer. I suspect many N2K devices are nothing more than a small PIC, and I doubt they could run enough SW to be a web server. For an N2K device like Maretron's DSM250 display it's probably not a big deal to add a web configuration server, but for a tank level sensor, pressure sensor, trim tab indicator (I'm trying to think what I have on board), GPS, Weather sensor? And the N2K stuff is miniscule volume compared to Linksys, Netgear, Apple, etc., so they have that cost disadvantage too.

I haven't build such a thing in a while, but would hosting a web site really be practical in a transducer?

My head is wrapped around what these units retail for. Although, I do agree on your point about niche market product vs. mass market.

Example: the Furuno GP330B lists @ $450, street price north of $300. It's a OEM of Airmar's G2183 which has a street price of sub $200. Fifty percent more for the same hardware from Furuno? There is room there to add features.

If no web server for config/firmware management, then provide the software to communicate with the unit for free (ex. Airmar & Weathercaster, etc.). My goal is to get away from having to purchase yet another box just to maintain a transducer.

[s/v Jedi]

They put webservers in $25.- wifi routers; this is no added cost.

I think it's a good idea, although I also like how Maretron does the configuration and firmware upgrades.

I would not want n2k over ethernet. Why put one encapsulation in another one without any benefit? I notice tha Furuno Navnet is baically 0183 over Ethernet.

cheers,
Nick.

[DotDun]

Originally Posted by s/v Jedi

I think it's a good idea, although I also like how Maretron does the configuration and firmware upgrades.

A guess - they use manufacturer proprietary PGNs.

Originally Posted by s/v Jedi

I would not want n2k over ethernet. Why put one encapsulation in another one without any benefit? I notice tha Furuno Navnet is baically 0183 over Ethernet.

OK, more specifically. Lose the CANbus media access arbitration layer, use IP and choose a port number then encapsulate a N2K source/destination with a raw PGN, one per packet. Keep to a single network, keep the 50 device limit (at layer 4). This should allow for backward compatiblity.

There is good reason to lose 0183. They overloaded the sentences due to bandwidth limitation plus the fact a 0183 network has only a single talker. They unbundled a lot of data in N2K, in order to take advantage of the multiple sources feature.

[s/v Jedi]

Originally Posted by DotDun

A guess - they use manufacturer proprietary PGNs.

Yes... But would you enforce strict templated web page standard then? It'll be proprietary anyhow...

As much as I like Ethernet (bought me my ticket to cruising), I still like n2k for simple sensors. It reduces cabling significantly while still allowing to power the devices, waterproofing much better than Ethernet standards (= afterthought there)

cheers,
Nick.

[akio.kanemoto]

Originally Posted by s/v Jedi

Okay, let's do this as a list in random order:

You don't need a box to translate AIS from N2K to 0183 because your AIS already outputs that same info in 0183. Also, maybe a Furuno MFD will convert N2K AIS to NavNet?

OK, issue here is that the AIS unit is on the other side of the boat from where the PC is. I have an N2K bus snaking around the boat with sensors scattered around the place - so the fact that the AIS PGNs don't come out of the USB100 was unplanned to say the very least.

Is there ANY way to pull the PGNs out of the N2K network near the PC with something like Actisense, but dump to 0183 so I can use Maxsea TZ with two serial ports?

The reason to start supporting the actisense first is probabl be ause it's much cheaper. Both Actisense and Maretron will feed every PGN so both are complete. The thing that is bothering you is the conversion to 0183, not the gateway between N2K and MaxSea.

I don't quite understand your statement - what do you mean "both Actisense and Maretron will feed every PGN"? (There's no way to access the data except for N2kanalyzer... so I'm not sure it qualifies as "feeding".. since it's not usable by anything right?)

There is no problem with your autopilot because it does not need to be driven by your computer. It will take all needed info off your N2K network and also feed PGNs for heading and rudder angle onto the N2K network. The only extra action required, is set a bearing manually. Your AP is top of the pop and will compensate for drift, ie. steer straight line over ground. It simply uses GPS sensor data from N2K for that. It can also take info from the wind sensor and steer by that.

Setting a bearing manually is a kludge though... So assuming that I buy the Actisense and assuming it works with Maxsea TZ, do you know whether this problem goes away, or are we still going to suffer the same magnetic deviation problem etc? (how do you control your AP btw?)

Furuno is using Ethernet (NavNet) as their primary interface. Interfacing with MaxSea using NavNet works very good, so I would advice to give in and take that option. Change radar to Furuno 3D and there is your box that does all the conversions you need. It also gives you radar inside MaxSea. It also allows you to go wireless, using standard Wifi for the link between MaxSea and NavNet.

OK, so assuming one buys a Furuno MFD, then doesn't that become the primary chartplotter? The PC is then just a backup and doesn't even enter the equation? In fact, it's not even a backup - since the MFD is doing the conversions and if the MFD dies, so does Maxsea on the PC... or am I missing something?

So if I go buy an MFD in this case, USB100 is relegated to troubleshooting duty, Maxsea never gets used... BUT does this solve my AP and AIS problem?

(can you tell I'm desperate to make my problems go away?

I have the whole range of Maretron sensors and mainly use the USB100 to upgrade firmware in the sensors and debug the network. The 0183 conversion is considered an extra to the direct N2K gateway by Maretron I think. When you use the USB100 to feed MaxSea, you are better off than 99% of the cruisers who use just a cheap USB GPS. I want all data to work and got that using the plotter/radar display.

Likewise, I want all my data too. (But your AP still doesn't work right?)

I have had good contact with Maretron and think they would be willing to change the firmware of he USB100 to make the AP work. AIS targets isn't so hard either but I don't know if internal memory allows for much expansion. Try to get into contact with Rich Gauer. He's the president of the company and open to suggestions. I may send him the request if I find time... for me it's "just back-up" though.

If you're on a friendly basis with the CEO, then I would greatly appreciate some requests re AIS and AP - and if your MFD is down it may not be just backup after all.

(Having said that, I can imagine this request taking another year for them to code... so I am ready to cave in and buy an MFD if it resolves my issues... hey, it's just like IT! just throw money at the problem and hope it will go away!)

[twistedtree]

I think Maretron now has an N2K to Ethernet gateway - similar (somewhat) to the N2K/USB device, but ethernet instead of USB.

You might want to ask Maretron if that device will work with Maxsea, or if it has the same limitations as the USB100.

[s/v Jedi]

Akio,

Okay, I'll go a bit slower: what you are doing right now with the USB100 is using it to convert between n2k and 0183. That is not the primary function of it. When MaxSea would support it, it can pass every PGN between n2k and MaxSea without converting anything. This is what will happen when support for he Actisense becomes available too. These devices are acting as gateways instead of converters in that case. They will pass any PGN, even vendor proprietary ones.

Your planning with the AIS far from computer. But that means you planned on hopes and assumptions instead of specs of he equipment. Sorry it sounds harsh

I'm beginning to think you have no radar? A Furuno MFD can be used as secondary display, while it powers the radar sensor (which is 48V DC) and feeds the Navnet network. It will do that even in standby mode. Your AP will work 100% in that case, also from MaxSea. Assuming that you have Maxsea Explorer which can talk to Navnet, not the cheaper plain MSTZ version.

It Is not bothersome to set the AP without the computer. Just press one key labelled Auto. If the course is different from the wanted one, turn the knob to adjust. From there on the AP works independent, with or without computer, because it pulls the other data it needs direct from sensors.
With computer attached, you set the Goto on the computer, then press Nav on the AP, then confirm the Goto with another press. You're pressing knobs on the AP either way.

In my setup, when the MFD fails, MaxSea looses it's instrument feed. I will then connect he USB100 and continue. When the USB100 also fails, I put a $50.- USB GPS in the computer and continue. All I really loose with he MFD out is the radar.

Mark also has the Actisense n2k to 0183 converter. It might do what you need, but I don't know the device well enough to tell. Look up the specs and find out!

I only exchanged some emails with Rich @ Maretron. I'll put this USB100 thing on my list of things to look at when I'm finished with the ones higher up he list.

In your shoes, I would start with pulling a 0183 cable from AIS to computer and possible location of MFD. Prepare for multiple setups because AIS over n2k is still a bit tricky. I would also always have some Keyspan USB to serial converters around.

cheers,
Nick.

[DotDun]

Originally Posted by s/v Jedi

Yes... But would you enforce strict templated web page standard then? It'll be proprietary anyhow...

Pretty simple page. Option A [on/off] Option B [yes/no] Firmware update [choose file] AND, no additional $400 device required!

Originally Posted by s/v Jedi

As much as I like Ethernet (bought me my ticket to cruising), I still like n2k for simple sensors. It reduces cabling significantly while still allowing to power the devices, waterproofing much better than Ethernet standards (= afterthought there)

There is no doubt that a purpose built anything is better suited to the task at hand when compared to a more general purpose solution.

Following your line of reasoning, the PSTN would never go away, RF delivering television signals would last forever, and Keyspan would be selling USB/serial adapters for another 50 years!

The fact remains that Ethernet chipsets, Cat5 cabling, POE, IP stacks, and small purpose built web server can be assembled together for cheaper than the N2K interface on a depth transducer or GPS. Why does a N2K depth transducer from Airmar cost ~$150 more than the equivalent analog model? The N2K interface is ~$150??

In an economic society, the market always wins.

I certainly don't consider the 802.3 standards as inferior because they don't include weatherproof connectors. I commend them for recognizing that's not their area of expertise and letting others define that part! On your boat, both Furuno and Ubiquity did it! BTW, did I mention the spec includes up to 15 watts of power? Oh yeah, how is your Bullet powered?

[s/v Jedi]

Originally Posted by DotDun

Pretty simple page. Option A [on/off] Option B [yes/no] Firmware update [choose file] AND, no additional $400 device required!

Ah yes, but price is a new argument you only now bring forward I agree that anybody without a stake in the technology firms involved would prefer Ethernet based with web interface for the configuration and firmware update part. But that is just part of the complete picture.

There is no doubt that a purpose built anything is better suited to the task at hand when compared to a more general purpose solution.

Exactly. And the only counter argument is the costs involved. The thing is that sometimes cost outweighs other factors and sometimes it does not.

Following your line of reasoning, the PSTN would never go away, RF delivering television signals would last forever, and Keyspan would be selling USB/serial adapters for another 50 years!

No, following my line of reasoning, better suited technologies get developed even when old ones are usable. I don't see any link with PSTN etc.

The fact remains that Ethernet chipsets, Cat5 cabling, POE, IP stacks, and small purpose built web server can be assembled together for cheaper than the N2K interface on a depth transducer or GPS. Why does a N2K depth transducer from Airmar cost ~$150 more than the equivalent analog model? The N2K interface is ~$150??

I don't agree to accept that as you write it. The only reason that the Ethernet solution is cheaper today is because it is produced much more and off the shelf modules are available for what you describe. There is nothing particularly expensive about electronics used for n2k. Yes, the connectors are much more expensive but I am sure every boater is happy to pay that price for the weather sealing they provide.

And of course the manufacturers let us pay more for the n2k versions of sensors. They will do the same with Ethernet based ones, even if the cost to produce it would be lower. They will only let you keep those $$$ in your pocket when the market forces them to do that. Airmar pretty much has a monopoly on the transducers anyway. As long as they don't become too greedy, nobody is gonna challenge them any time soon I think.

I certainly don't consider the 802.3 standards as inferior because they don't include weatherproof connectors. I commend them for recognizing that's not their area of expertise and letting others define that part! On your boat, both Furuno and Ubiquity did it! BTW, did I mention the spec includes up to 15 watts of power? Oh yeah, how is your Bullet powered?

Yes well, the weatherproofing of Ubiquity is as good as possible for their price but yes I understand what you mean and I like Ethernet too. Let's compare the two like this:

1. n2k sensors.

Wind/weather sensor at masthead. An in-line terminator lives here and the n2k backbone cable runs down the mast, exits it and connects to a T-connector. From that T a drop-cable runs forward to a depth/speed/temp tri-ducer. Also from the T, the backbone continues aft, snaking along compass, GPS, computers, displays, APs etc. with in the middle a power injector. At the very end another terminator.

2. ethernet sensors.

Let's assume they decide to use small enough solid weatherproofed connectors. Now we have to find a central location where we mount an industrial Ethernet switch that is DC powered and has POE ports. These units are 48V. Okay, let's assume they create 12V versions. Now we have the switch and can start pulling cables from that switch to each and every individual sensor. That looks awfully much like 0183 cabling to a 0183 MUX, doesn't it. I hate that and the total amount of cabling is horrific. But we have the sales in place and connect the sensors which are same price as the n2k versions because the amount of sensors sold determines price more than cost differences to build them.
Now we can use a web browser to update and configure the sensor which works great and we use a computer that we have anyway, saving $400.- Now we start using the sensors. They put what, 100 bits per second on a dedicated cable rated for at least 100,000,000 bits per second. Clearly, the available bandwidth of Ethernet is wasted on these simple sensors, or at least not an advantage.

Next we get to compatibility. We connect the computer to the Ethernet and then what? Best you hope for is a standard packet format among manufacturers, like we have with NMEA and software vendors who slowly start accepting and supporting that. I do not see any improvement regarding compatibility, although the physical interface from a computer is easier. But cost savings is just the same $400.- mentioned earlier.

I'm fine with n2k as it is and almost agree with the mix and match between n2k and Ethernet as done by Furuno. I would only put 1 connector on the displays and output n2k from the AIS box. It would be nice when they standardize Ethernet protocols among themselves so that a Garmin radar sensor works on Furuno display etc. How realistic is that to happen? It would require an organized consumer commitment to it and support from at least one manufacturer.

cheers,
Nick.