Thread: Investigating possible effects of EMI on FireWire cameras
Brought to you by:
aeb,
bencollins
From: Alex J. <al...@nu...> - 2014-06-07 05:50:56
|
Good morning, I am using a pair of FireWire cameras (Guppy/Guppy Pro) connected via an AVT pci controller card (TI-TSB43AB22A). I'm using them as vision cameras for an underwater autonomous vehicle. I'm facing a very weird issue where the cameras shut down when certain thrusters are fired. The device disappears from the device list and has to be physically replugged to raise it again. Is anyone here familiar with this kind if issue? The cable is spliced and joined again using molex connectors and shielded with aluminum foil for extra protection. We are thinking that it shuts down because of EMI. Reducing the data rate does not seem to help. All thrusters firing as fast as possible on land does not seem to cause any issues but as soon as the vehicle is in water we lose the FireWire devices. Any input would be appreciated! Thanks alex |
From: Damien D. <dd...@do...> - 2014-06-07 07:27:49
|
Hi Alex, On Sat, 2014-06-07 at 13:50 +0800, Alex John wrote: > Good morning, > > I am using a pair of FireWire cameras (Guppy/Guppy Pro) connected via > an AVT pci controller card (TI-TSB43AB22A). I'm using them as vision > cameras for an underwater autonomous vehicle. I'm facing a very weird > issue where the cameras shut down when certain thrusters are fired. > The device disappears from the device list and has to be physically > replugged to raise it again. That looks like a power supply issue to me... At least I would start investigating there with a multimeter to see if/how the voltage drops on the supply rails when the motors run. If you use batteries or an umbilical (any other option anyway? :) you may get voltage drops due to batteries limitations or wire resistance. Next step is using a scope to check the noise on the supply voltage, if the motors run on the same supply as the cameras. > Is anyone here familiar with this kind if issue? The cable is spliced > and joined again using molex connectors and shielded with aluminum > foil for extra protection. We are thinking that it shuts down because > of EMI. > > Reducing the data rate does not seem to help. All thrusters firing as > fast as possible on land does not seem to cause any issues but as soon > as the vehicle is in water we lose the FireWire devices. I imagine that motors won't draw maximum current above water as the medium is much less dense. The motors' current will be higher underwater (higher torque required) and the supply rails may then drop significantly. OTOH 1394 cameras have DC-DC converters to deal with the varying supply voltage found on 1394 busses, so they should be able to cope with transients. Of course the cams may fail if you supply them at a nominally low voltage (e.g. 5V) and the voltage drops further down. What kind of supply are you using? If you supply 12V to the cameras they should be able to cope with supply variation pretty well. Damien -- Damien 高原 Douxchamps http://damien.douxchamps.net/ |
From: Stefan R. <st...@s5...> - 2014-06-09 10:42:02
|
On Jun 07 Damien Douxchamps wrote: > On Sat, 2014-06-07 at 13:50 +0800, Alex John wrote: > > I am using a pair of FireWire cameras (Guppy/Guppy Pro) connected via > > an AVT pci controller card (TI-TSB43AB22A). I'm using them as vision > > cameras for an underwater autonomous vehicle. I'm facing a very weird > > issue where the cameras shut down when certain thrusters are fired. > > The device disappears from the device list and has to be physically > > replugged to raise it again. > > That looks like a power supply issue to me... At least I would start > investigating there with a multimeter to see if/how the voltage drops on > the supply rails when the motors run. If you use batteries or an > umbilical (any other option anyway? :) you may get voltage drops due to > batteries limitations or wire resistance. > > Next step is using a scope to check the noise on the supply voltage, if > the motors run on the same supply as the cameras. [...] I too think that this sounds more like instability or noise on the power supply rails rather than HF noise on the signal lines. Incidentally, I too have got a "device disappears" problem at home with a cable TV box (FireDTV C/CI): Often when another electrical device is switched on (or sometimes when switched off) at the 230 V 50 Hz power grid --- e.g. a PC, monitor, RAID enclosure, or vacuum cleaner ---, the bus with the FireDTV sees a bus reset, and the phy of the FireDTV is no longer present according to selfID reception. To recover, the FireDTV has to be plugged out and in again. The FireDTV has a TSB41AB2 phy according to lsfirewirephy from jujuutils. I have got some other devices with TSB41AB2 phy though which do not exhibit such an issue. Usually I power the FireDTV from one or another PC's FireWire bus power. The PCs don't exhibit any other stability issues though, neither do any of a bunch of other bus-powered FireWire devices of various kinds. The PCs' PSUs (Seasonic models from different generations) are said to deliver comparatively clean and stable output. From a few brief tests it seems there are two ways to fix this issue: - Powering the FireDtV from a separate 12 V PSU, or - putting a ground loop filter (a capacitive coupler, I think) between TV cable and FireDTV. So I suspect that my particular issue is not actually caused by a voltage drop on the FireWire bus on its own but by a current between FireWire ground and TV cable ground. -- Stefan Richter -=====-====- -==- -=--= http://arcgraph.de/sr/ |
From: Alex J. <al...@nu...> - 2014-06-09 11:04:14
|
> On 9 Jun, 2014, at 18:41, Stefan Richter <st...@s5...> wrote: > >> On Jun 07 Damien Douxchamps wrote: >>> On Sat, 2014-06-07 at 13:50 +0800, Alex John wrote: >>> I am using a pair of FireWire cameras (Guppy/Guppy Pro) connected via >>> an AVT pci controller card (TI-TSB43AB22A). I'm using them as vision >>> cameras for an underwater autonomous vehicle. I'm facing a very weird >>> issue where the cameras shut down when certain thrusters are fired. >>> The device disappears from the device list and has to be physically >>> replugged to raise it again. >> >> That looks like a power supply issue to me... At least I would start >> investigating there with a multimeter to see if/how the voltage drops on >> the supply rails when the motors run. If you use batteries or an >> umbilical (any other option anyway? :) you may get voltage drops due to >> batteries limitations or wire resistance. >> We already filter the power to a certain degree and the wire resistance was measures and found to be okayish. I can get the exact measurements but this brings me to the issue that I forgot to mention which I'll detail below- >> Next step is using a scope to check the noise on the supply voltage, if >> the motors run on the same supply as the cameras. > [...] > > I too think that this sounds more like instability or noise on the power > supply rails rather than HF noise on the signal lines. > > Incidentally, I too have got a "device disappears" problem at home with a > cable TV box (FireDTV C/CI): Often when another electrical device is > switched on (or sometimes when switched off) at the 230 V 50 Hz power > grid --- e.g. a PC, monitor, RAID enclosure, or vacuum cleaner ---, the bus > with the FireDTV sees a bus reset, and the phy of the FireDTV is no longer > present according to selfID reception. To recover, the FireDTV has to be > plugged out and in again. > > The FireDTV has a TSB41AB2 phy according to lsfirewirephy from jujuutils. > I have got some other devices with TSB41AB2 phy though which do not > exhibit such an issue. > > Usually I power the FireDTV from one or another PC's FireWire bus power. > The PCs don't exhibit any other stability issues though, neither do any of > a bunch of other bus-powered FireWire devices of various kinds. The PCs' > PSUs (Seasonic models from different generations) are said to deliver > comparatively clean and stable output. > > From a few brief tests it seems there are two ways to fix this issue: > - Powering the FireDtV from a separate 12 V PSU, or > - putting a ground loop filter (a capacitive coupler, I think) between > TV cable and FireDTV. > > So I suspect that my particular issue is not actually caused by a voltage > drop on the FireWire bus on its own but by a current between FireWire > ground and TV cable ground. Thanks for the suggestions, I'll look into it but there's another aspect of the problem that I forgot to mention. The cameras that die are always the external cameras. The difference is that we have cut the cables and used our own underwater cables including connectors. The camera that is in the hull connected straight using the original FireWire cable never has any issues. Both cameras are running on the same power system. > -- > Stefan Richter > -=====-====- -==- -=--= > http://arcgraph.de/sr/ Thanks Alex |
From: Carl K. <ca...@pe...> - 2014-06-09 13:41:17
|
On Mon, Jun 9, 2014 at 6:04 AM, Alex John <al...@nu...> wrote: > The cameras that die are always the external cameras. The difference is > that we have cut the cables and used our own underwater cables including > connectors. The camera that is in the hull connected straight using the > original FireWire cable never has any issues. Both cameras are running on > the same power system. The cameras that die are always the external cameras, and only when submerged, right? Would it be possible to do a test with the same cameras inside? Ideally with a new cable and then as much of the modified cabling as possible. Also, can we get a picture of the underwater cables including connectors? Long shot: can you take the external cameras out of the system and loop the firewire back to the other firewire port and see if there is any odd behavior? The thought is maybe the system side firewire chips may be the ones being disrupted by dirty signals. -- Carl K |
From: Clemens L. <cl...@la...> - 2014-06-09 14:01:26
|
Alex John wrote: > we have cut the cables and used our own underwater cables including > connectors. The camera that is in the hull connected straight using > the original FireWire cable never has any issues. So you made your own FireWire cables? How did you ensure that these cables conform to the IEEE-1394 specification? Did you test them? <http://www.1394ta.org/developers/PublicSpecs/2009008.pdf> Regards, Clemens |
From: Stefan R. <st...@s5...> - 2014-06-09 14:25:42
|
On Jun 09 Alex John wrote: >>>> On Sat, 2014-06-07 at 13:50 +0800, Alex John wrote: >>>>> The cable is spliced >>>>> and joined again using molex connectors and shielded with aluminum >>>>> foil for extra protection. We are thinking that it shuts down because >>>>> of EMI. [...] > The cameras that die are always the external cameras. The difference is > that we have cut the cables and used our own underwater cables including > connectors. The camera that is in the hull connected straight using the > original FireWire cable never has any issues. Both cameras are running > on the same power system. Did you use stock 1394 cable material, or other material? Here are some points from the IEEE 1394 reference cable constructions concerning the shields and their connections to the plugs, for comparison: - Each of the two data pairs has got its own shield. In addition, there is an outer shield around everything, including the power pair. - In 4-4, 4-6, 4-9, 6-9 pin cables, the two inner shields around the data pairs shall be in contact with each other and shall be isolated from the outer shield. - In 9-9 pin cables, the two inner shields should be isolated from each other and shall be isolated from the outer shield. - The inner shields shall be connected with the 4-pin connector's plug shield, or with the 6-pin connector's VG pin, or with the 9-pin connector's dedicated Twisted Pair A Ground Reference and Twisted Pair B Ground Reference pins, respectively. - The outer shield shall be connected with the 6- or 9-pin connector's plug shield. [These and the other parameters of the reference cable constructions, such as permissible length and wire gage, are just examples which work, not strict requirements. Actual requirements of the standard are specified in terms of performance criteria, as far as I understand, not being an electrical engineer.] Did you als modify anything at the device side, i.e. boards or chassis? If so, the question is whether termination and isolation of the signal pairs, power pair, and shields are affected by those modifications. -- Stefan Richter -=====-====- -==- -=--= http://arcgraph.de/sr/ |