That is an interesting point. These camera nodes are a port from QNX4
to QNX6 (4-5 years ago) and they primarily are used for dealing with
camera data. There is some processing for messaage passing via a
network for image ID so we know where each image was taken and
where, but if is very small amount (< 200 bytes per image)
When I intially used this wrote this application, threads were new to
me. I have not done much with the priortity but I did change the
prioritiests of some tasks. The systesm smiply is set up to:
1 get an image from a camera (in IIDC that would be a full frame)
2. compress image to JPEG
3. Strore to Disk
4. inbackground get some data from a Control node compter on what to
name the image file. There is a handsaking mechanism in place that
prevents images being taken while we are busy preocssing an image.
5. Display some data to screen on the status of what is going on
(minimal) Images are only displayed on command by operator)
This takes about 350-450 ms per image depending on computer hardware
used. When we push the system faster than 450 ms we get more missing
images and the more we push it the more we get.
I will look at these priorites and run more tests. In our non IIDC
firewire design we have, we can push the systems and the image will
be taken at the maximum allowable speed and there will be no missing
images ( This systesm misses about 1 in 30K images) The only draw
back is the image spacing will become longer for our app.
Greg.
With our FireWire camera driver, we can take images at
640 x 480 x 24bits x 15FPS and use only about 5% of a Pentium IV.
This is with the camera in isochronous mode.
If you’re losing frames, you’re doing something wrong.
Our driver is open source (GPL), runs on QNX, but requires
the Mindready LLA.
Manual page:
http://www.overbot.com/public/devfw-ohci.html
Source code:
http://www.overbot.com/public/qnx/
We’d really like to see the LLA dependency removed.
The OHCI chip interface is fully documented and
standardized. Download it here:
ftp://download.intel.com/technology/1394/download/ohci_11.pdf
There are existing Linux drivers. So it’s not that hard to write a
replacement for the Mindready LLA.
So who’s going to do it?
John Nagle
Team Overbot
glorvets wrote:
That is an interesting point. These camera nodes are a port from QNX4
to QNX6 (4-5 years ago) and they primarily are used for dealing with
camera data. There is some processing for messaage passing via a
network for image ID so we know where each image was taken and
where, but if is very small amount (< 200 bytes per image)
When I intially used this wrote this application, threads were new to
me. I have not done much with the priortity but I did change the
prioritiests of some tasks. The systesm smiply is set up to:
1 get an image from a camera (in IIDC that would be a full frame)
2. compress image to JPEG
3. Strore to Disk
4. inbackground get some data from a Control node compter on what to
name the image file. There is a handsaking mechanism in place that
prevents images being taken while we are busy preocssing an image.
5. Display some data to screen on the status of what is going on
(minimal) Images are only displayed on command by operator)
This takes about 350-450 ms per image depending on computer hardware
used. When we push the system faster than 450 ms we get more missing
images and the more we push it the more we get.
I will look at these priorites and run more tests. In our non IIDC
firewire design we have, we can push the systems and the image will
be taken at the maximum allowable speed and there will be no missing
images ( This systesm misses about 1 in 30K images) The only draw
back is the image spacing will become longer for our app.
Greg.
I suggest you to contact MindReady technical support. They can
provide you the code to change the stack’s priority. If you have the
same problem we had, changing the priority of your threads in your
program won’t be enough. You may check the disk driver priority for
example…
John
I have down loaded that code and have yet to try it out. I plan on
trying it. After I exhaust the IIDC play. I have contacted Mindready
and we are starting to bring them up to speed on this problem. It
will be alott of work for each camera we use. using the LLA.
I have my own driver using the LLA for using sony cameras that is
several years old that works just as your does in Iso mode and does
not miss any images. We are not just taking images but also
compressing and storing them to in real time. Both my ISo driver and
the IIDC does that for all the 1.4 and 2 mega pixels cameas we are
using. Yes we may be doing something wrong but that is perhaps using
the mindready IIDC SDK. I am looking for a good solution as you are
and sugestions on the IIDC probelm at hand. one probelem at a time.
we are looking at the IIDC Mindready product for a specific case using
an external trigger mode and missing an image every one in a hundred.
I.e I trigger the camera and for some reason the IIDC code does not
give me a frame? and I get a missing image. We have been getting this
probelm on both Basler A102Fc and redlake Es-2001 cameras.
I have begun to look at the priorites of the disk and IIDC drivers and
they are both set at 10. Are you saying to set one higher than the
other. I have 4 threads set to 10, 10, 18, 21. I think I set the
cameras functions the same as the disk and IIDC server.
Any sugesstions?
Greg,
Greg, you may try to change the priority of all threads in the process
“iidcDrv-srv”.
Priority 22 should be 24
Priority 21 should be 23
Priority 20 should be 22
It’s not very easy to change. MNY will give you the code.
stremblay wrote:
Greg, you may try to change the priority of all threads in the process
“iidcDrv-srv”.
Priority 22 should be 24
Priority 21 should be 23
Priority 20 should be 22
It’s not very easy to change. MNY will give you the code.
It’s easy to change at the LLA level. Take a look at lines 87-88 in
fwadapter.cpp in our driver.
John Nagle
Team Overbot
Thanks all,
I have isolated our bug and it may be the thread priorties. I have
an support order started with MNY and should here something back
after a minor code dump.
In a nutshell we have a dedicated thread that changes the gain as part
of a automatic gain control S/W circuit. When I diable the AGC the
systesm does not miss a beat and takes images with out missing any or
generating a reset. but when I change the gain near max triggered
frameirate our set_gain function generates an IIDCERR-FEATUREID Error
using
retValue = iidc_setfeature(camHandleArray[selectedCam] ,
&feature_s, sizeof(feature_s));
if (retValue == 0)
{
/* An error occured */
proccessError(selectedCam);
printf(" DCAM_SetGain error detected:\n");
return;
}
It only does this less than 1% of the time.
Greg,