SC33 flapping on sensor list

[lucas111]

Good morning Gents,

Got a strange issue I'm dealing with for a couple of hours already with our brand new SC33.
The system is having 3x TZtouch2 (only one is powered at that time) with numerous equipment connected.
We've recently installed SC33 and on all TZtouch2 on sensor list the line with SC-33 is toggling between NBE100, Furuno Autopilot and SC-33.
When I unplug a part of the network (NBE100 and Autopilot) the line stays with SC-33 and it appears neatly in "Data source", but once one of the above equipment is plugged back it starts swapping between those 3 devices.

The vesion of TZtouch2 is 6.21 and 6.26, SC-33 works with 20180216 1134 : 2051594-01.02

Anybody experienced those kind of issues?
Crate of beer for a good hint!

KR,
Lucas

 

[lucas111]

Adding photos since the video didn't want to upload.
The toggling time between those two devices is around 5 seconds.

KR,
Lucas

 

[Johnny Electron]

You have a NMEA 2000 bus issue maybe caused by one of the new devices, tee, or cable added. The system is designed to cycle through sources when it can't find the data type it is looking for. When the bus is bad, the SC33 data isn't seen by the system so the "current" selection is cycling between devices looking for data. If the "preferred" becomes usable it will lock onto it. When all is well, the preferred and current will be the same like it does when your bus is reduced. Something bad is happening to your bus when adding those other items. When the bus is bad, try turning everything off including NMEA 2000 bus power and ohm out the signal lines of the bus with a meter (white and blue). It should be 60 ohms. It isn't always termination problems but an easy thing to test.

 

[lucas111]

Hi,

That's exactly what I was suspecting at first, however 60Ohms in all the parts of the network.
I've also moved the NBE100 to another Tee ports and similar issue.

I've got Maretron Analyzer and can see data flowing constantly with 10Hz rate as expected.
The only issue looks to be MFD since FL70s are seing the SC33 with no problems.

Would you recommend any software update that may help out?

Is there any possibility that MFD needs to be reset because even the SC-30 settings in "Initial settings" are greyed out since we've moved from SC30 to SC33.

 

[Johnny Electron]

The SC33 should be seen no matter what the version of software currently in the MFD or SC33. If the MFD is has new enough to have the words "SC33" and it is grayed out; it isn't seeing the device clearly. I would recommend a Mareton tester to see if you can find the bus problem. A twisted NMEA 2000 cable will ohm out good all day long but act as an inductor and filter or distort high speed communications. You won't see that with a multi-meter. That is just an example. Because the bus is in parallel, you only need to ohm in one location on the bus. I am guess the 600 ohms was a typo? Checking power at different locations is a good idea in case the LEN values are exceeding the bus design.

 

[lucas111]

Thanks for the reply - much appreciated.
Today I've swapped the SC33 for the previously installed SC30 and no issues at all.
SC30 appears on TZTouch2 with it's settings (offsets, etc.) - works like a charm.

The question is, what can be wrong with SC33 since I've directly exchanged the equipment for SC30 - the same drop cable.

Also I've noticed that still our autopilot and NBE100 are "swapping places" in "sensor list", however after exchanging the NBE100 for a different one, the problem was solved.

I do have the Maretron Network Analyzer software and blue Maretron Analyzer. The analyzer shows no errors - smiley face. I can see the network congestion from 30-70% with at times peaks of 99% (but once per 30minutes or so).

Not sure how to proceed at that moment since it maybe just some software issue (which I'd like to have) instead of hardware one.

 

[Johnny Electron]

The connections at the antenna for the SC33 and SC30 are not the same. You have to be doing something different as you swap them because it isn't the same cable. So why did you replace a working SC30 to begin with?

 

[lucas111]

It's a long cruising vessel therefore we'd need to have a spare part for that crucial equipment in case of failure. That's the reason we've installed SC33 with SC30 staying as a replacement "just in case".

The interesting part is that NBE100, Sailmon WindBox, Autopilot700 and SC33 were toggling on "Sensor list" alternatively. Once I've relaced NBE100 with another one we have it stopped toggling.
Exchanging SC33 for SC30 took it out from the toggling list as well.
Should we suspect an issue with SC33 then?
What would you recommend about Windbox and Autopilot700 case which is now causing issue?

I see all the devices with Maretron Analyzer software (via IPG100) giving solid data all the time.
Maretron Blue Analyzer shows maybe 10 errors within an hour time, so I'd assume not much (but please correct me if I'm wrong).

Is it possible that some IDs are being duplicated in those devices?

 

[Johnny Electron]

10 errors per hour is evidence of a bus problem. An unreadable PGN is counted as an error, so at least 10 PGNs per hour are corrupted on the bus. Here are a couple of items to check/consider. 1) Check the NODE address are all unique. I don't have any experience with the NBE so it would be good to verify with the Analyzer that there are no duplication of Nodes. 2) Regarding the SC30 and SC33 initial settings. It is normal for the "SC30" to gray out when the SC33 is connected because it is not the same unit. The setup of the SC33 is in a totally different area.View attachment SC30SC33.pdf
Another possible reason you don't see data from the SC33 but do from the SC30 is because of the GPS almanac data (course orbital parameters of all the satellites). The first time a unit is powered on is does not have an almanac. It takes a bit of time to acquire the satellites and build the almanac data. If you are under a covered area, it is possible that the SC30 gets data because it has a full almanac but the SC33 can't because it doesn't. Replacing the NBE100 was a good start if he help the toggling stop. That means the unit is able to lock onto clear data and stay on a source. Your gaining ground but there is still something going on with the bus.

 

[lucas111]

Hi Johnny,

I think we've narrowed down the possible fault.
Since a similar issue was happening with our FL70s I've checked the Unique CAN ID and on the toggling devices it was similar - (CAN Unique ID: 4660). However the CAD addresses differ - see attached picture.

The question then is, how we can force the CAN Unique ID to reqauire/ change its ID then? Or is it a normal behaviour?
That applies to both FL70s and NavPilot700 cases.

I was suspecting a cabling issue, but I've just connected two FL70s to a brand new network with only 2 tees and the photo is taken from that very installation.

All advices are more than welcome.

 

[lucas111]

However the interesting thing is that not all the FL70s are behaving like that.
I've got 4x FL70s with different CAN-ID (5420, 5278, 10002, etc.), but the remaining 6 stay with CAN-ID: 4660.

Would it be connected with serial numbers or the time we've bought the equipment?
Is it a normal behaviour?

 

[Johnny Electron]

Yeah that looks like a problem with the unique ID. Can you please PM me the serial number to both of those unit?