PaulRainbow
Well-Known Member
Post a link to a diagram showing this then, please.
NMEA 2000, two pieces of equipment off one drop link?
- Thread starter Ceirwan
- Start date
Post a link to a diagram showing this then, please.
prv
Well-Known Member
Any N2K diagram whatsoever - on re-reading I'm sure you'll agree that Knuterikt's assertion is complete nonsense and it's nothing to do with wiring topology.
Pete
Last edited:
PaulRainbow
Well-Known Member
I don't think so Pete. I think he means you can have more than one display "daisy chained" from a drop cable. IE drop cable goes to a display, then another cable links the two displays. I don't think this is fully N2K compliant though and most modern displays only have a single N2K port. My Garmin GMI 10s are connected to the backbone by drop cables, no daisy chains.
I can see no way of connecting multiple sensors to the backbone via a single drop cable, can you ?
prv
Well-Known Member
PaulRainbow
Well-Known Member
You cannot (IMO) daisy chain multiple sensors on a single drop cable, which is what the OP wants to do. Various people keep saying you can daisy chain multiple devices and keep referring to Simnet and Raymarine, neither of whom have shown daisy chained sensors. They have, in the past, shown more then one display on a single cable, where the second display is linked to the first.
I think knuterikt is saying that the only reason this worked is because the displays are only receiving data.
What i am saying is that it is not possible to connect more than one sensor to a single N2K drop cable.
I await a wiring diagram to demonstrate that this can be done and i am wrong
Keith-i
Well-Known Member
I can't see any reason why electrically it would not work for a small network well within design limits. Somewhere in the panbo.com archives a very contorted and non compliant network was tried and worked successfully.
Hoolie
Well-Known Member
There is no difference in N2K network wiring between backbone and drop cable. It's just wires and they're all interconnected the same way. So functionally you can connect into the network anywhere. Of course in practice there are differences and backbone cable is supposed to be heavier guage (though some suppliers are suspected of not doing this). Terminators are needed somewhere - usually at the extremities, though I think this is to ensure adequate pull-up on the individual equipment line drivers.
I guess one reason you don't see multiple sensors on a single drop cable is they tend to be be distributed all round the boat and you might as well use backbone to interconnect them. On the other hand displays tend to be grouped so daisy chaining several from one drop cable seems attractive. I think NMEA has deprecated this practice and manufacturers have now discontinued fitting more than one network connector. In practice it makes no difference as three displays can be connected just as easily to a 5-way connector as a t-piece using exactly the same interconnecting cables.
I guess one reason you don't see multiple sensors on a single drop cable is they tend to be be distributed all round the boat and you might as well use backbone to interconnect them. On the other hand displays tend to be grouped so daisy chaining several from one drop cable seems attractive. I think NMEA has deprecated this practice and manufacturers have now discontinued fitting more than one network connector. In practice it makes no difference as three displays can be connected just as easily to a 5-way connector as a t-piece using exactly the same interconnecting cables.
Martin_J
Well-Known Member
It looks like the displays are only receiving, but they are transmitting on the bus as well. How do you think they can for example control the light levels on other displays if they can't transmit.
P113 of the Raymarine i70 shows at least 20 PGNS that they are able to transmit...
Martin_J
Well-Known Member
RichardS
N/A
I also thought that Knuterikt was drawing an analogy with NMEA0183 rather that stating a fact about N2K but I might be wrong. I don't know whether the bit about the i70 not transmitting any data is correct or not.
Richard
knuterikt
Well-Known Member
It's true that the i70 transmit some data, but the volume of data is small compared to a sensor that is outputting data all the time.
I think is't bad advice to suggest that OP experiment with a setup that is not supported.
NMEA 2000 relies on a protocol for network sharing that is sensitive to timing errors. I suspect that that multiple busy talkers on the drop cable can create more problems, than having non chatty displays sharing a drop cable.
From https://www.nmea.org/Assets/20090423 rtcm white paper nmea 2000.pdf
Ceirwan
Well-Known Member
Well all the date from every sensor / device on the network has to go down the backbone which is the same wire that's used on the spurs, it has no extra capacity in anyway.
In fact my understanding of the wiring is that to all intents and purposes the network can't tell the difference between the spur and the backbone, it all looks like one and the same wire.
Either way I shall repost when I test it on the bench, I just need to pick up some of the bits I left at the boat as I was experimenting with positions.
Hoolie
Well-Known Member
Exactly the point I was trying to make in post no 27.
Well done for doing proper bench testing!
PaulRainbow
Well-Known Member
Then please post a digram where two sensors are connected to a single N2K drop cable.
If you want to chop some cables up and wire stuff up to bare wires that's a different story. It's possible to build a N2K network without using Tees, you can use bare wires and crimps/choc blocks/chewing gum. You could chop some cables up so you had connectors at one end for the device and bare wires at the other end, then you could run a bare wire cable from a tee to the first devic, loop over to the second device and then back to the tee. That is far from complying with the standard, you may have problems and it seems a pointless waste of time to avoid running two drop cables instaed of one.
Hoolie
Well-Known Member
I think you're being a bit myopic about this. I wasn't advocating multiple sensors - just saying it's technically feasible. Of course proper connectors are always better than chocolate blocks etc and anyway a tee connection could be used on a drop cable to keep things tidy .
As far as cables with connector one end and bare wires at the other, the Raymarine SPX30 autopilot that I have yet to install is wired exactly like that. All its connections are made through terminal blocks, including N2K.
As far as cables with connector one end and bare wires at the other, the Raymarine SPX30 autopilot that I have yet to install is wired exactly like that. All its connections are made through terminal blocks, including N2K.
Last edited:
Martin_J
Well-Known Member
indeed. techincally feasible..
One of the main reasons that NMEA2000 does not allow daisy chaining was because NMEA2000 only regulates the wiring and not the internal components of connected devices.. hence by daisy chaining you are breaking the wire connection by passing through a 3rd party device.. Also if that middle device fails, can you guarantee that onward connected devices will still reach the bus correctly.
nmea.org reason for not allowing daisy-chaining
Back to the OP.. I guess to save argument.. pull a pair of <6m cables through to the fore-cabin, one with the male end pulled through and one with the female end pulled through. You'll then be able to connect however many t-pieces you like in the fore-cabin for transducers..
In a few years you'll have a collection of NMEA2000 cables and t-pieces in your spares cupboard and you'll wonder what the fuss was about.. It all seems to work well.
One of the main reasons that NMEA2000 does not allow daisy chaining was because NMEA2000 only regulates the wiring and not the internal components of connected devices.. hence by daisy chaining you are breaking the wire connection by passing through a 3rd party device.. Also if that middle device fails, can you guarantee that onward connected devices will still reach the bus correctly.
nmea.org reason for not allowing daisy-chaining
Back to the OP.. I guess to save argument.. pull a pair of <6m cables through to the fore-cabin, one with the male end pulled through and one with the female end pulled through. You'll then be able to connect however many t-pieces you like in the fore-cabin for transducers..
In a few years you'll have a collection of NMEA2000 cables and t-pieces in your spares cupboard and you'll wonder what the fuss was about.. It all seems to work well.
Last edited:
JohnGC
Well-Known Member
There are some sensible comments here and some less informed. I thought it may help a little (for those interested) to add some information on the CAN/J1939/NMEA2000 relationship.
The underlying standard upon which NMEA2000 is based is CAN BUS (I’m sure everyone knows this.)
There are 2 main formats of CAN messages; those with standard 11-bit IDs and those with extended 29-bit IDs.
Many baud rates are possible. In practice the baud rates range from 50kbits/s to 1Mbits/s. Slower baud rates are more resilient, will transfer data over longer distances but have lower bandwidth (meaning less data can be transferred over the BUS in specified amount of time).
All devices on a BUS must have the same baud rate. So when designing a system, a compromise must be reached for baud rate based on the required bandwidth, overall BUS length, cable type, expected noise etc…..
Standard ID and extended ID messages can be used on the same BUS so long as the baud rates are the same.
Every device which transmits on a BUS has at least one ID which is unique. More than one device with the same ID is not allowed.
J1939 is an automotive standard. It specifies CAN extended IDs (29-bit) and a baud rate of 250kbits/s. J1939 also specifies a higher layer protocol which (among other things) allows devices to negotiate for IDs. It is this which makes “plug-and play” possible.
NMEA2000 is an extended version of J1939. It specifies many things which are relevant to the marine environment including cabling and connectors.
At the lowest level, CAN nodes (EG a sensor or display), operating in “normal” mode, acknowledge every message sent by every other node on the BUS. This enables auto-retransmission of messages which have not been acknowledged without any other intervention. In all devices I have programmed, this is an automatic function of the hardware, apart from setting it up, the application software isn’t involved. If a node doesn’t receive an acknowledgment within some predefined time, it will remove itself from the BUS and enter what is known as a BUS-OFF state.
So, in most circumstances, there is no such thing as a “listen only” node; every device writes to the BUS even if it is only to acknowledge other messages and to negotiate its ID.
(It is possible to have true listen only nodes but these are normally used for diagnostics. EG Test equipment that allows a developer to view BUS activity without effecting it.)
It is entirely possible to deviate from the NMEA2000 standard and expect it to work on a small boat installation. After all, CAN is a very robust and well tried communication system and small boats installations are not large. But, deviating from the standard will result in a less robust installation and testing it on the bench may not be a true representation of the boat.
The standard allows some flexibility for connections, barrier terminals are allowed for example. But they should be suitably protected.
In the end it comes down to reliability verses cost and convince. You don’t have to blindly follow the standard but it’s worth understanding what effect your deviation from it may have.
It is also worth bearing in mind that the cabling and connector section of the standard is concerned with data and power. So a device which fails to work on an overlong drop cable may well have a power supply issue rather than a data problem.
The underlying standard upon which NMEA2000 is based is CAN BUS (I’m sure everyone knows this.)
There are 2 main formats of CAN messages; those with standard 11-bit IDs and those with extended 29-bit IDs.
Many baud rates are possible. In practice the baud rates range from 50kbits/s to 1Mbits/s. Slower baud rates are more resilient, will transfer data over longer distances but have lower bandwidth (meaning less data can be transferred over the BUS in specified amount of time).
All devices on a BUS must have the same baud rate. So when designing a system, a compromise must be reached for baud rate based on the required bandwidth, overall BUS length, cable type, expected noise etc…..
Standard ID and extended ID messages can be used on the same BUS so long as the baud rates are the same.
Every device which transmits on a BUS has at least one ID which is unique. More than one device with the same ID is not allowed.
J1939 is an automotive standard. It specifies CAN extended IDs (29-bit) and a baud rate of 250kbits/s. J1939 also specifies a higher layer protocol which (among other things) allows devices to negotiate for IDs. It is this which makes “plug-and play” possible.
NMEA2000 is an extended version of J1939. It specifies many things which are relevant to the marine environment including cabling and connectors.
At the lowest level, CAN nodes (EG a sensor or display), operating in “normal” mode, acknowledge every message sent by every other node on the BUS. This enables auto-retransmission of messages which have not been acknowledged without any other intervention. In all devices I have programmed, this is an automatic function of the hardware, apart from setting it up, the application software isn’t involved. If a node doesn’t receive an acknowledgment within some predefined time, it will remove itself from the BUS and enter what is known as a BUS-OFF state.
So, in most circumstances, there is no such thing as a “listen only” node; every device writes to the BUS even if it is only to acknowledge other messages and to negotiate its ID.
(It is possible to have true listen only nodes but these are normally used for diagnostics. EG Test equipment that allows a developer to view BUS activity without effecting it.)
It is entirely possible to deviate from the NMEA2000 standard and expect it to work on a small boat installation. After all, CAN is a very robust and well tried communication system and small boats installations are not large. But, deviating from the standard will result in a less robust installation and testing it on the bench may not be a true representation of the boat.
The standard allows some flexibility for connections, barrier terminals are allowed for example. But they should be suitably protected.
In the end it comes down to reliability verses cost and convince. You don’t have to blindly follow the standard but it’s worth understanding what effect your deviation from it may have.
It is also worth bearing in mind that the cabling and connector section of the standard is concerned with data and power. So a device which fails to work on an overlong drop cable may well have a power supply issue rather than a data problem.
ctva
Well-Known Member
If you end up with a cupboard full of spare nmea 2k bits, you have more money than sense.
I installed a B&G 2k network last year, masthead wind, triducer and two Triton 1 displays and feel your pain with so much conflicting and ambiguous advise. The wind was the terminator then triducer teed off the backbone, power teed off the backbone too then to the cockpit to the two daisy chained Triton displays. This year I added a Vulcan 7 teed off the end of the daisy chained displays with a terminator on the tee. Also added an Actisense thingy to feed the 0183 AIS receiver in to the system. So far, touching all wood available, it all just works and the Vulcan displays everything including system status. Next winter a new auto helm will hopefully be added.
Best thing about the Vulcan is that it allows the iPad or phone to act as a full remote control and display for the entire system.
PaulRainbow
Well-Known Member
Geezus, this is the original question from the OP
So the whole thread is supposed to be about connecting two sensors to one drop cable !!!
Like i keep saying, this is not possible how the OP describes it. The only possible workaround is to use some bare wire connection, which do not comply with the standard, could cause problems and are not hardly future proof.
PaulRainbow
Well-Known Member
You mean like i said back in post #3, yes #3 !!
You disagreed in post #4 and your assertion was that it would work.
It will not work !!