NMEA 2000 Bridges #1, they’re coming
So what the dickens is a NMEA 2000 bridge and why would you want one? Well, I think the answers are complicated enough, and important enough, that they deserve two entries. Mystic Valley Communications, the small company that produced the prototype above, describes its bridge as an “intelligent connection between two electrically isolated NMEA 2000 networks that copies transmitted data between the two networks.” Obviously, then, this is another way to deal with the backbone power issues discussed here in the past; with a bridge you can have two N2K networks that act as one in terms of data but are independent in terms of supplying power to devices, and in terms of a power failure. But the Mystic Valley brochure (unfortunately not online yet) goes on to claim that the bridge can also be used to increase the number of devices and drop lengths beyond what’s allowed for a single backbone. How is that possible?…
The critical concept, I think, is that this bridge doesn’t just pass data from one network to another, but “copies” it. In other words, the PGNs are read by a microprocessor and then re-broadcast fresh on the other network. They’re reborn! Which may not mean much until you start to grasp why an N2K network has a limited number of nodes, limited backbone length, and a limited total drop length, which has nothing to do with the limited capacity of the power wires carrying 12v to the nodes, and little to do with even the bandwidth of the data wires.
Somewhere I have a recording of Maretron CEO Rich Gauer waxing eloquent about how N2K is an impedance-based network protocol, how well the data waves travel through the backbone as long as the cable and connector characteristics are correct and the terminating resistors are there to prevent back splatter (my phrase), how the drop lengths need to be limited to minimize data wave reflections, and how the usually robust process can get screwed up by impedance-related subtleties. I really should write an entry around Rich’s rap, because he can really give the technology life and help folks understand why care must be taken (especially with the large networks Maretron sometimes works with). But for now suffice it to say that another feature of a bridge is that it lets you have one large data network split into two (or more) independent impedance environments.
At any rate, this stuff can get real when you create an extra large N2K backbone and/or get involved with some of the more finicky devices. And it’s our good fortune that a regular Panbo reader, Jeremy Anwyl, has not only gone down both those paths but has already had some success using an industrial bridge as a cure. We’ll hear from Jeremy next week in a guest entry that might be subtitled “One brave man’s experiment with a CANbus bridge, and the issues that drove him to it!”
I shouldn’t close without also noting that an optional feature of Mystic Valley’s bridge is the ability to filter PGNs passing between networks. This has tremendous potential for certain situations, I think. For instance, in Fort Lauderdale I learned that the proprietary-seeming CANbus control network that Side Power uses to integrate its various thrusters (and now stabilizers) is actually NMEA 2000 compatible because the engineers anticipated the day when bridges like this would make it possible for critical gear like theirs to integrate with larger multi-manufacturer networks in a super safe fashion.
Mystic Valley Communications, incidentally, is headed by David Morschhauser, who does a lot of technical writing and training for NMEA, as well as N2K consulting. Neither the bridge nor the optional BridgeBuilder software are priced yet, but they are scheduled for release early in 2011. And MVC may not be first. BEP is already showing the one below on its web site, though that’s all I know about it so far. NMEA Bridges are coming, and next week we’ll learn more about why.
Ben, if I read this correctly this sounds like it could be the answer for seperating my Maretron NMEA2000 Yanmar engine monitoring displays and systems from my Garmin navigation and main NMEA2000 network and then combining them if needed without re-routing when I want either configuration. I posted this question somewhere else on your site.
Thanks,
Bill Lentz
It sounds like n2k is repeating the history of Ethernet
What’s next? N2k routers and n2kBaseT? 😉
Douglas, if you Google “CAN bus bridge” you’ll find all sorts of gear; same with “gateway” and “converter.” Which is one reason NMEA developed 2000 on top of CAN bus; it’s relatively easy to add utility hardware as needed. I think there’s an argument, though, that CANbus already routes the type of data it’s meant to handle better than Ethernet does.
I am pretty sure there is a N2K to Ethernet device that will be available early next year. One way to get data directly to an iPad.
Interesting. In the Ethernet world, the following terms are used:
Hub – a device that takes multiple network segments and makes them act as one. All messages on all segments appear on all other segments. Passive hubs simply connect the segments electrically. Active hubs read a packet and retransmit it on all segments at full strength. No packet data is changed. It is possible for network segments to operate at different speeds, even though all are connected to a hub. In that case, the hub must have enough memory to store inbound packets from fast segments while dribbling them out to slow ones.
Switch – like a hub, but inbound packets are not retransmitted onto segments where their destination doesn’t lie. This is like a hub, but it reduces packet collisions since most packets will only be retransmitted onto a single segment, not onto all segments. No packet data is changed.
Router – like a switch, but much higher level address processing is used to determine which destination a packet is routed to, and the packet headers can be changed. This allows different addressing schemes to be used at each port of a router, for example.
Firewall – A router with security functionality that is used to filter packets according to security criteria.
Dan
Thanks, Dan, but I probably shouldn’t have made that remark about N2K routing, because I’d rather not see this thread become a CANbus vs Ethernet fight (as others have). All I meant was that CANbus/N2K has pretty solid addressing, prioritization, and guaranteed data delivery built in.
Ben – I’m with you. I have no bone to pick with Ethernet/CANbus/N2K, but it woudl be good if the existing terminology were reused, to avoid confusion.
Regardless, I look forward to there being more interoperability, both at the software (protocol) end of things and at the hardware end.
Ben et al, We have to be very careful here and theres a danger of smoke and mirrors.
Firstly canbus/nmea 2K is not a routable protocol unlike TCP/IP which was specifically designed so. This is becuase the basic hardware doesnt really even have device addressing. J1939 added this as a kind of kludge,
The primary definition of Bridging is that in interconnects networks and determines remotes address by flooding the network with address requests, and then stores the hardware address of the destination device. Since Nmea2K doesnt have a non-repeatable address like a MAC address, bridging isnt technically possible.
Routers are defined by their routing tables, ie the pick a destination network according to routing rules ( tables) , again nmea2K acnt do this.
switches are seperate collision domains, really not applicatble to NMEA2K or canbus, but the defintion can be extended to incorporate them, switches would add nothing to a canbus network
Hubs are essentially a method of cabling/electrically seperation and were the way a bus based system like ethernet went to isolated star based systems. Hubs have a place in a Canbus network as they act to create electrically isolated protocol homogenous network.
What we are left with is , a kind of cross between a Hub and a store and forward bridge. There are major issues, firstly how can a bridge handle REQUEST commands since these are device addressed. In fact any PGN that relies in device addressing is in for a problem. Equally its hard to see how fast packet prorocol will work accross a bridge as this relies on addressing.
what will work is standard 8 byte PGNs, both private and public and these could be filtered by the bridge, However dont expect a canbus bridge to connect two devices that rely on the extended protocol.
sure a canbus “brdige” can provide useful features, namel hub style features to isolate the network into electrically seperate networks.
since Canbus doesnt have a higher level transport protocol, its hard to see how bridges will handle network collisions. ie the bridge accepts the PGN and the sender is happy, yet the bridge fails to get the PGN to the destination, since the bridge has no way to subsequently request a retransmission, it leads to problems, as to how BUS-OFF issues are handled hmmmm.
Electrically isolation is a good idea, there is a need for simple Canbus hubs to allow one network but electrically sperate spurs, but bridging , i remain to be convinced.
Dave
Please, Dave, I already said I’m sorry for mentioning routing that way. I really am! Let’s please not apply Ethernet definitions of bridging where they don’t apply. I think that the definition of a network bridge is pretty wide. Let’s focus on what a CANbus/N2K bridge can do.
Incidentally, the Mystic Valley Bridge was demoed at METS, maybe even as part of the large connectfest that took place there. And David Morschhauser told me that he’s submitted its NMEA 2000 certification package and “expects no problems with that.” I see no reason to believe that his bridge, or BEP’s, will limit device communications between the two networks.
OK, Ben I understand that we shouldnt get bogged down in Ethernet defintions. I like to know what a canbus nmea2K “bridge” can do. can it extend the number of devices past the theorectical 253, ccan it handle all the protrocols, including Fast packet and Request protocols. How does it handle peer to peer messaging
This is the key otherwise theres a danger that canbus bridges are less then effective and are just a store and forward broadcaster. Note that certification doesnt resolve this. SAE has J1939/31 networking extensions , NMEA does not to my knowledge have a similar protcol
BTW the BEP unit looks like a hub.
Darn, Im getting close to another NMEA 2k rant
Dave
Dave’s comments are interesting. I can report that when testing a CAN bus bridge on my NMEA 2000 network(s) that the device is invisible. By that I mean it does not appear as a network device on Maretron’s N2K Analyzer software.
I can also report that with an Airmar PB200 on network 1 and Airmar’s weathercaster running on a PC connected to network 2 (via an Actisense N2K to USB adatper) that the weathercaster software performed normally.
Jeremy, have you tried installing software updates between a PC or MFD on network 1 and a sensor on Network 2 ?
E.g.
Airmar Weathercaster PB200
Maretron ?? Maretron xxx-100
XYZ brand MDF XYZ brand sensor
Dan,
I haven’t tried a software update but can give it a shot.
I did change the configuration of the PB200 across the bridge with no problem. As I said, to devices on both networks, it is like the bridge does not exist.
I will test the firmware idea and report back.
Dan:
Through your question, I have learned several things. I have a Maretron ALM100 that I have not connected as it caused my bus to crash with errors. (Probably not the fault of the ALM100, but something it conflicts with on the network.) This was back before I started experimenting with a bridge…
The ALM100 has firmware 1.0.5 and version 1.0.6 is available. I installed the ALM100 on bus 1 and the USB100/PC on bus 2. The firmware updated normally. More importantly, the ALM100 is also working nicely on bus 1.
Even more interestingly, I tried installing the ALM100 on bus 2. It works on bus 2 as well.
Clearly, the bridge is doing something worthwhile.
It seems to me that the ability to filter PGN’s is probably the most valuable function of a bridge. This would allow you to filter out offending PGN’s when one piece of equipment is causing issues on the network. Usually these cases are temporary as the manufacturers try to fix firmware quickly but some manufacturers seem to care less than others when their gear causes problems with others.
Outstanding. Do I recall correctly that updating software across N2K is non-standard, e.g. each manufacturer works out their own method and non-standard PGN’s?
I am no expert, but I believe you are correct. At least that is what seems to be happening.
I can see a role for three levels of bridges/routers:
Like NAT, it would be hard to do firmware updates from a PC of a device located on the other bus. On the upside, you can grow beyond a 253 node system. The router would also be able to provide services such as deciding which GPS provides the best signal, and retransmit the signal from only that device.
I’ve implemented my own version of #3 by the way, using my onboard Linux router-style device and 2 Actisense NGT-1s. This allows me to keep a small N2K network on 24/7/365 and only power up the big network when actually moving the boat. It also resolved some power issues I had. I’ve also got a 3rd NGT-1 connected to a PC, but I can dump this as soon as my N2K to Ethernet conversion is done and I get some software that can speak N2K over Ethernet. Alternatively, I’ll have to translate the data to/from NMEA-0183.
Kees:
I tried something similar. I was trying to get NMEA 2000 data to some older ST60 Maxview displays. I used the Actisense NMEA2000 to NMEA 0183 and Raymarine’s 0183 to Seatalk converter. (It had occurred to me I could also make a bridge type device going from NMEA 2000 to 0183 and back to 2000.
The issue I ran into was incomplete translations. Several PGNs I needed did not get converted.
The CAN bus bridge I am testing has no such issues.
Incidentally, I recently tried Raymarine’s Seatalk to Seatalk Ng converter. The data translated well, but something the device did caused several other NMEA 2000 device to drop off the network. I ended up sending it back.
Jeremy,
I installed the same 2k>0183 then 0183>ST convertors the end of the season. I haven’t had time to troubleshoot it all yet. DO you remember what PGN’s were not converting?
Thanks
Rob
If I remember correctly, it was speed over ground. Actisense is adding to translated PGNs, so perhaps this working now.
The Seatalk to NG converter did a great job of translating–it just caused by Floscan device to drop off the network.
Jeremy has quite a loaded up network(s), as will be revealed in part 2 😉
Hi Kees I can’t see how a bridge can work in canbus without a higher level networking protocol. For example how can you have NAT when the possibility of duplicate device address can exist ( given the 253 address space). Hence this disrupts bridge operation. Even if you allows address claims to work across the bridge that’s them removed one of the main advantages ie expansion of the address space .
As to network to network filtering even in a homogenus address space how can you deal with peer to peer packets since (a ) don’t know the PGNs (b) the peer to peer address change on different power up sequences. Hence you can say something like ” bridge do not pass device address 128 since there’s nongusrantee that the desired address will be there next power up.
I accept you can do simple ” public” PGN filtering ok. But that’s only half the battle. This is why I said ” smoke And mirrors”. I suspect the devices advertised work properly because in reality they don’t act as bridges at all , merely isolating hubs with some limited filtering.
Dave
Dave,
Fully agree that’s what these “transparent” devices do, I think they are #1 in my classification. They -could- theoretically be #2 but that would only make them more expensive and it would result in the bridge appearing as a separate device on both networks unless it has a different interface used to program it.
With regard to my suggestion of NAT — that’s what I’ve got right now with my system that has 2 NGT-1s. Here’s how that works:
[network#1]–>NGT#1–>Computer–>NGT#2–>[network#2]
When you have the computer repeat all data that it receives on network #1 onto network #2 the PGNs that started off with particular source addresses on network #1 will be broadcast with the address of the NGT#2 on network two. In other words, on network #2 you see all PGNs broadcasted on network #1 but with a different source address.
This will only work for non-addressed messages, those without a destination address. Since the devices on network #2 are not known on network #1 they won’t “see” those on their network #1 and thus won’t be able to address individual devices on network #2. Thus, no addressed messages. This basically rules out doing cross-NAT activities such as firmware updates and setting changes.
The same holds when you reverse network #1 and #2, so it is a “source-and-destination” NAT.
I’m not saying that these #3 devices make much sense in the average boaters network, just saying they are possible and may be useful in some instances.
David Morschhauser wrote this morning (just before stepping on a plane to South Korea) to say that NMEA has certified his bridge, and that the answers to Dave’s questions — Is ‘bridge’ the right term? Can it handle Fast Packets or Request type messages? — are “yes, yes, and yes.”
Incidentally, this weekend I tried to find out more about fast packets and so forth myself, and was helped to some degree by this NMEA white paper (PDF):
http://www.nmea.org/Assets/20090423%20rtcm%20white%20paper%20nmea%202000.pdf
which was co-authored by David Morschhauser 😉
The only way Ben that fast packets and request etc as well as other peer to peer addressing is that the ” bridge” passes address claims backwards and forwards and hence there is never duplicate device address on a bridge canbus network do irrespective of bridges there can only be 253 address max.
Then the bridge must hold address lists of what device is on what network and relay peer to peer messages across the bridge.
I remain to be convinced that adding bridges will not stop certain devices from operating properly and will add instability. Again unless the user can ascertain what PGNs are in use ( both private and public ) and we see some low cost hand held packet loggers/analysers, the user is going to be presented with mysterious network/ device faults
Face
Stupid iPhone replaced Dave with face
Isn’t it amazing how the whole Ethernet thing just won’t go away? N2K needs every conceivable excuse, rationalization and band aid. But Ethernet just works.
Please, Russ; let’s keep this thread about N2K bridging. If you or anyone wants to beat on the old N2K vs Ethernet horse some more, there’s the Forum or threads like this:
https://panbo.com/archives/2009/11/ais_over_nmea_2000_concept_defended.html
Dave, It’s not me that’s saying the bridge handles Fast Packets, etc. fine. It’s the designer, and apparently the NMEA testing software.
Ben I wasn’t commenting on you or the designer, what I was pointing out that inherently without a higher level networking protocol it’s really impossible to build a canbus bridge ( in the true sense of the world)
What is described as a bridge is really a smart hub .
It allows for protocol separation between networks, overcomes the 30 devices power limit and offers possible PGN filtering
However, it can’t ( unless the designer is going to give us a detailed explanation)
1. Expand the device address space
2. Allow for routing
3. Deal with the issues of filtering private PGNs and peer to peer filtering
KcmYes they have s place and are useful, whether it’s a real bridge is another question
GBN,
I hate it when these things end up in a flame war, but I can’t help myself here.
You say a CANBus bridge cannot:
1. Expand the device address space
2. Allow for routing
3. Deal with the issues of filtering private PGNs and peer to peer filtering
However, those are exactly the things that an Ethernet bridge -also- cannot do. If an Ethernet device does those things it’s called a router, not a bridge. A bridge is just a 2 port switch…
Note that I do not disagree with you on the fact that these CAN bridges cannot perform the functions you mention!
well Kees, the definitions are somewhat blurred now, most TCP/IP bridges and routers are in fact Brouters.
The main definiiton of a bridge to my mind is that interconnects two similar but unknown networks.
Fundementally the problem stems from the lack of a global unique MAC like address system in Canbus, NAME fields are a hodge podge add on to try and solve the problem.
In fact Kees the device isnt even a 2port swicth, switches seperate the collison domains, and in a canbus system the “bridge” cant even do that.
so in reality its a filtering 2-port hub ( bHub!!)
Dave
Actually Kees, I dont even know if the device mentioned in Bens article can even do filtering. I suspect its just a hub like the BEP one. I of course stand to be corrected.
If It can do filtering , I like to see the setup PC software.
Dave
I agree, those devices probably don’t do any filtering.
Please, look up the definition of Ethernet bridges. I respectfully disagree with your “main definition to your mind” of a bridge.
You also stat that switches seperate the collison domains, and in a canbus system the “bridge” cant even do that. Again, I disagree. There is no reason a CAN bridge cannot learn which device addresses are on which bus and then keep addressed messages restricted to one network. That would separate the collision domains, and thus form a true “switch”. Like an unmanaged switch there would not need to be any setup procedure for such functionality.
Yes, Dave, as clearly stated in the entry, the Mystic Valley Bridge will do PGN filtering using BridgeBuilder software, which is not yet released.
Now you’ve got to stop confusing readers, and I’m serious. If you want to understand why I just temporarily suspended your ability to post whatever you want without review, read through this thread as if you were a less technical person trying to understand what these NMEA 2000 bridges are actually about. Sorry, but I don’t think you’ve helped at all.
Hi Bill,
I have exactly the product you need! It has been tried and tested in several installations with Yanmar engines and Garmin plotters. Have a look at the instruction book here: http://www.tinleyelectronics.com/documents/CAN2000EngineGatewayV1-01.pdf