Development

This is an artificial exception and there are exception handlers in the UB1394.DLL code that know how to handle it.  In Visual Studio 2005, the message will look like the one below:

Pressing “Ignore” you will get the evaluation dialog that prompts you to enter some letters:

In order to avoid this message you must press “Continue” at the first dialog.

You can set Visual Studio 2005 to always react this way to the specific “First-chance” exception, through the “Exceptions” dialog from the “Debug” menu. In the exceptions dialog, you must uncheck the box next to “c0000008 An invalid handle was specified”:

Visual C++ 6 can also be set that way, through the exceptions dialog from the “Debug” menu. The “c0000008 Invalide Handle” should be set to “Stop if not handled”:

From within an Explorer window, select the executable file in question, right-click on it and select “Properties”. Either use the mouse or press CTRL+TAB to switch to the “Version” tab. This tab contains all the version information related to an executable. The string listed to the right of “File Version” is the executable version number. The executable of the FireAPI™ drivers are located in %WINDIR%SYSTEM32DRIVERS, except for UB1394.DLL which is in %WINDIR%SYSTEM32. Alternatively you can execute the version command on the FireCommander.

In general the size of debug executables is quite large (usually more than twice as large than the release executable). However you can also find this information by opening the properties page of the executable, switching to the Version tab and then viewing the “Build Type” entry in the “Other Version Information” listbox. Also in the same tab, the “Description” field, under the version number, contains the string “(DBG)” in the debug drivers.

The are various Freeware and commercial tools available in the market that allow capturing of the messages printed in the debug output. One of the best and most recomended utitlities that can handle such a task is DebugViewer provided free of charge by www.sysinternals.com.

When a FireAPI™ funtion fails a ton of debug messages are printed into the debug output. It is recommended that the user has the debug version of the ubCore drivers installed when doing developement and that he captures all the debug messages while running his application. The debug log messages will usually give the user a clue about why his application is failing but will be also be of invaluable help to the FireAPI™ support team when assisting the user.

Since version 4.0 the ubCore drivers have become bus manager and power management capable. Devices connected to the a 1394 adapter using the ubCore drivers are automaticaly enumerated in the system and presented in the Windows Device Manager. A plug’n play device driver can be developed for each device thus integrating it with the system. Unibrain has already developed a set of such client drivers for devices like IIDC 1394 cameras, DV camcorders and SPB2 external storage devices which cover the majority of the available 1394 devices in the market. Those drivers are available to the user through the installation of the ubCore Driver Suite.

Nothing! You application will work with the latest version of the plug’n play ubCore drivers without any changes at all. In fact you might not even need to recompile your application in most cases.

FireAPI™ includes the full source code of Fire-i DLL which is a C style DLL based on the user mode version of FireAPI™. Fire-i DLL provides a simple and robust interface that allows 1394 camera enumeration control and preview in a few lines of code. The source code of the Fire-i DLL as well as full documentation and a multitude of source samples can be found in the IIDC folder of the FireAPI™ samples directory. FireAPI™ also provides a WDM compliant IIDC camera driver that can be used along with the generic DirectShow SDK in order to perform basic camera control and preview tasks. Unibrain also provides a more complete and dedicated 1394 camera SDK called Fire-iAPI™.

OHCI 1394 adapters allow only quad reads in the configuration ROM. You are probably trying to perform block reads and that is why the ReadNode function is failing. Try reading the config ROM 4 butes at a time.

Broadcasts are always sent at the speed of the slowest device on the bus, so that all nodes can receive it. If you have a device attached on the bus, that operates at 100Mbps (for example a digital mini-camera) then you will only be able to send broadcast packets of maximum size 512 bytes. The same is true when you have a 200Mbps device on a bus with all 400Mbps nodes. In that case the maximum broadcast packet size would be 1024 bytes.

C1394Read/Write/LockNode() API functions automatically set the transmission speed bwtween two nodes to the maximum possible value. In order to set the transmission speed manually you should use the C1394TransmitPackets() function.

Read transactions on that address space are acknowledged with ACK_PENDING by the adapter. For write transactions, the default behaviour is to acknowledge the reception of the packet as soon as the packet arrives with ACK_COMPLETE and in doing so eliminating the need to send a response packet, resulting in much faster transaction. So when we have a Read transaction the following packets are send : Read Request (from the client) Acknowledgment with ACK_PENDING (from the server) Read Response (from the server) Acknowledgment with ACK_COMPLETE (from the client)when we have a write transaction the default behavior is: Write Request (from the client) Acknowledgment with ACK_COMPLETE (from the server)The last sequence is called “Unified transaction” (for more information about “unified transactions” check the IEEE1394-1995 spec. paragraphs 3.6.2.1 & 7.3.2.1).

The most probable reason is a FIFO overrun/underrun problem. Try setting FIFO’s isochronous receive memory to a bigger value, using the FIFO command on the FireCommander or the C1394SetInformation() API function.

Note: If you use an OHCI board then it’s not possible to change FIFO settings. For a more detailed explanation of the DMA Error please refer to this White Paper in this link. For more info on DMA Error click here.

You will have to link the resulting driver with 1394Initialize.obj which is located inside the FIREAPISRCLIB directory. This is the OBJ containing the code of C1394Initialize for kernel mode drivers. The UBSBM sample project demonstrates how to do this for a project built with BUILD.EXE. That project can be compiled from within VC++ without any problems.Note: In order to link with C1394Initialize.obj, you have both to specify the name of the file, AND specify its path in the library search paths, otherwise the linker will not be able to locate the file. In general even if you work from within the IDE, it is best to compile your drivers with the BUILD utility using some sort of batch file like the DDKBUILD.BAT included with UBSBM.

You should perform an installation of ubCore using the switch ‘/r’ in order to produce a setup.iss file that is created in the windows folder.
Then you should place the installation executable and the setup.iss file in the same folder.
Running the installation with the ‘/s’ switch, the setup will start in silent mode.
Please notice that if you install ubCore drivers in silent mode the user does not get prompted to restart the system. You should prompt the user for a restart through your software’s installation setup.

You should perform an installation of ubCore using the switch ‘/r’ in order to produce a setup.iss file that is created in the windows folder.
Then you should place the installation executable and the setup.iss file in the same folder.
Running the installation with the ‘/s’ switch, the setup will start in silent mode.
Please notice that if you install ubCore drivers in silent mode the user does not get prompted to restart the system. You should prompt the user for a restart through your software’s installation setup.

At first you should get the latest version of our Fire-iAPI SDK, 3.70.

Concerning the latest version of DirectX SDK, November 2007, you cannot use it, as dxtrans.h is missing and you will not be able to complile our samples. You should use the August 2007 version instead, that you can download from the following location:
http://www.microsoft.com/downloads/details.aspx?FamilyID=529f03be-1339-48c4-bd5a-8506e5acf571&DisplayLang=en

You can download the latest version of the Platform SDK “Windows SDK for Windows Server 2008 and .NET Framework 3.5” from the following location:
http://www.microsoft.com/downloads/details.aspx?FamilyId=F26B1AA4-741A-433A-9BE5-FA919850BDBF&displaylang=en

You should set the paths of VS2005, as illustrated below:

Win32 Platform Include files

(The first entry is the path of the sample BaseClasses of the Platform SDK, e.g.
D:Program FilesMicrosoft SDKsWindowsv6.1SamplesMultimediaDirectShowBaseClasses)

Win32 Platform Library files

x64 Platform Include files

(The second entry is the path of the sample BaseClasses of the Platform SDK, e.g.
D:Program FilesMicrosoft SDKsWindowsv6.1SamplesMultimediaDirectShowBaseClasses)

x64 Platform Library files

NO. Fire-iAPI™ is a development kit ONLY for 1394 Digital Cameras, that implement the 1394-based Digital Camera Specification (version 1.20 and up) of the 1394 Trade Association.

Fire-i provides 2 different platforms to the user that can be used for 1394 camera application developement. The first platform is a C style DLL called Fire-i DLL which offers a simple and robust interface that allows full camera enumeration, control and preview. Fire-i DLL comunicates directly with the ubCore 1394 adapter drivers bypassing this way any additional driver layers. The other platform that can be used is a camera class that uses the Microsoft DirectShow SDK along with the Fire-i WDM IIDC 1394 camera driver in order to provide full camera control. The class provides functionality for video capture using various system installed codecs, for TCP streaming of video data over the internet and much more since it has the ability to use all available DirectShow components. A managed wrapper is also available for this class so that it can be used with managed languages such as C# and VB.net.

In order to locate and open camera handles for the second bus, you should use the extended version of the functions, FiLocateCamerasEx() and FiOpenCameraHandleEx(). As long as you have a handle to a camera then it makes no difference on which bus it is located.

1394 Digital Cameras transmit data on YUV format. This is NOT RGB compatible so the proper convention should be applied, so that the data are displayed correctly on screen.

Controlling a camera and receiving/displaying frames on the screen are two completely different tasks that must run concurrently. So they must be implemented and executed as two different processes or threads.

First of all you should find out the offset of the register. When you know the complete address of the register you should use FiQuery/SetCameraRegisterEx() to access it. When you use this function, you should take into consideration Endianess. Refer to the manual for more details.

The camera has already transmitted the frame, before setting up the isochronous engine. In order to avoid this you should start the isochronous engine prior to ordering the camera to transmit the frame.

Are you sure that your video card supports hardware overlay. Find out if it does prior to blaming the software!!! Many older video cards do not support hardware overlay.

The problem is due to the incompatibility of headers between different versions of Microsoft’s Platform SDK. Older headers contained SetWindowLong, GetWindowLong and GWL_USERDATA instead of SetWindowLongPtr, GetWindowLongPtr and GWLP_USERDATA respectively. We preferred to use the latter, because it is compatible with both the 32-bit and 64-bit versions of Windows. To solve this problem just change each occurrence of SetWindowLongPtr, GetWindowLongPtr and GWLP_USERDATA with SetWindowLong, GetWindowLong and GWL_USERDATA respectively.

This application tries to set the cameras to Format 0, Mode 1, 30 fps (320×240 YUV 4:2:2). If the camera does not support this mode, then the application just fails and no image is displayed.

The FIREi_CAMERA_FRAME struct, passed to FiGetNextCompleteFrame, has a pointer to the frame’s raw YUV data transmitted by the camera (the struct member pCameraFrameBuffer). This struct also provides information about the size of the frame buffer and the dimensions of the frame. You can convert this data from YUV to RGB using the function FiYuv2Rgb. CAUTION: Successive calls to FiGetNextCompleteFrame for the same isoch engine can use the same frame buffer.

Format_7 is a scalable size, user defined, not-compressed format that is defined in the 1394 camera spec. and supported by some 1394 cameras. In this format the camera gives you the ability to choose the dimensions of the image being captured. Of cource you don’t have unlimited choices of size (the choices depend on camera model).
Fire-iAPI™ v.2.0 and later supports Format 7.

Although this would seem like a working solution (meaning that eventually a frame would be captured and returned from each call), depending on the timing with which the frames are transmitted on the bus(when a frame starts to get transmitted and when it ends)you would probably lose frames without any real reason (normal reasons for losing a frame are, a received bad frame or high CPU usage). The problem is that a single thread can only issue one call to FiGetNextCompleteFrame at a time and then gets blocked untill that frame arrives. The solution to this is to start more than one threads for receiving, one for each transmitting camera, and issue one call to FiGetNextCompleteFrame from each of these threads so that each would wait for a frame independantly from the others. In the sample applications that came with Fire-iAPI™ you can find the “SimpleFireisample” that presents the use of multiple threads to receive from multiple cameras.

You should call the FiInitializeDisplay function before calling the FiSaveFrame or FiYuv2Rgb functions even if you do not intend to display the captured frames. FiInitializeDisplay initializes all the conversion tables for the yuv to rgb conversion and if you do not call FiInitializeDisplay the conversion tables will not be initialized. That is why you are getting a blank image.

We have noticed this with some video display cards. Do not use hardware overlays with these adapters.

You haven’t probably interconnected the two adapters, so there are two different local buses on your PC. Fire-i™ application checks for cameras on the FIRST local bus ONLY. The simplest solution is to connect the two adapters together. Beware: Loop topologies are PROHIBITED by the 1394 specification. Such a topology will result in successive bus resets, until the loop is removed.

Make sure that the display properties are adequate. First of all more than 256 colors should be selected. Secondly the screen resolution must be greater or equal than the camera resolution. If, e.g. camera format is 800×600 and the display is 1024×768 then the frames should be displayed. If the display is 800×600 then the frames should be displayed ONLY on full screen. If the resolution is 640×480 then no frames should be displayed.

In order to do that you should follow the procedure described bellow: i) set the cameras you want to capture triggered frames from, in trigger mode by checking the trigger check box for each of them. ii) start each camera and open a viewer for each of them. iii) press the trigger so that frames will be transmitted and captured. iv) highlight each window and press the shortcut key you assigned for saving frames.

The version of the Fire-i™ app&drivers you have is in demo mode and has expired after 30 minutes. You must unlock the Fire-i WDM driver using one of the valid product keys you have received after purchasing Fire-iAPI™. You can view the status of your current driver licence by switching in to details view in the Fire-i™ application.

First of all you must install Platform SDK and DirectX8.0 SDK under the same directory, the default option is “c:mssdk” from now this path will be referred as “SDK root”. Secondly you must build strmbasd.lib(debug version), or strmbase.lib(release version),

“To use the base classes in MicrosoftR DirectShowR, you must build and link the base class library, located in the following directory: (SDK root)SamplesMultimediaDirectShowBaseClasses

Note : Previous versions of the SDK included the libary as a binary file. With MicrosoftR DirectXR 8.0, you must build this library yourself if you plan to use the base classes.”
The above quotation is extracted from MS DirectX 8.0 help in:

“DirectX 8.0(C++)DirectShowDirectShow ReferenceDirectShow Base ClassesUsing…”
You can check it for more information on building the lib. After building that lib you must make sure to point the compiler to search for the header files in:

“(SDK root)SamplesMultimediaDirectShowBaseClasses”
first, and “(SDK root)include” second. To do that under VC++6 modify the project’s preprocessor settings in “Additional Include directories” textbox in “Project®Settings®C++ Tab” or modify the VC++ global settings by setting the “Include files” in “Tools®Options®Directories Tab” so that the above mentioned paths to the header files are listed in the order mentioned. Also point the linker to search in:

“(SDK root)SamplesMultimediaDirectShowBaseClassesDebug”
first, and “(SDK root)lib” second. Again one way to do that is by adding the

“(SDK root)SamplesMultimediaDirectShowBaseClassesDebug”
path in the”Library Files” directories of the “;Tools®Options” dialog box under “Directories” tab on top of the list and “(SDK root)lib” second. Also add strmbasd.lib in “Object/Libraries” textbox in “Project®Settings®Link Tab”. You must make sure that the files in the above mentioned directories are the files used by the compiler since there are probably more than one versions of these libraries (like strmbasd.lib) and header files(like streams.h) scattered around in your system.

You need to give power to the camera because the pcmcia cards do not give power to the bus as opposed to regular PCI adapters. In the Fire-i™ installation documentation at page 20 you can find more information on how to connect your camera to your laptop. One suggested way is with the use of a FireRepeater™. If you are going to use a FireRepeater™ make sure that you ave supplied the FireRepeater™ with power. If there is power on the bus the camera’s led should be on. Another way you can power the camera if you do not have a repeater available is to connect the camera to a desktop with a 1394 adapter capable of sourcing enough power to the bus to drive the camera and then connect the desktop to the laptop.

In order to do that you must follow the procedure described below: i) Set the cameras from which you want to capture triggered frames from to trigger mode by checking the “Trigger” check box in Fire-i™ main dialog box. ii) before pressing the trigger, highlight and press the shortcut key (assigned in the “Save Options” dialog box) for every display window for which you want to save the frame that will be displayed in it. iii) press the trigger After that the frames will be saved in the specified directory.

The CFiCamera class which uses DirectShow and the Fire-i wdm kernel streaming driver offers a callback function that is called every time a frame arrives One way you can access the frame data before it is drawn on the computer screen is by inserting the SampleGrabber filter into your filter graph. This filter exports the ISampleGrab interface that allows you to assign a callback for every frame that arrives and get a pointer to the frame data. You can manipulate the data any way you want. Your graph should look like this: Fire-i™ capture driver®Fire-i yuv decompressor®Sample Grabber®Video Renderer.Another way you can have access to the data is by creating a filter of your own and inserting it into the graph. Inside your filter you will have access to the data before they are passed to the video renderer. You can create your own filter by modifying the nullip and nullnull filters provided with the DShow SDK: Fire-i capture driver®Fire-i yuv decompressor®Your own Filter®Video Renderer.

You can use the Fire-i™ yuv decompressor filter (fiyuv.ax) provided with the Fire-i™ drivers in order to do the conversion from yuv to rbg. If you open graphedit a utility provided with DirectShow SDK you will be able to insert the Fire-i™ yuv decompressor into a graph via the Add filters dialog. The decompressor can be found under directshow filters. You can create a custom filter graph and pass the frames to an upstream filter of your choice. You can receive the frame data in RGB by inserting the SampleGrabber filter in the graph. You need ofcource the DirectX 8.0 SDK in order to do all this. Your graph should look like this. Fire-i™ Capture Driver®Fire-i yuv decompressor®SampleGrabber®Video Renderer if doing display or Null renderer otherwise. The sample grabber should allow to set a callback every time a frame is received(Use the DirectShow ISampleGrab interface). Check the DirectShow documentation to find out more about this.