Why is arcnet lost first when a fibre begins to fail

[ronjon]

Could anyone help me out with this one.

I am trying to work out why the Arcnet signal is the first thing to go when the fibre begins to fail.

I have found this a couple of times now, when either the sliprings start to stick or the main system fiber begins to reach the top of its loss budget the first thing to go is the Arcnet signal, SONAR and bathy always start to fail first, not so much as a ripple on the video or system telemetry but no Arcnet….

The fibre mux is a focal 903 running 8 video, 1 arcnet, 8 RS232 and 16 RS485 channels.

Any insight would be appreciated as I hate black box faults, I like to know why thing happen if you know what I mean.

[Spacer]

Don’t know what arcnet is but what is the bit rate?? Seems to me, the higher the resolution the more susceptible to signal loss and interference.

[ronjon]

Arcnet (Attached Resource Computer NETwork) is the network telemetry protocol Tritech uses and in my case on the Seanet SCU, as it is basically a network protocol it allows multiple sensors to be connected to one twisted pair, it is running at a baud rate of 115200.

However that being said I would have expected the bandwidth requirements of the 8 channel video system to be much wider and as such the first to be effected when the fibre attenuation starts to go up and the available bandwidth falls.

Just can’t get my head around the WHY of it if you catch my drift.

[James McLauchlan]

What is it?

Arcnet is an old LAN protocol most commonly seen in use offshore with subsea sensors such as Bathymetic/Profiling/Pipe/cable Tracking systems.

For more on Arcnet see:

http://en.wikipedia.org/wiki/ARCNET

[Ray Shields]

I assume its because Arcnet is such high speed data (115k I think) that it is more suceptible to losses.

I have seen 903 signals drop by 20db and the video is still fine (even when this puts it outwith the optical budget)

I assume from that line up you are using single mode on the 903, do you use the diagnostics program taht comes with the 903 to monitor the losses? very handy.

As I said, I believe its the high data rate of Arcnet.

[ronjon]

Not sure I can agree with that theory

Having checked the stats on the Focal903 mux when this first became an issue, it is capable of delivering 32video channels and HDTV signal and a RS232/RS485 baud rate of up to 2.5 Mbaud with a flux budget of 20dB.

I am sure you can agree the present setup is barely scratching the surface of the mux’s abilities, the Arcnet failure occured when the dB losses were in the region of 18dB.

We do run the Mux diagnostics software however it is somewhat limited as a fault finding tool as the sensors have never been calibrated. The trend graph is indispensable though as is the data loss counter.

To prevent any fault finding tangents this was the only fault we had on an otherwise stable system and the resolution was cleaning ad re-polishing all the fibre connectors on the system, dropping the losses to 12dB etc. etc.

Still left me at least with the question, why the Arcnet failure first and so long before anything else was effected, what makes it so susceptible to fibre losses?

[ronjon]

Could be I guess, would like to think a company designing equipment used in the ROV industry would try to make these things less susceptible to lost or currupted data packets.

I don’t suppose you know of any way that can be checked for in a Tritech Arcnet system? I haven’t tried it but I am guessing you can’t just monitor the string as you would RS232 via a com port and there doesn’t appear to be that sort of functionality on the Seanet SCU.

[pipetracker]

I assume its because Arcnet is such high speed data (115k I think) that it is more suceptible to losses.

I have seen 903 signals drop by 20db and the video is still fine (even when this puts it outwith the optical budget)

I assume from that line up you are using single mode on the 903, do you use the diagnostics program taht comes with the 903 to monitor the losses? very handy.

As I said, I believe its the high data rate of Arcnet.

I’d agree with this also. Don’t get too obsessed with optical budgets/theoretical performance either as the number of connections in a link will have a greater effect due to the reflections at each one which will go some way to ‘blurring’ the data stream. If you are lucky enough to see the fiber link deteriorte then usually you’ll see the sonar lock up first, then flashes on the video followed by telemetry failure. The same goes for a Prizm Video 3 system

[mind-when-this-was-fields]

I agree with pipetracker on perry tritons anyway!! you know when it needs a reterm as the sonar indeed starts to lock up….
However we have had problems with the arcnet on both xls and xlx systems and had to run with a tritech subsea sensor junction box for bathy/ alt and sonar.
Or run the sonar on rs232 if by itself……
Its all plug and play!!!!!!!!!!!! 😀

[Ray Shields]

Not sure I can agree with that theory

Having checked the stats on the Focal903 mux when this first became an issue, it is capable of delivering 32video channels and HDTV signal and a RS232/RS485 baud rate of up to 2.5 Mbaud with a flux budget of 20dB.

Fine, just passing on the experience that I have had in the past with Arcnet and muxes.

And assume you mean optical budget, not flux?

No matter if you are using 1 channel or all 32 channels, each channel in the 903 is allocated a specific amount of bandwidth, just because you dont use all the other bandwidth within the fibre does not mean the other channels will make use of it.

[pipetracker]

I agree with pipetracker on perry tritons anyway!! you know when it needs a reterm as the sonar indeed starts to lock up….
However we have had problems with the arcnet on both xls and xlx systems and had to run with a tritech subsea sensor junction box for bathy/ alt and sonar.
Or run the sonar on rs232 if by itself……
Its all plug and play!!!!!!!!!!!! 😀

Were you able to supply enough current? I’ve seen that being a problem before or the cross-sectional area of the intenal wiring in the survey pod is a bit marginal and you get a volt drop when you start loading on extra sensors like profilers.

[Scott Beveridge]

Arcnet is very susceptible to ANY noise. Noise could be caused by close proximity of AC power cables next to your data lines.

Try bringing the baud rate down a step at a time and see if this helps – beware that you don’t bring it down too far as you may get a data overflow message and end up bringing the baud up step at a time.

[Anonymous]

Hi
I have seen the same thing when fibre is on its way out, start with white dots on sonar, seen it a few times on SMD systems, the system i have been on use Prizm

[Scott Beveridge]

Hi
I have seen the same thing when fibre is on its way out, start with white dots on sonar, seen it a few times on SMD systems, the system i have been on use Prizm

As in Perry systems…

SMD has the monitoring software… works wonders except when the system has got an absolute CRAP main lift umb!!!!!!! Don’t need to check the FO…. all ya’ gotta do is count on your hands and feet and get ready for a (R… word)!!!!!!!!!!!!!!

I think all are in agreement when saying that the profilers, sonar, (sometimes) Seabats (sometimes) TSS or similar pipe tracking gear, and THEN video go pear-shaped (in this order) when the FO is on the way out.

[ronjon]

Thanks for all the insight, there is obviously alot of experienced guys watching these forums.

I understand it is accepted that the SONAR / survey equipment is the first thing to go when the fibre begins to fail, I accept the statement that Arcnet is susceptable to noise but the heart of the question is the why.

Been thinking about Arcnet, as it is basically a computer network, that must mean each node on the network has to wait its turn to communicate one at a time.
If a data packet comes in to the SCU corrupted it must ask for it to be resent causing a hang up until a good packet is recieved, this would certainly concur with what we see on the SONAR and what I have seen previously in regular computer networks.
This would also explain why shifting to RS232 resolves the issue as the RS232 standard utilises a higher voltage for data transmission and is a screened twisted pair as opposed to just a twisted pair.

[Author]

Posts