Need N2K technical knowledge

[colemj]

I was just looking through the diagnostics pages of several of our N2K MFD's and noticed something I do not understand.

We have 3 B&G Triton Displays and a Simrad AP display connected to a N2K backbone. When I look at the network diagnostics on the B&G displays, they show transmit errors ranging in number from 0-300 (constantly changing). This number is different for each display. There are no receive errors on any display.

On the Simrad diagnostics, there are receive errors ranging in number from 0-30 (constantly changing). There are no transmit errors.

The B&G displays do not transmit any N2K data - they only receive. The Simrad AP transmits standard AP PGN's.

The network and systems attach to it work just fine. The other equipment connected to the network are the depth and speed transducers, the wind instrument, the GPS, the Simrad rate compass, a Furuno MFD, and Actisense and Maretron 2000-0183 converters.

Can anyone explain what I am seeing, the consequences of it, and any remedy that is necessary?

Thanks,
Mark

[MarkSF]

Well the displays do transmit data, in the sense that they repeat it on the output so that they can be daisy chained.

I don't think that your question can be answered without knowing how the devices have been connected. They SHOULD be either daisy chained as part of the backbone, or have individual drop cables. They MIGHT have been connected to the backplane with one drop, then daisy chained together, which is not recommended.

However, as I've discovered myself, with NMEA2000 you can do things that aren't recommended and it can still work. (have an NMEA2000 network with SIMNET connected to a drop, then SIMNET devices daisy chained - they tell you not to do this.)

Only you can decide whether it's worth re-wiring a system that works fine but has some errors.

See pages 18 and 19 :

http://www.bandg.com/Documents/produ...language=en-GB

[colemj]

I should have mentioned the topography.

All instruments and displays are connected direct to the backbone via drop cables with the exceptions of the Wind and GPS, which are located on each end of the backbone and terminated with in-line terminators at each. None are daisy chained.

The B&G displays drop individually into a Maretron multiport box that is connected directly to the backbone. The Simrad display drops onto a Simnet multiport box that is connected directly to the backbone.

Mark

[MarkSF]

The wind devices are designed to go on the end of the backbone, as it's the only way to get around the drop cable length limit and have a cable longth enough to go up the mast.

Some wind devices have the terminating resistor in them, so you don't need to add another. I have the B&G wind sensor, and I did not terminate it. I assumed it had one in it...

Are you sure the GPS is intended to do the same? I would expect it to be on a drop on a T at the end of the backbone, then the terminating resistor to be on the end of the T. (as in the diagram on page 19). Maybe it is that way, but that's not how I read your post.

[MarkSF]

Never mind, just researched inline terminators. So the only thing I can see, that might be wrong, is that you might have terminated the wind instrument twice. That's a question for B&G.

I think the errors you are getting are another question for B&G I'm afraid....

[colemj]

The wind instrument is a Maretron ultrasonic, not B&G. It does not have a built in terminator.

Do you get any error messages in the diagnostics menu on your B&G displays or Simnet displays?

Mark

[mrm]

Have you tried the classic troubleshooting technique of physically disconnecting devices from the backbone?

Marius

[goboatingnow]

My experience with nmea2k is there is always some TX errors, the canbus protocol handles them automatically. In any sizeable systems I've analysed, there always seemed to be a proportion of unexplained TX and therefore RX errors. I've never dug much farther, perhaps others might like to comment

I know that simnet seems to very sensitive to ringing , as are all canbus systems as long runs ( Especially up the mast etc) can cause mismatch errors etc. there is a little know Simrad Simnet noise filter

See http://www.panbo.com/archives/2011/0...se_filter.html

By the way , daisy chaining does not require rebroadcasting of the data. ( which causes collision domain issues ), its just that the drop cable is in effect inside the device and breaks the rules for minimum drop cable length. ( a function of bit propagation times )

Dave

[colemj]

The system does seem to run without fault (and has for over a year). I find it strange that the instruments that have no transmit functions activated have transmit errors and no receive errors, while the ones that do transmit have receive errors, but no transmit errors. Perhaps I am thinking about this backwards.

I will try disconnecting pieces from the system and see what effect that has.

Mark

[goboatingnow]

Originally Posted by colemj

The system does seem to run without fault (and has for over a year). I find it strange that the instruments that have no transmit functions activated have transmit errors and no receive errors, while the ones that do transmit have receive errors, but no transmit errors. Perhaps I am thinking about this backwards.

I will try disconnecting pieces from the system and see what effect that has.

Mark

All instruments transmit on the bus. ( Address claim , ID exchange , NACK , etc etc ) Irrespective of their nominal function
Remember on a canbus , their will be legitimate collisions, retrys , etc these may be counted as TX errors as technically they show up on the bus as TX faults.

I am surprised that some have one fault and not the other, but there is no standardised way to count or display TX and RX faults anyway.

Dave

[s/v Jedi]

You have the Maretron USB gateway, with which you can emulate a DSM250 display. Go to display settings, Bus status and you get a real time monitor. Mine currently says CAN Frame: 4.7% traffic; 90 fps Rx rate, 0fps Tx rate, Error count: 0 Times. Then it shows a frame counter running.

When you switch off the AP do you get new errors on the displays?

[colemj]

So it appears the WSO-100 ultrasonic wind instrument is causing the errors. When I unplug it (and terminate the backbone), the errors go away. Perhaps it is sending data that the B&G Tritons do not recognize? The Tritons do not read relative humidity. However, the WSO100 only sends an "environmental" PGN containing all of the data - much of it recognized by the Triton (wind, temp and pressure), but some not (relative humidity).

Or maybe the inline terminator is bad.

When I look at the DSM250 display, I see 44.4% traffic, 845 fps RX rate, 2 fps TX rate, error count 4 times and nothing on the frame counters.

Mark

[MarkSF]

I looked at the WSO-100 manual and it was a bit ambiguous about whether it was terminated internally. Maybe it's worth asking their technical support? Or, alternatively, remove your inline terminator and see what happens

[goboatingnow]

It also could just be noise from the long cable run, There was also the issue of the inline terminator with Airmar, didnt they produce one with switchable ternmination , that NMEA ruled out of order and then they shiped ones with no termination.!

Did Maretron have the same issues??

Dave

[s/v Jedi]

I think it's just the cable length. I would ignore it but you could test the terminator if the errors go worse. If all stays like it is, I wouldn't bother.

Well, you could create a smaller network with just the segment up the mast and a display and power T at the base of the mast. Just to see if errors go away.