Thread: basler camera on firewire
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-user
|
From: Robert L. <rob...@se...> - 2011-11-01 23:45:22
|
hi everyone, not sure how to approach this, don't know much about linux firewire support/ any pointers welcome: I have a basler a601f firewire camera, and a debian squeeze machine that I would like to use the camera with. kernel is a 2.6.32-5-amd64, lspci lists my firewire card: 03:01.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 61) lsmod | grep firew reports: firewire_ohci 19676 0 firewire_core 36848 2 firewire_sbp2,firewire_ohci crc_itu_t 1307 1 firewire_core i tail /var/log/kern.log and modprobe firewire_ohci debug=7 (after removing it first of course): Nov 1 23:40:08 sandbender kernel: [54557.082719] firewire_ohci 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 Nov 1 23:40:08 sandbender kernel: [54557.152008] firewire_ohci: Added fw-ohci device 0000:03:01.0, OHCI version 1.0 Nov 1 23:40:08 sandbender kernel: [54557.152014] firewire_ohci: IRQ 00000010 AR_req Nov 1 23:40:08 sandbender kernel: [54557.152020] firewire_ohci: AR evt_bus_reset, generation 147 Nov 1 23:40:08 sandbender kernel: [54557.152023] firewire_ohci: IRQ 00010000 selfID Nov 1 23:40:08 sandbender kernel: [54557.152034] firewire_ohci: 1 selfIDs, generation 147, local node ID ffc0 Nov 1 23:40:08 sandbender kernel: [54557.152037] firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci Nov 1 23:40:09 sandbender kernel: [54557.652109] firewire_core: created device fw0: GUID 0000d100802a6abc, S400 if i leave it like that i get this every now and then: Nov 1 23:41:06 sandbender kernel: [54614.877141] firewire_ohci: IRQ 00200000 cycle64Seconds if i plug in my camera I get: Nov 1 23:41:36 sandbender kernel: [54645.307192] firewire_ohci: AR evt_bus_reset, generation 148 and unplugging the camera gives me: Nov 1 23:41:56 sandbender kernel: [54665.004775] firewire_ohci: IRQ 00000010 AR_req Nov 1 23:41:56 sandbender kernel: [54665.004782] firewire_ohci: AR evt_bus_reset, generation 149 Nov 1 23:41:56 sandbender kernel: [54665.005770] firewire_ohci: IRQ 00000010 AR_req Nov 1 23:41:56 sandbender kernel: [54665.005774] firewire_ohci: AR evt_bus_reset, generation 150 Nov 1 23:41:56 sandbender kernel: [54665.005948] firewire_ohci: IRQ 00010000 selfID Nov 1 23:41:56 sandbender kernel: [54665.005958] firewire_ohci: 1 selfIDs, generation 150, local node ID ffc0 Nov 1 23:41:56 sandbender kernel: [54665.005961] firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci Nov 1 23:41:56 sandbender kernel: [54665.005963] firewire_core: skipped bus generations, destroying all nodes Nov 1 23:41:57 sandbender kernel: [54665.504029] firewire_core: rediscovered device fw0 but I don't think the camera actually works. I don't get any device for it (I was expecting something in the logs, or a /dev/fw1 or so to appear, am I wrong?), and coriander claims that no camera is connnected. so: is this the right direction? should this work? Can anyone see something obvious? How should I go on from here? thanks robert |
|
From: Stefan R. <st...@s5...> - 2011-11-02 09:01:46
|
On Nov 01 Robert Lemmen wrote: [...] > i tail /var/log/kern.log and modprobe firewire_ohci debug=7 (after > removing it first of course): > > Nov 1 23:40:08 sandbender kernel: [54557.082719] firewire_ohci 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 > Nov 1 23:40:08 sandbender kernel: [54557.152008] firewire_ohci: Added fw-ohci device 0000:03:01.0, OHCI version 1.0 > Nov 1 23:40:08 sandbender kernel: [54557.152014] firewire_ohci: IRQ 00000010 AR_req > Nov 1 23:40:08 sandbender kernel: [54557.152020] firewire_ohci: AR evt_bus_reset, generation 147 > Nov 1 23:40:08 sandbender kernel: [54557.152023] firewire_ohci: IRQ 00010000 selfID > Nov 1 23:40:08 sandbender kernel: [54557.152034] firewire_ohci: 1 selfIDs, generation 147, local node ID ffc0 > Nov 1 23:40:08 sandbender kernel: [54557.152037] firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci > Nov 1 23:40:09 sandbender kernel: [54557.652109] firewire_core: created device fw0: GUID 0000d100802a6abc, S400 > > if i leave it like that i get this every now and then: > > Nov 1 23:41:06 sandbender kernel: [54614.877141] firewire_ohci: IRQ 00200000 cycle64Seconds This is all correct and expected. > if i plug in my camera I get: > > Nov 1 23:41:36 sandbender kernel: [54645.307192] firewire_ohci: AR evt_bus_reset, generation 148 [...] This on the other hand is far less than what should happen. Among else you should get one or two "selfID" IRQ events which contain 2 selfIDs --- one of the FireWire controller and one of the camera. After that there should be a bunch of AT and AR events when firewire-core probes the camera. Finally, firewire-core should report something like "created device fw1: GUID 003053.........., S400". This not happening could be caused by - defect of the FireWire port of the PC, - cable defect, - defect of the FireWire port or of the logic board of the camera, - insufficient power supply of the camera. -- Stefan Richter -=====-==-== =-== ---=- http://arcgraph.de/sr/ |
|
From: Robert L. <rob...@se...> - 2011-11-02 18:08:19
Attachments:
signature.asc
|
stefan, folks, On Wed, Nov 02, 2011 at 10:01:33AM +0100, Stefan Richter wrote: > This not happening could be caused by > - defect of the FireWire port of the PC, > - cable defect, > - defect of the FireWire port or of the logic board of the camera, > - insufficient power supply of the camera. an excellent checklist! I'll go off and verify all of this. The last item seems especially suspicious, the camera is bus-powered after all. The firewire card is PCI (not pcmcia or anything weird), and i was expecting it to provide bus power. but it's not one of the cards that have an extra power supply connector... cu robert -- Robert Lemmen http://www.semistable.com |
|
From: Stefan R. <st...@s5...> - 2011-11-02 23:47:13
|
On Nov 02 Robert Lemmen wrote: > The firewire card is PCI (not pcmcia or anything weird), and i was > expecting it to provide bus power. but it's not one of the cards that > have an extra power supply connector... From the Basler A601f-HDR user manual: "Power must be supplied to the camera via the IEEE 1394 cable. Nominal input voltage is +12.0 VDC, however, the camera will operate properly on any input voltage from +8.0 VDC to +36.0 VDC as specified in the IEEE 1394 standard. Maximum power consumption for the A601f-HDR is 1.7 W at 12 VDC. Ripple must be less than 1%." A PCI slot has a single +12V pin. I don't know what its current and ripple ratings are, whether PCI devices share a power budget on the +12V rail. (PCI also has got +3.3V, +5V, -12V power rails. The Agere FW323 link and phy is a 3.3V powered device, so it is at least unlikely that the 1394 controller card itself uses the +12V rail for anything else besides 1394 bus power.) -- Stefan Richter -=====-==-== =-== ---== http://arcgraph.de/sr/ |
|
From: Carl K. <ca...@pe...> - 2011-11-02 19:31:28
|
On Wed, Nov 2, 2011 at 1:08 PM, Robert Lemmen <rob...@se...> wrote: > stefan, folks, > > On Wed, Nov 02, 2011 at 10:01:33AM +0100, Stefan Richter wrote: >> This not happening could be caused by >> - defect of the FireWire port of the PC, >> - cable defect, >> - defect of the FireWire port or of the logic board of the camera, >> - insufficient power supply of the camera. > > an excellent checklist! I'll go off and verify all of this. The last > item seems especially suspicious, the camera is bus-powered after all. > The firewire card is PCI (not pcmcia or anything weird), and i was > expecting it to provide bus power. but it's not one of the cards that > have an extra power supply connector... > This is more for me than you, but it might help you.... If you have a 2nd firewire controller (card), plug one card into the other and run: https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c If it finds an error, then the problem is one of the cards or cable and probably not the camera. Or the program is whacked. This is something a friend wrote, I haven't gotten around to testing it other than "it runs! great! thanks! I'll buy you a beer!" -- Carl K |
|
From: Clemens L. <cl...@la...> - 2011-11-03 08:47:08
|
Stefan Richter wrote: > "Maximum power consumption for the A601f-HDR is 1.7 W at 12 VDC." > > A PCI slot has a single +12V pin. I don't know what its current and > ripple ratings are, whether PCI devices share a power budget on the > +12V rail. PCI cards have two sense lines to tell the motherboard if they use up to 7.5, 15, or 25 W. (I'd guess there are as many motherboards that make use of this information as there are FireWire power managers.) However, the maximum 12 V current is 500 mA, so bus power (with up to 1.5 A) must come from a separate power connector. Regards, Clemens |
|
From: Robert L. <rob...@se...> - 2011-11-07 20:32:18
Attachments:
signature.asc
|
On Thu, Nov 03, 2011 at 09:47:58AM +0100, Clemens Ladisch wrote: > PCI cards have two sense lines to tell the motherboard if they use up to > 7.5, 15, or 25 W. (I'd guess there are as many motherboards that make > use of this information as there are FireWire power managers.) However, > the maximum 12 V current is 500 mA, so bus power (with up to 1.5 A) must > come from a separate power connector. ok, I have found another firewire card. it says "ma-133" on it, and lscpi says: 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) this card has two jumpers on it labeled "Internal 12V" and "External 12V". It also has a white 4-pin power connector. I have tried the same thing with this card, with and without direct power, with all settings of the jumpers, and with all ports of it. same problem: no device is created for the camera, when I unplug it I get: [ 378.411546] firewire_ohci: IRQ 00000010 AR_req [ 378.411553] firewire_ohci: AR evt_bus_reset, generation 5 [ 378.411557] firewire_ohci: IRQ 00010000 selfID [ 378.411567] firewire_ohci: 1 selfIDs, generation 5, local node ID ffc0 [ 378.411570] firewire_ohci: selfID 0: 807f8956, phy 0 [---] S400 gc=63 +15W Lci [ 378.411572] firewire_core: skipped bus generations, destroying all nodes [ 378.908018] firewire_core: rediscovered device fw0 and when i plug it in I get: [ 406.438553] firewire_ohci: IRQ 00000010 AR_req [ 406.438559] firewire_ohci: AR evt_bus_reset, generation 6 with stuff like this every now and then: [ 387.448656] firewire_ohci: IRQ 00200000 cycle64Seconds I ran the test program, and it leads me to believe both my cards and the cables are ok (but see my other mail). so: - is that other chip (VIA VT6306) ok? - has anyone a similar card? what have you set your jumpers to? - there is another 8-pin jumper block, anyone knows what that is good for? - can I just plug in my camera, and check the voltage on the cable? - any other ideas? thanks robert -- Robert Lemmen http://www.semistable.com |
|
From: Stefan R. <st...@s5...> - 2011-11-08 13:12:41
|
On Nov 07 Robert Lemmen wrote:
> ok, I have found another firewire card. it says "ma-133" on it, and
> lscpi says:
>
> 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
> II(M)] IEEE 1394 OHCI Controller (rev 46)
>
> this card has two jumpers on it labeled "Internal 12V" and "External
> 12V". It also has a white 4-pin power connector.
[...]
> so:
> - is that other chip (VIA VT6306) ok?
Yes, it is. I have used VT6306 successfully with various different audio,
video, and storage devices; also with multiple devices on the bus at once.
There are some known problems though:
- Audio device aggregation by FFADO does not work on this chip. This is
a common problem of many other chips also.
- DV capture with the gstreamer DV plugin or with the dv4lstart V4L2
device emulator does not work. This is a unique problem of VT6306.
> - has anyone a similar card? what have you set your jumpers to?
I don't.
> - there is another 8-pin jumper block, anyone knows what that is good
> for?
This could be a header for a front panel breakout cable. VT6306 is a
three-port chip, so if this card has got three ports already at its back
plate, then such an internal connector would share pins with one of the
external connectors. Only one of the shared connectors can be used at a
time then, and signal quality on either connector is probably lower than
on proper port connectors. On top of that, a breakout cable or any kind
of passive extension cable would degrade the signal even more.
Many 1394 PCI cards offer an internal 1394 connector, usually in the form
of a regular 1394 6-pin socket or a 1394b 9-pin socket. Motherboards with
onboard 1394 chip and an internal 1394 port on the other hand usually offer
that internal port in the form of a pin header, looking like a jumper
block. There might be PCI cards with pin header as internal connector too.
That jumper block on your card might serve other purposes, but an internal
1394 port is IMO the most plausible explanation in case of a VT6306 based
card.
--
Stefan Richter
-=====-==-== =-== -=---
http://arcgraph.de/sr/
|
|
From: Robert L. <rob...@se...> - 2011-11-07 20:35:11
Attachments:
signature.asc
|
On Wed, Nov 02, 2011 at 02:31:01PM -0500, Carl Karsten wrote: > This is more for me than you, but it might help you.... > > If you have a 2nd firewire controller (card), plug one card into the > other and run: > > https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c > > If it finds an error, then the problem is one of the cards or cable > and probably not the camera. > > Or the program is whacked. This is something a friend wrote, I > haven't gotten around to testing it other than "it runs! great! > thanks! I'll buy you a beer!" not sure how to interpret this, but with a cable between both cards (for any combination of ports) I get: /dev/fw0: Success 234 001106005350d195 65472 65472 /dev/fw1: Invalid argument 234 0000d100802a6abc 65473 65472 /dev/fw2: Invalid argument 234 0000d100802a6abc 65473 65473 /dev/fw3: Invalid argument 234 001106005350d195 65472 65473 /dev/fw4: Invalid argument /dev/fw5: No such file or directory /dev/fw6: No such file or directory /dev/fw7: No such file or directory /dev/fw8: No such file or directory Device not found. : No such file or directory without a cable beteeen them, I get: /dev/fw0: Success 234 001106005350d195 65472 65472 /dev/fw1: Invalid argument /dev/fw2: No such file or directory 234 0000d100802a6abc 65472 65472 /dev/fw3: No such file or directory /dev/fw4: No such file or directory /dev/fw5: No such file or directory /dev/fw6: No such file or directory /dev/fw7: No such file or directory /dev/fw8: No such file or directory Device not found. : No such file or directory is that a sign for good cables and cards? thanks robert -- Robert Lemmen http://www.semistable.com |
|
From: Robert L. <rob...@se...> - 2011-11-07 20:43:30
Attachments:
signature.asc
|
On Mon, Nov 07, 2011 at 08:35:02PM +0000, Robert Lemmen wrote: > any combination of ports) I get: > > /dev/fw0: Success > 234 > 001106005350d195 65472 65472 > /dev/fw1: Invalid argument > 234 > 0000d100802a6abc 65473 65472 > /dev/fw2: Invalid argument > 234 > 0000d100802a6abc 65473 65473 > /dev/fw3: Invalid argument > 234 sorry, I copied from the wrong file. with the cable between the cards I get: dev/fw0: Success 234 0000d100802a6abc 65473 65473 /dev/fw1: Success 234 001106005350d195 65472 65472 /dev/fw2: Success 234 0000d100802a6abc 65473 65472 /dev/fw3: Success 234 001106005350d195 65472 65473 /dev/fw4: Success /dev/fw5: No such file or directory /dev/fw6: No such file or directory /dev/fw7: No such file or directory /dev/fw8: No such file or directory Device not found. : No such file or directory also, I get the same output no matter if I do "send" or "receive", and for any "guid" (whatever that is) cu robert -- Robert Lemmen http://www.semistable.com |
|
From: Carl K. <ca...@pe...> - 2011-11-07 21:59:20
|
On Mon, Nov 7, 2011 at 2:35 PM, Robert Lemmen <rob...@se...> wrote: > On Wed, Nov 02, 2011 at 02:31:01PM -0500, Carl Karsten wrote: >> This is more for me than you, but it might help you.... >> >> If you have a 2nd firewire controller (card), plug one card into the >> other and run: >> >> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c Whoops, that wasn't the one I was thinking of. That is v1, which needs to be run twice.. This is what I mean, and here is what 'good' looks like: juser@pc9e:~/fwdiag$ sudo ./async-loop-ck Main process: starting receiver Main: receiver started, pid: 2567; waiting 4 seconds... Receiver child process 2567 starting... Main process: starting sender Main: sender started, pid: 2568 Main process, waiting for child processes to finish... Sender child process 2568 starting... Received 524289389 bytes = 500.00 MB in 511745 packets in 28 seconds ...receiver finished Sent 524288119 bytes = 500.00 MB in 511753 packets in 28 seconds ...sender finished Main: processes finished -- Carl K |
|
From: Carl K. <ca...@pe...> - 2011-11-07 20:41:38
|
On Mon, Nov 7, 2011 at 2:35 PM, Robert Lemmen <rob...@se...> wrote: > On Wed, Nov 02, 2011 at 02:31:01PM -0500, Carl Karsten wrote: >> This is more for me than you, but it might help you.... >> >> If you have a 2nd firewire controller (card), plug one card into the >> other and run: >> >> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c >> >> If it finds an error, then the problem is one of the cards or cable >> and probably not the camera. >> >> Or the program is whacked. This is something a friend wrote, I >> haven't gotten around to testing it other than "it runs! great! >> thanks! I'll buy you a beer!" > > not sure how to interpret this, but with a cable between both cards (for > any combination of ports) I get: > > /dev/fw0: Success > 234 > 001106005350d195 65472 65472 > /dev/fw1: Invalid argument > 234 > 0000d100802a6abc 65473 65472 > /dev/fw2: Invalid argument > 234 > 0000d100802a6abc 65473 65473 > /dev/fw3: Invalid argument > 234 > 001106005350d195 65472 65473 > /dev/fw4: Invalid argument > /dev/fw5: No such file or directory > /dev/fw6: No such file or directory > /dev/fw7: No such file or directory > /dev/fw8: No such file or directory > Device not found. > : No such file or directory > > without a cable beteeen them, I get: > > /dev/fw0: Success > 234 > 001106005350d195 65472 65472 > /dev/fw1: Invalid argument > /dev/fw2: No such file or directory > 234 > 0000d100802a6abc 65472 65472 > /dev/fw3: No such file or directory > /dev/fw4: No such file or directory > /dev/fw5: No such file or directory > /dev/fw6: No such file or directory > /dev/fw7: No such file or directory > /dev/fw8: No such file or directory > Device not found. > : No such file or directory > > is that a sign for good cables and cards? Not really. I have not had a chance to run in on known bad hardware to verify it actually reports an error. If it reported an error, then there would be a clue what to look at. But... looking at the output makes me wonder if it is detecting 2 cards. I can at least see what happens if it I run it with only 1 card. I should be able to do that today. -- Carl K |
|
From: Robert L. <rob...@se...> - 2011-11-07 20:47:57
Attachments:
signature.asc
|
On Mon, Nov 07, 2011 at 02:41:10PM -0600, Carl Karsten wrote: > But... looking at the output makes me wonder if it is detecting 2 > cards. I can at least see what happens if it I run it with only 1 > card. I should be able to do that today. I think it does, at least it goes through "fw0" to "fw3" with two cards, with one (or without a cable) it doesn't cu robert -- Robert Lemmen http://www.semistable.com |
|
From: Robert L. <rob...@se...> - 2011-11-07 20:50:05
Attachments:
signature.asc
|
hi folks, not sure that means anyting, but if i do my modprobe with debug=8 rather than debug=7 (no idea what any of this exactly means), then plugging in my camera floods the dmesg with bus reset messages: [ 361.873332] firewire_ohci: IRQ 00020000 busReset [ 361.873340] firewire_ohci: IRQ 00020000 busReset [ 361.873349] firewire_ohci: IRQ 00020000 busReset [ 361.873357] firewire_ohci: IRQ 00020000 busReset [ 361.873366] firewire_ohci: IRQ 00020000 busReset [ 361.873374] firewire_ohci: IRQ 00020000 busReset that can't be right at such a high rate! cu robert -- Robert Lemmen http://www.semistable.com |
|
From: Stefan R. <st...@s5...> - 2011-11-07 21:29:11
|
On Nov 07 Robert Lemmen wrote: > not sure that means anyting, but if i do my modprobe with debug=8 rather > than debug=7 (no idea what any of this exactly means), then plugging in > my camera floods the dmesg with bus reset messages: > > [ 361.873332] firewire_ohci: IRQ 00020000 busReset > [ 361.873340] firewire_ohci: IRQ 00020000 busReset > [ 361.873349] firewire_ohci: IRQ 00020000 busReset > [ 361.873357] firewire_ohci: IRQ 00020000 busReset > [ 361.873366] firewire_ohci: IRQ 00020000 busReset > [ 361.873374] firewire_ohci: IRQ 00020000 busReset > > that can't be right at such a high rate! debug=7 actually means debug=1+2+4, meaning it should log (1) asynchronous packet transmit and receive events, (2) self-ID-complete events with self-ID packet contents, (4) any interrupt events from the set of interrupt types that the driver normally receives. debug=8 means that the driver shall activate reception of bus reset interrupts in addition to the set of the other interrupt event types and log them. (Normally the driver is not interested in getting bus reset IRQs. We only want to know when a bus reset is over and the bus is back in normal operation again --- and for that purpose we receive self-ID-complete IRQs.) Old 1394-1995 hardware used to react with a short burst of bus resets every time when something was plugged in to or out of a bus, and this burst was followed by a self-ID-complete event. With 1394a-2000/ 1394b-2002/ 1394-2008 compliant hardware, you typically get just one, maybe two bus resets and then a self-ID-complete event. By means of the self-ID-complete IRQ, the chip signals to the driver that transmission and reception of self-identification packets by all nodes right after bus reset and automatic enumeration of all nodes. (Unlike old parallel SCSI where node IDs where configured by the user, typically with small jumper switches at the back panel of each device, 1394 node IDs are re-negotiated between all devices at each bus reset.) The self-ID packets carry node IDs, how many ports each node has, parent--child connection relationships of all ports, and more. The fact that you receive boatloads of bus reset events but never a self-ID-complete event with the camera means that the camera is defective (since you checked the card and the cable, and you apparently also ruled out bus power as the problem source). -- Stefan Richter -=====-==-== =-== --=== http://arcgraph.de/sr/ |
|
From: Stefan R. <st...@s5...> - 2011-11-07 21:45:19
|
On Nov 07 Stefan Richter wrote: > Old 1394-1995 hardware used to react with a short burst of bus resets every > time when something was plugged in to or out of a bus, and this burst was > followed by a self-ID-complete event. With 1394a-2000/ 1394b-2002/ > 1394-2008 compliant hardware, you typically get just one, maybe two bus > resets and then a self-ID-complete event. PS, for completeness: Briefly after this, there is often another pair of bus reset and self-ID-complete. This is when a bus manager software, e.g. the Linux driver, reconfigures the bus with better asynchronous arbitration gap settings or selected a different root node to ensure proper isochronous arbitration. Or/ and there may be another pair of bus reset and self-ID-complete when a newly switched-on node finished its boot sequence and signals to the rest of the bus that its higher functions are now ready for access. (Just to describe what kind of events should normally be seen; obviously that's not at all happening with your camera.) -- Stefan Richter -=====-==-== =-== --=== http://arcgraph.de/sr/ |
|
From: Robert L. <rob...@se...> - 2011-11-07 21:52:32
Attachments:
signature.asc
|
On Mon, Nov 07, 2011 at 10:29:00PM +0100, Stefan Richter wrote: > The fact that you receive boatloads of bus reset events but never a > self-ID-complete event with the camera means that the camera is defective > (since you checked the card and the cable, and you apparently also ruled > out bus power as the problem source). great, thanks for the explanation! would you think that bus power could also lead to these constant bus resets? I am asking because I still hope it is something with bus power rather than a broken camera. I'm still hunting for a pci card that has known working bus power. the one I have claims so, but the jumpers that I don't know what they are good for etc makes me wonder... can I just check for bus power by looking at voltage/power on the cable? Or is this intelligently managed in the sense that the power is only available if the device asks for it? If I could just check for 12V at a given power draw on the cable, then that would be the easiest way to check for bus power... thanks robert -- Robert Lemmen http://www.semistable.com |
|
From: Stefan R. <st...@s5...> - 2011-11-08 06:54:30
|
On Nov 07 Robert Lemmen wrote: > would you think that bus power could > also lead to these constant bus resets? Yes, insufficient or unstable bus power could do that. > I am asking because I still hope > it is something with bus power rather than a broken camera. I'm still > hunting for a pci card that has known working bus power. the one I have > claims so, but the jumpers that I don't know what they are good for etc > makes me wonder... > > can I just check for bus power by looking at voltage/power on the cable? I think yes, if you measure with power consumer (e.g. camera) connected. I am not sure though at which frequency you need to be able to measure in order to determine that bus power is stable enough for the camera. > Or is this intelligently managed in the sense that the power is only > available if the device asks for it? Bus power is always there if there is a power provider on the bus. It is the other way around: A power management software could control power draw of consumers which support respective management functions. -- Stefan Richter -=====-==-== =-== -=--- http://arcgraph.de/sr/ |
Thanks for helping keep SourceForge clean.
X