Why is arcnet lost first when a fibre begins to fail

[ronjon]

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

Sounds like an obvious question but that does that look like? False targets or just snow like on a detuned TV?
I only ask as all I have ever seen the stripes you get from transponder pings and that weird effect you get when another ROV is in the water with SONAR running too.

[mind-when-this-was-fields]

pipetracker i hear ya! the voltage was checked and still the same locking probs..Gave it clean supply from a seperate unit.
This is not common on only one system.
I have seen it on a few xls and 2 xlx systems.
Even got modded board from Perry but it still there…
Now we are running with the comms bottle and its working it will stay that way for the noo!!!!

[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

Sounds like an obvious question but that does that look like? False targets or just snow like on a detuned TV?
I only ask as all I have ever seen the stripes you get from transponder pings and that weird effect you get when another ROV is in the water with SONAR running too.

Hi
No false target, just some white dots, yes like snow but not to bad (in the start) everytime i have seen it, well, close to make an re-term, i just try to keep it going to my relief come and i am on my way home 😉 😉 😉

[Anonymous]

Hi
Forgot to tell that i have seen it quite a few times, but i had nothing to do with it, it was the night shift, honest
😆 😆 😆

[Anonymous]

Isn’t it so that ARCNET gets converted into RS232 before going trough telemetry. Does it make more susceptible to data loss for an old computer network like ARCNET. 🙄

[Ray Shields]

Isn’t it so that ARCNET gets converted into RS232 before going trough telemetry. Does it make more susceptible to data loss for an old computer network like ARCNET. 🙄

From the description given, the 903 mux has an Arcnet card installed so no need to convert to RS232.

Intermittent sonar comms was always the number one indication that a reterm was coming up soon "back in the day" when everyone ran their sonar up a twisted pair.

[Anonymous]

From the description given, the 903 mux has an Arcnet card installed so no need to convert to RS232.

Manufacturer calling this ‘Tritech ARCNET’, does it mean it’s originaly designed for sonar.

Assuming that ROV communication was running on ARCnet as well!!!

[Savante]

thinking out aloud… from what i’m reading, I may be talkin utter BS.

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

need to look at the effect of data errors on the transmission of data and handshaking via tokens. The tokens are quite small, but if you get corruption I think you’d get complete data dropout and loss of the packet. Also I think you need a bit of time for the "active monitor" to correct. I think it’s to do with the synchronisation too.

With a video signal, the effect of loosing a couple of hundred bits in an image 24 (8 bit x 3 colours) x 640 (h)x 480 (w) x 30 (fps) would be exceptionally small. It would also be unlikely that there is syncing of the noise to a particular couple of pixels of each image frame. Also if you have inbuild MPEG compression in your system, the effect of noise is hard to discern as the averaging algorithm will probably knock it out.

Also in most ROV video, they tend to be very much low light level at which point, the noise of background pixels will be comparably high. What I’m saying is the noise may be there, but it’d be a bit more difficult to pick it up compared to ARCNET.

[Anonymous]

Reason ARCNET still being used is due to its tolerance against errors. 🙂

[Savante]

understood, apply BS filter to above !! 😆

ARCNET may not transmit the erroneous data, but if the transmission line is corrupted for one reason-other, will there not be a timeout issue?

is the sonar software setup to recover the data that should have been transmitted, or does it just turn around and say, "screw it", ignore that point and default to a 0-value signal on your sonar screen for the missed datapoint ? and carry on to get the next piece of data spat out by the sonar head?

Call this a work in progress or just cut n run n take my losses?? 😆

[ronjon]

I have been doing a little reading about the Arcnet networking system, very versatile protocol and used in heaps of applications under different names.
It seems one of the abilities of the system is that it automatically reconfigures itself if a new node is added or removed from the network, however if a communication request response times out it is assumed the node is no longer on the network and a reconfiguration burst is sent out. This burst is a jam signal of suficient strength and duration to destroy activity on the network and ensure all nodes are aware that a reconfiguration of the network is about to take place.

Engage BS filter from here on!!

I can only assume that if there is packet lost or corrupted and the turnaround timeout is exceeded the network is reset/remapped causing the brief glitch we see from time to time, add a heap of these together and we have a sonar lockup!

Sounds reasonable to me, especially as if an RS232 signal comes through as garbage it tends to get processed anyway and comes out as garbage. The Baud rate notwithstanding, RS232 standard requires a voltage in the region of +-10volts give or take a couple with a ground (0v refrence) which is usually incorperated into a screen making it a much more stable comms protocol but not capable of communicating with multiple sensors.

Another factor could be the length of communications string, as the RS232 strings send are only 8 to 40ish ASCII characters long as opposed to a much longer strings of data sent up to form the SONAR picture, longer string better chance of corruption.

Still would be interesting to find out how the signals are processed within the Focal 903 mux we have on here and if a packet is corrupted in transit up the fiber it is still output as a corrupted packet or just omitted, how does the mux (diagnostics page) know it has recieved a corrupted packet, does it add its own checksum to the end of the packet for diagnostic purposes?

[Savante]

arcnet adds a 4 byte field for crc and the rest of hte data is manc encoded. when it’s decoded topside, i think the data is passed if crc check is good.

After that if you have a crapped out ascii string, your sonar software will filter out some of the bad data if it doesn’t see the correct ascii string header on each transmitted statement. Effectively I think it parses the string. I don’t know if it puts in a default value if data is bad.

If you read the tritech bathy manual, there is a huge bit on the string format. I’ve not seen one for the sonar, but I imagine it’s similar.

[Savante]

http://www.arccontrol.com/aiusb.htm

[Anonymous]

http://www.tritech.co.uk/support/kb/seaking/sk-measuring-arcnet-oscilloscope.html

1. SEAKING SENSOR HEAD
1. Ensure that the Sensor is configured internally for ARCNET operation. Refer to the ‘Seanet Sensor Communications’ manual for details on jumper settings
2. Connect up the head to 24V power on pins 3 and 4 and fit a 39 Ohm resistor across the comms wires.

5. MEASURING THE SIGNAL
Regardless whether it is a Subsea Sensor or surface unit the signal is identical
Configure the oscilloscope as follows…
1. Set Timebase to 2.5usecs/div and Voltage Scale to 2volts/div
2. Always connect the probe tip to the yellow wire and the earth clip to the blue wire. Reversing this will invert the direction of the displayed sinusoidal waveform.
3. Observe the signal and compare with the drawing below.
a) Each pulse should form a complete sinusoid and have equal size above and below the zero line. Actual voltage levels measured may vary between devices
b) The timing should be as per the drawing for 156kBaud (Full baud rate).
4. At 78kBaud (half baud rate) the pulses will have the same voltage but duration will approximately double

ARCNET signal with device set to 156kBaud.

[rovnumpty]

Ronjon, svante, etc.

I reckon the reason arcnet is lost first is entirley due to the high data load sent up that channel by the sonar head. Nothing else on the sub sends up quite so much information on a single data channel.

Video is analogue so won’t ‘lock up’, and, as savante says, you’re not likely to notice a few missing lines in a video signal.

[Author]

Posts