MyBB Internal: One or more warnings occured. Please contact your administrator for assistance.
Raymarine forum - [TG11] sample network drawings

Raymarine forum

Full Version: [TG11] sample network drawings
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Good Evening,
I am upgrading my electronics and I have seen sample drawings of networks and the connections that can be made using Raymarine products. If anyone has seen what I describe maybe you could post a link pointing me in the right direction.

Thanks for your time
Hello Chris,

There are so many different possible combinations because of the modularity of the systems, that apart from specific ones in product installation guides we don't attempt to do 'general' system drawings. For major boatbuilders and the like we do, or help dealers to do, boat-specific system drawings and there are illustrations of the Raynet and SeatalkNG systems in places like the SeatalkNG Reference Manual.

What connections do you need to know about?

If it helps spark a conversation, here is a slightly outdated network diagram for my boat, showing the Ethernet and NMEA2000 busses. I've added a couple of things, and have a couple more on the bench, but happy to answer any questions about my logic here.
Thanks, @brk.

I'd make a couple of comments for other viewing @brk's attached drawing:
  • Power supplies aren't shown, but STNG/NMEA2000 needs a *single* point of 12V power. Emphasis on single here, because some devices (including some Fusion stereos, Raymarine ACU200/300/400 autopilot actuator controllers and more) can supply power (usually switchable as on the ACU and in Fusion software.) @brk's pilot has an ACU150, but were it an ACU200 then there are potentially 3 sources of STNG power here even without the supplied STNG power cable.
  • You should use caution with any non-Raymarine (and particularly non-marine) devices in an ethernet (SeatalkHS/Raynet) network. @brk has a non-Raymarine IP video camera which may or may not work with our system, and a non-marine router. Non-marine devices will often be AC-powered (or if DC-powered, will usually not be tolerant of the wide voltage ranges of a typical marine '12V' system) which can add the potential for grounding issues or electrical noise (invertor?), are not usually tolerant of marine shock and vibration, temperature ranges or humidity (especially saline humid air) and are not tested/approved to marine electromagnetic compatibility (EMC) standards. They can also raise compatibility issues in their IP setup. As an extreme example, I took a call a few years back from the owner of a boat that had been installed with a system using a non-marine network switch, which ended up catching fire in his engine room when at sea (in the Bass Strait, of all places.)

Good points, Tom.

The NMEA2000 network has a single fused power source. I left out the layer that shows power circuits on purpose so as to not complicate the diagram too much.

The other ethernet network devices are rated for the typical voltage ranges seen on a 12V marine system, as they come from applications targeted at mobile surveillance platforms. Also, these devices are installed in the climate controlled portion of the boat that can handle their combined max anticipated heat dissipation (~300BTU/hr), these are also rated for extended temperature ranges.

The potential compatible issues in IP schemas you point out is really the most vexing issue. I am working out some options to segment the "marine" part of the network with the MFDs radar, etc, from the "consumer" side of the network (cameras, other wifi devices not shown like AppleTV units onboard, etc.) while routing data selectively between them. This mostly involves adapting to the way the Raymarine devices do not offer any configuration options for the IP subnet.
It sounds like you've given a lot of thought to the system. My motto in this sort of thing is 'if you have to ask the question then you shouldn't be doing it', but it sounds like you definitely didn't need to ask the question and can make your own informed judgements.

On the IP configuration, this is so as to ensure backwards-compatibility with legacy products, and also to prevent the support nightmare that I think would ensue if IP configuration were generally available. I agree though that it can cause problems in the sort of integration you're doing.

Reference URL's