gmane.comp.multimedia.libdc1394.devel

Re: libdc1394 + Point Grey Chameleon USB2.0 + Raspberry Pi

Antoine Villeret — 2013-05-08T12:20:05

hi,

I  had lots of issues with USB and Ethernet on the Pi
did you use Ethernet ?
if not, you could try to disable it,
if yes, you could at least disable turbo mode
see http://wiki.linuxaudio.org/wiki/raspberrypi

hope this helps

kind regards

antoine

--
do it yourself
http://antoine.villeret.free.fr


2013/5/7 Eric Gratorp <erigr222-oe7qfRrRQfdIcsJQ0EH25Q< at >public.gmane.org>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________
Mailing list for libdc1394-devel
libdc1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

libdc1394 + Point Grey Chameleon USB2.0 + Raspberry Pi

Eric Gratorp — 2013-05-07T12:39:13

Greetings,

Im currently trying to capture video from the Pt Grey camera using the
coriander GUI on my Raspberry Pi which runs on a Debian distribution.
Coriander recognizes the that the camera is connected to the USB.

I have:

libdc1394
Version: 2.2.0-2


libusb
Version: 2:1.0.11-1

When I try to display the video stream with coriander I get these errors:

/* start log */

libdc1394 error: Generic failure: in dc1394_video_get_transmission
(control.c, line 965): Could not get ISO status

libdc1394 error: Generic failure: in dc1394_video_get_mode (control.c, line
663): Could not get video format

/* end log */

When this occurs I need to remove my camera and then plug it back in to be
able to start coriander again. I have tried the different video modes and
data rates under services -> receive.

I also receive these errors when trying to capture a frame without the GUI.

/* start log */

libdc1394 error: usb: Bulk transfer 0 failed with code 1
libdc1394 error: Generic failure: in main (grab_sequence.c, line

Re: image timestamp

Johann Schoonees — 2013-05-06T03:41:49

The timestamp is the time the last packet is received into a DMA buffer.
  If you want to know the time of the start of integration, you have to
work backwards through the transmission time etc. as described in the FAQ.

There are some tools that can help characterize you camera's lag times
(e.g. Camwire's example program measureconf_1394.c
http://kauri.auck.irl.cri.nz/~johanns/camwire/ ) by connecting the
external trigger to your PC's serial port.

Our experience is that timestamps are indeed accurate to within the 125
microsecond bus cycle time.  Or in other words, the unix system time is
accurate enough for the timestamp resolution to be dominated by the
Firewire bus period.

________________________________

This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the inte

Re: image timestamp

Damien Douxchamps — 2013-05-05T15:00:06

Hello Roger,

On Fri, 2013-05-03 at 08:18 +0200, Roger Oberholtzer wrote: 

The timestamp provided by libdc is indeed the time the frame arrived in
the host PC. It's simply the unix time expressed in microseconds. The
FAQ has a couple of lines about this:

http://damien.douxchamps.net/ieee1394/libdc1394/faq/#Can_I_find_out_exactly_when_a_frame_was_acquired

If you need more accuracy I can suggest two options:

- Some cameras can embed 1394-bus timestamps (aka cycle timer) in the
image data. That will give you an accuracy of 125us at best, and you
will still have to sync that with your system clock. But if you have
several cameras on a single bus you can use this data to compare their
relative capture times.

- Use an external trigger signal, which could be wired from one of your
other sensors.



Damien

image timestamp

Roger Oberholtzer — 2013-05-03T06:18:03

I am curious what the most 'accurate' time stamp is that is available
for FireWire images captured in Linux. All the data we collect in our
acquisition system are time tagged with the local time (millisecond
resolution). We would like to do the same with FireWire images. Since
the cameras are not time synchronized with the PC, I am guessing that
the time stamp that is available is when the image arrived in the PC.
How best to access this information for images captured via 

dc1394_capture_dequeue(cam, DC1394_CAPTURE_POLICY_WAIT, &capture)


Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer< at >ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se



------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed f

Re: Occasional DC1394_NO_ISO_CHANNEL

Roger Oberholtzer — 2013-05-03T06:09:16

Based on new findings, the current retry of 300 seems more than enough:

Our initial attempt was to increase the sleep after a failed ioctl() to
1000 µsecs, and to add a delay of 1000 µsecs before the ioctl(). As
reported, this seems not to help.

So, we increased the delays to 5000 µsecs. In the tested systems, this
had a big positive effect. We are now testing this in more problem
systems.

I do not really like the long pauses here. But it does seem to have an
effect. From the way the status messages are printed, it seems that the
delay before the ioctl() is the one leading to the improvement. We do
not get log messages that the command timed out, and so the usleep after
the ioctl() seems not to be done. When we are certain that the two long
delays have the effect we need, we will then try to see which of the
changes is leading to the improvement.

--
Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer< at >ramboll.se
______

Re: can not use max bandwidth in format 7

E Chalaron — 2013-04-28T21:03:34

Same problem with a Stingray
E

On 24/10/12 05:22, Falko Kellner wrote:


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: Occasional DC1394_NO_ISO_CHANNEL

Roger Oberholtzer — 2013-04-25T06:06:54


I can do this. But the commands that fail are after commands that work.
So the camera is basically responsive. I did increase the delay before
and after the ioctl() that communicate. Those were added based on the
error message printed by the library.I hope these added delays are
really happening at the correct place...

I should probably update the subject of this thread as it is not just
that error that occurs...


Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer< at >ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with jus

Re: Occasional DC1394_NO_ISO_CHANNEL

David Moore — 2013-04-25T05:49:20

You could also try increasing the value of DC1394_MAX_RETRIES. Make it
really big, say 10000. This is used in the do_transaction() loop.

I recall I had a Sony camera once that would sometimes take many seconds to
become responsive.

-David


On Wed, Apr 24, 2013 at 10:21 PM, Roger Oberholtzer <roger-x1DU6litPwk< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr_______________________________________________
Mailing list for libdc1394-devel
libdc1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

Re: Occasional DC1394_NO_ISO_CHANNEL

Roger Oberholtzer — 2013-04-25T05:21:23


I have made a smaller application that does pretty much what the bigger
app does. This is a single thread that just opens a camera and reads
images it also fails in the exact same way.

The frustrating thing is that it is inconsistent, Different functions at
different times. The only commonality is that it arrives when we started
using the juju interface, I have been over the docs a zillion times and
cannot see where I could have made a mistake porting our old code to the
new API.But that must be it.

The natives in these parts are getting restless...


Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer< at >ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based applica

Re: Occasional DC1394_NO_ISO_CHANNEL

Stefan Richter — 2013-04-23T17:50:00

[...]

Call me crazy, but... what if there is a memory corruption causing all
this?

In your application, make sure that only one thread at a time manipulates
libdc1394 internal state.  Either you have just one thread, or only let
one thread see libdc1394 state at the whole time, or serialize properly
with some sort of lock.

Also watch out for memory-corrupting application bugs; e.g. run it with
valgrind's memory checker or something like that.

And of course watch out for kernel-internal memory corrupting bugs.  One
measure of doing so would be to not load any third-party kernel module.

(Sorry in case that some info from earlier in this thread already
precluded what I am suggesting here; this discussion collected already
quite a bit of backlog...  Besides, userspace programming is not my field
of specialization, so I may very well be talking nonsense.)

Re: Occasional DC1394_NO_ISO_CHANNEL

Roger Oberholtzer — 2013-04-23T14:47:33

Sorry for taking so long to reply. We have spent a bit of time fiddling
with cameras, cables, interface cards and motherboard slots to see if we
could find a pattern to our problem. We have not found any pattern.
Except that the hardware worked previous to the juju generation of
library.

After turning on debugging, and having added said delays, I see this
when there is a failure:

libdc1394 error: juju: Max retries for tcode 0x4, offset f00404
libdc1394 error: Generic failure: in dc1394_feature_is_present (control.c, line 1318): Could not get register for feature
libdc1394 error: Generic failure: in dc1394_feature_get (control.c, line 235): Could not check feature presence
libdc1394 error: Generic failure: in dc1394_feature_get_all (control.c, line 210): Could not get camera feature

I have tried the suggested delay increase, as well as adding the delay
before the ioctl() in do_transaction. We do not feel it makes a
difference. The failure seems to be roughly one in 5 times the app
starts and the library i

(OT) What about a USB3 Vision Lib

Mark — 2013-03-18T17:35:47

Hello,

sorry if this is a bit off topic here…

Has someone taken a look at the recently published USB3 Vision standard?  

Basler and Matrix VIsion seem to have first cameras implementing the new standard. I contacted Ximea today - their cameras currently implement a custom protocol, but a new USB3 Vision Firmware should be ready in a few weeks. AVT is readying some USB3 Vision cameras, but I have no release date yet. 

The spec is not overly complex, register reading and writing uses GenCP. Most camera vendors provide higher level libraries for Windows, some for Linux. Only Ximea has a beta Mac driver (but it really is beta…lots of bugs). 

An open source USB3 Vision Lib could be quite useful. Anyone interested in such a project?

PS: interestingly, USB3 Vision devices can optionally implement IIDC2. See chapter 4.2.2.11. I don't really see the point of it - I guess that was PTGreys idea since they are offering USB3 Cameras implementing IIDC already.

Regards
mark
 



---------------------------------

Re: Occasional DC1394_NO_ISO_CHANNEL

Roger Oberholtzer — 2013-03-15T15:35:36

I will have to fiddle with that.

It is interesting that once it fails for a feature, it seems to stay
failed for that feature until the next time the feature is accessed.
Like if the recovery after the failure in a single call is not properly
cleared. At least it feels that way.


Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer< at >ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Mailing list for libdc1394-devel
libdc1394-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

Re: Occasional DC1394_NO_ISO_CHANNEL

Stefan Richter — 2013-03-14T15:12:19

Seeing the "ack_busy_X" lines in Roger's logs I was about to suggest a
retry loop.  But you already have one...  (Actually, when a transaction
terminates with ack_busy_X, the OHCI-1394 link did already send a few
retries, observing a certain retry protocol.  Of course sometimes these
transparent hardware retries are not enough.)

We added a similar software retry loop in libraw1394 not too long ago:
http://git.kernel.org/cgit/libs/ieee1394/libraw1394.git/commit/?id=8e433bf58413725365654c27fb4fad0aad88b516
This was found necessary for a few old consumer-grade camcorders.  These
ones already exhibited intermittent ack-busy failures with older linux1394
based kernels, but back then these failures were rare enough to remain
largely unnoticed.  With the switch to the juju kernel drivers, these
failures became much more frequent, to a degree to make these camcorders
entirely inaccessible.  Perhaps the reason was lower transaction handling
overhead in juju compared to linux1394.

Because the special issue with the

Re: Occasional DC1394_NO_ISO_CHANNEL

Damien Douxchamps — 2013-03-14T13:53:53

On Wed, 2013-03-13 at 09:32 -0700, David Moore wrote: 

Easy fix, thanks Stephan.
Committed to the git repo.
Tested with 2.6.32.

Re: Occasional DC1394_NO_ISO_CHANNEL

Damien Douxchamps — 2013-03-14T13:14:36

Hello Roger,

On Thu, 2013-03-14 at 11:26 +0100, Roger Oberholtzer wrote: 

When a register read or write fails, libdc will retry a few times. In
juju this is set to 300 (!) times (this a little bug, it should be
DC1394_MAX_RETRIES, not 300). A short usleep of 20+/-10us is inserted in
the loop, hence the delay. See do_transaction() in juju/control.c (line
376~)

If you enable logging of debug messages in libdc1394 you should see a
lot of messages like "juju: retry rcode XXX tcode XXX offset".

Re: Occasional DC1394_NO_ISO_CHANNEL

Roger Oberholtzer — 2013-03-14T11:22:35

When there are errors, I see lines like this in the /var/log/messages:

Mar 14 12:18:39 rst7 kernel: [10452.813747] firewire_ohci: AT spd 2 tl 04, ffc1 -> ffc0, ack_busy_X, QW req, fffff0f00608 = 40000000

ack_busy_X seems to appear. Other than that, my untrained eye does not
see a difference in the log.


Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer< at >ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Mailing list for libdc1394-devel
libdc1394-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

Re: Occasional DC1394_NO_ISO_CHANNEL

Roger Oberholtzer — 2013-03-14T10:26:39


I see that when it fails, there is a bit of a delay. Then the error
message gets printed. When it does not fail for a feature, the function
returns quicker. Not sure if that is useful.



Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer< at >ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Mailing list for libdc1394-devel
libdc1394-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

Re: Occasional DC1394_NO_ISO_CHANNEL

Roger Oberholtzer — 2013-03-14T10:12:57

I have taken away resetting the bus and camera. The problem persists.
Intermittent errors getting/setting random features. Sometimes when I
call dc1394_feature_get_all I get DC1394_FAILURE. If I immediately call
it again, it is happy. When it fails, it prints:

libdc1394 error: Generic failure: in dc1394_feature_get (control.c, line 287): Could not get feature register

libdc1394 error: Generic failure: in dc1394_feature_get_all (control.c, line 210): Could not get camera feature




Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer< at >ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___

Re: Occasional DC1394_NO_ISO_CHANNEL

Stefan Richter — 2013-03-14T09:28:46

Application code should generally not request bus resets.  Bus resets
should be reserved to those caused by hardware (topology changes),
firmware (device functions coming online or going offline), and bus
management functionality (implemented in the kernel).


Yes, you better should wait at least after the bus reset.  Or best, don't
reset the bus at all.  (I don't know whether waiting is required after the
camera reset.)

First of all, the kernel call behind dc1394_rest_bus() is non-blocking:
It merely schedules a bus reset but does not wait for it to happen before
return of the kernel call.  Among else the kernel makes sure that such a
bus reset is deferred until at least 2 seconds after the last bus reset
event.  This is required so that various protocols are able to perform
their reconnection procedures after each bus reset.  Furthermore, because
there are a few other occasions at which kernelspace or userspace software
directly or indirectly causes a software-requested bus reset, the kernel
tries to fol