Ultrasonix SDK 3.

0 Integration
Revision 1.0

Creation Date: 03-Apr-2006

Supersedes: NEW
Author: Mike Donovan
File: 531500974.doc

Resonant Medical Inc., Montreal, Canada

DOCUMENTATION NOTICE
This document is the final version and will be updated by a complete reissue.

PROPRIETARY NOTICE
This document is the property of, and contains proprietary information of Resonant Medical Inc. This document shall
not be reproduced, copied, or used for any purpose other than consideration of the technical contents, without the
express written permission of the duly authorized representative of the company.
 PAGE 2 OF
ANALYSIS DOC 10

DOCUMENT # Ultrasonix_SDK_3.0_Integration REVISION 1.0

TITLE Ultrasonix SDK 3.0 Integration

EFFECTIVE DATE SUPERSEDES NEW

SUBMITTED BY Mike Donovan DATE 09-Jun-2006

REVIEWED BY Sebastien Phaneuf DATE 09-Jun-2006

APPROVED BY Bob Donovan DATE 09-Jun-2006

QA APPROVAL DATE

PUBLICATION HISTORY

REVISION NO. CREATION DATE REVISED BY DETAILS

01 09-Jun-2006 Mike Donovan NEW

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 3 OF 12

TABLE OF CONTENTS
Table of Contents..........................................................................................................................3
1.1 Document Scope.............................................................................................................4
1.2 Responsibilities...............................................................................................................4
1.3 Internal Document References & Materials.....................................................................4
1.4 External Document References.......................................................................................4
1.5 Definitions.......................................................................................................................4
2 Specific NEEDS OF ULTRASONIX ACQUISITION.........................................................5
2.1 Current Needs..................................................................................................................5
2.1.1 User must be notified (receive event) only when a new frame is acquired............5
2.1.2 Threading bug in ImageProcessor must be fixed...................................................5
2.1.3 1-frame processing limit for B Processor must be removed..................................5
2.1.4 Currupt setup files must not raise exceptions........................................................5
2.1.5 The SDK dll’s must be compatible with VC7 (and soon VC8).............................5
2.1.6 The serial number licensed must be accessible.....................................................5
2.1.7 The prbInfo structure of probes must be accessible...............................................6
2.1.8 The probe boundaries of variables must be accessible..........................................6
2.1.9 Hardware testing must be accessible.....................................................................6
2.1.10 The acquisition strategy used must not affect current performance.......................6
2.2 New Needs......................................................................................................................6
2.2.1 The prmRfOffset parameter must be accessible properly......................................6
2.2.2 The RF capture length must be at least 18 cm.......................................................6
2.2.3 The captured RF must not be shifted line-wise.....................................................6
2.2.4 The captured RF must not be shifted depth-wise..................................................6
2.2.5 It must be possible to disable (or modify) board filters.........................................7
2.3 Other Needs.....................................................................................................................7
2.3.1 Overlooked Needs.................................................................................................7
2.3.2 Future Needs.........................................................................................................7
2.3.3 Future Bugs...........................................................................................................7
2.3.4 Information Needs.................................................................................................7
3 Integration Options For Ultrasonix SDK.............................................................................8
3.1 Keep working with current SDK (1.2).............................................................................8
3.2 Integrate the new SDKs (Porta 3.0 and Texo 1.0) as-are.................................................8
3.3 Integrate the new SDKs (Porta 3.0 and Texo 1.0) with additional support from Ultrasonix
8
3.4 Integrate the new SDKs with all the buildable source code for both high-level and low-level
DLLs 8
4 Likeliness Of Fulfilling Needs By Option.............................................................................9
4.1 Comparison Table...........................................................................................................9
4.2 Conclusion.....................................................................................................................11

CONFIDENTIAL – DO NOT REPRODUCE

P07P2_WORKSTATION_CONFIG_EDITOR-01 PAGE 4 OF 12

1 PURPOSE
This document analyses the feasibility of integrating the new Ultrasonix 3.0 SDK into the
Restitu main trunk.

1.1 Document Scope

This document covers all options concerning the evolution of the RsdUltrasonixAcquition
module to add new features, including RF acquisition, while maintaining the current
functionality.

1.2 Responsibilities
Mike Donovan and Sebastien Phaneuf are responsible to keep analysis valid and up-to-date.

1.3 Internal Document References & Materials

DOCUMENT NAME AUTHOR VERSION DATE

1.4 External Document References

DOCUMENT NAME AUTHOR VERSION DATE

1.5 Definitions

TERM MEANING

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 5 OF 12

2 SPECIFIC NEEDS OF ULTRASONIX ACQUISITION

2.1 Current Needs

2.1.1 User must be notified (receive event) only when a new frame is acquired
SDK 1.2 had to be modified so that the main acquisition loop notifies the user only if a new
frame is found. As it was, the main loop emitted events continuously, and because the event did
not contain a frame ID to compare with the previous event, we could mistakenly record the
same frame twice or even more often. As this was probably not considered a bug by Ultrasonix,
it likely hasn’t been ‘fixed’ in their most recent SDK.
The fix involved creating our own acquisition loop, which requires access to several internal
variables and functions of the SDK which are not exported in current SDK.

2.1.2 Threading bug in ImageProcessor must be fixed

SDK 1.2 had to be modified to fix a threading bug which occurred in a loop that repeatedly
called a function to check the number of frames to process. Since that function may suddenly
return something different mid-loop because of modifications by another thread, the initial
result of that function call was put into a local variable. This has likely been corrected by
Ultrasonix in their new SDK.

2.1.3 1-frame processing limit for B Processor must be removed

SDK 1.2 had to be modified so that it does not limit the number of frames to process in B-
Mode. As it was, a one-frame limit was put to prevent flooding the CPU. Our experience is that
the CPU is not flooded without that limit. As this was possibly not considered a bug by
Ultrasonix, it might not have been ‘fixed’ in their most recent SDK.

2.1.4 Corrupt setup files must not raise exceptions

SDK 1.2 had to be modified so that if a setup file is corrupt, the exception raised in
SYS_LoadSetup() is caught and ignored, and the function simply returns a flag warning that the
file could not be loaded. As it was, the SDK raised an exception that interrupted the program’s
execution. The problem was not the exception per se because it can be caught in an outer loop,
it was that the exception was raised and resources from the system weren’t freed: some buffers
were created and the setup file was kept open forever. This has possibly been corrected by
Ultrasonix in their new SDK.

2.1.5 The SDK dll’s must be compatible with VC7 (and soon VC8)
SDK 1.2 had to be rebuilt on VC7 to make its dll’s compatible with Restitu. As it was, the dll’s
were built in VC6, and were unusable by Restitu, which is built in VC7. This has not been fixed
by Ultrasonix in their new SDK, which is still built in VC6.

2.1.6 The serial number licensed must be accessible

SDK 1.2 had to be modified to allow access to the Licenser object and its Init() and
GetSerialInfo() functions, because the serial number is displayed in Restitu and used by
manufacturing for inspections, etc… The new Ultrasonix SDK does not seem to allow access to
the serial info.

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 6 OF 12

2.1.7 The prbInfo structure of probes must be accessible

SDK 1.2 allowed access to the prbInfo structure of a probe. This access seems to have been
removed in the new SDK. Restitu needs it for its generateProbeReport() function, and to fill its
mAvailableProbes variable.

2.1.8 The probe boundaries of variables must be accessible

SDK 1.2 had to be modified to allow access to the probe-related boundaries of variables. This
information is used to validate the manual input of data in our spinbox and especially the
TextEdit that allows entering of arbitrary values. The new SDK does not seem to allow access
to those boundaries, which are not used in the demo of the SDK (the spinboxes in that demo
does not allow direct manual entry of parameters).

2.1.9 Hardware testing must be accessible

SDK 1.2 allowed the testing of Ultrasonix hardware through its SYS_TestHw() function. This
functionality is used in Restitu within its doRunHwTest() function. It is used by manufacturing
to validate incoming inspection. The new SDK does not seem to allow access to the hardware
testing function.

2.1.10 The acquisition strategy used must not affect current performance
Our current acquisition strategy is the parallel strategy, which has its own acquisition loop. All
performance tests were done on that strategy. Should we need to change to the callback strategy
(implemented but not performance-tested), performance must not be negatively affected. The
new SDK may force the use of the callback strategy.

2.2 New Needs

2.2.1 The prmRfOffset parameter must be accessible properly

SDK 1.2 had to be modified to fix a bug in ParamsMgr. The function GetParamName() returned
the wrong name for the variable prmRfOffset. We need that parameter in RF acquisition. This
has likely been fixed in the new SDK.

2.2.2 The RF capture length must be at least 18 cm

SDK 1.2 does not allow RF capture length to exceed 7.9 cm because of the FIFO size. Restitu
needs a capture length of at least 18 cm. This has likely been corrected in the new SDK.

2.2.3 The captured RF must not be shifted line-wise

SDK 1.2 captures RF frames which are shifted line-wise, i.e. some lines seem to belong to an
earlier or later frame. Restitu needs proper frames. This has likely been corrected in the new
SDK.

2.2.4 The captured RF must not be shifted depth-wise

SDK 1.2 captures RF frames which are shifted depth-wise, i.e. the samples are preceded by
samples that seem to belong to another frame or to the end of the current frame. Restitu needs
proper frames. This has likely been corrected in the new SDK.

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 7 OF 12

2.2.5 It must be possible to disable (or modify) board filters

SDK 1.2 had to be modified to allow access to the SetVariableValue() of the SystemMgr. This
was needed to disable the board filters. The new SDK does not seem to provide access to non-
display parameters.

2.3 Other Needs

2.3.1 Overlooked Needs

We tried to be as thorough as possible in assessing our needs, but it is quite possible that we
overlooked something we need that the new SDK does not provide or no longer provides.

2.3.2 Future Needs

Our research team has just started exploring the possibilities of RF acquisition, and it is quite
possible that we will find that we need some feature not accessible through the new SDK.

2.3.3 Future Bugs

No product is bug-free, and the Resonant team did find bugs in Ultrasonix SDKs that were
impairing our development. It is quite possible that we will find bugs in the new SDK that we
will not be able to fix because we do not have access to the source code. If those bugs blocks
our development, we will be dependent on Ultrasonix to fix those bugs in a timely manner.

2.3.4 Information Needs

Having access to the SDK source code allowed us to learn how certain functions had been
implemented. In certain cases, this is crucial. For example, knowing the exact algorithms to
convert raw RF in scan-converted B-Mode to get the same images we are currently getting, or
modifying the SDK to allow dumping of all parameters to know which ones must be modified
to disable board filters. Adopting a new SDK for which we do not have the source code
prevents us from getting that information.

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 8 OF 12

3 INTEGRATION OPTIONS FOR ULTRASONIX SDK

This is a list of all options we have for integrating the Ultrasonix SDK in Restitu.

3.1 Keep working with current SDK (1.2)

The current SDK fulfills most of our needs as-is. Having access to the source code allows us to
make the modifications we need. Certain needed modifications, however, may be too complex
or time-consuming, or may be even impossible.

3.2 Integrate the new SDKs (Porta 3.0 and Texo 1.0) as-are
The new SDKs provide a lot of functionality and likely fix many of the more complex bugs
(especially for RF acquisition). Adopting them may make Restitu more performant, may give
access to features not available in older SDKs, and may even eventually be necessary with new
hardware. Integrating them as-is has the advantage that it does not require any additional
support from Ultrasonix, and makes us less dependent on them. However, it may be impossible
to fulfill many of our needs, and the integration may be time-consuming, especially if the new
SDKs cause new bugs in Restitu.

3.3 Integrate the new SDKs (Porta 3.0 and Texo 1.0) with additional
support from Ultrasonix
If Ultrasonix accepts to provide additional support for their SDKs in a timely manner, we may
get most of the advantages of option 3.2 (complex bug fixes, possible performance boost, new
features, compatibility with future hardware). In addition, many of our needs are more likely to
be fulfilled through their support. This would likely require their giving us access to all their
low-level DLLs (not the source code, but the LIBs and headers) and their giving us buildable
sources for one or more critical specific low-level DLLs. However, this would make us more
dependent on them, it may still be impossible to fulfill some of our needs, and the integration
may still be time-consuming.

3.4 Integrate the new SDKs with all the buildable source code for both
high-level and low-level DLLs
If we convince Ultrasonix that giving us access to all the buildable source code for their DLLs
simplifies our integration greatly (and even makes it possible in the first place) without any
disadvantages for them, we get all advantages of option 3.3. In addition, it is likely that all our
needs will be met this way, and that we will not be blocked waiting for them to make changes.
The integration will still be more time-consuming than with option 3.1, but the advantages
outweigh that disadvantage greatly.

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 9 OF 12

4 LIKELINESS OF FULFILLING NEEDS BY OPTION

4.1 Comparison Table

Needs 3.1 Old SDK 3.2 New SDK as- 3.3 New SDK 3.4 New SDK
is with support with all sources
2.1.1 Notification Certain. Already Unlikely. Uncertain. Certain.
only if new frame working. Probably not Requires our own Necessary
considered a bug acquisition loop, modifications in
by Ultrasonix. and thus access to source code
acquisition DLL possible.
source code.
2.1.2 Processor Certain. Already Likely. Ultrasonix Likely. Ultrasonix Certain.
threading bug working. informed of the informed of the Necessary
bug. bug. modifications in
source code
possible.
2.1.3 1-frame Certain. Already Uncertain. May Uncertain. May Certain.
processing limit working. not be considered not be considered Necessary
a bug. a bug. May require modifications in
access to source code
utx_imgproc.dll possible.
source code.
2.1.4 Corrupt Certain. Already Uncertain. May Uncertain. May Certain.
setup files working. not be considered not be considered Necessary
a bug. a bug. May require modifications in
access to porta.dll source code
source code. possible.
2.1.5 VC7 Certain. Already Unlikely. Likely. Certain.
compatibility working. Workarounds may Workarounds may Necessary
be possible but be possible but modifications in
probably requires a probably requires a source code
new version by new version by possible.
Ultrasonix. Ultrasonix.
2.1.6 Serial Certain. Already Unlikely. Does not Unlikely. Does not Likely. Necessary
number working. seem accessible seem accessible modifications in
through SDKs. through SDKs or source code may
even exported in be possible, but
low-level DLLs. driver may not
May require access allow access
to utx_driver.dll anymore.
source code.
2.1.7 prbInfo Certain. Already Unlikely. Does not Unlikely. Does not Certain.
structure working. seem accessible seem accessible Necessary
through SDKs. through SDKs or modifications in
even exported in source code
low-level DLLs. possible.

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 10 OF 12

May require access

to utx_utils.dll
source code.
2.1.8 Probe Certain. Already Unlikely. Do not Unlikely. Does not Certain.
boundaries working. seem accessible seem accessible Necessary
through SDKs. through SDKs or modifications in
even exported in source code
low-level DLLs. possible.
May require access
to utx_utils.dll
source code.
2.1.9 Hardware Certain. Already Unlikely. Does not Likely. Requires Certain.
testing working. seem accessible access to Necessary
through SDKs. utx_driver.dll LIB modifications in
and headers. source code
possible.
2.1.10 Strategy Certain. Already Likely. Nothing Likely. Nothing Certain. We can
performance working. hints that the hints that the choose the best
callback strategy callback strategy strategy since both
might be slower. might be slower. are implementable.
2.2.1 Certain. Already Likely. Too Likely. Too Certain.
prmRfOffset working. crucial a bug to crucial a bug to Necessary
access bug have been have been modifications in
overlooked. overlooked. source code
possible.
2.2.2 RF full Unlikely. Likely. Advertised Likely. Advertised Likely. Advertised
capture length Probably as such by as such by as such by
impossible to fix Ultrasonix Ultrasonix Ultrasonix and
in a simple necessary
manner. modifications in
source code may
be possible.
2.2.3 RF line-wise Uncertain. May Likely. Too Likely. Too Likely. Too
shift bug be impossible to crucial a bug to crucial a bug to crucial a bug to
fix in a simple have been have been have been
manner. overlooked. overlooked. overlooked and
necessary
modifications in
source code may
be possible.
2.2.4 RF depth- Uncertain. May Likely. Too Likely. Too Likely. Too
wise shift bug be impossible to crucial a bug to crucial a bug to crucial a bug to
fix in a simple have been have been have been
manner. overlooked. overlooked. overlooked and
necessary
modifications in
source code may
be possible.
2.2.5 Disabling Certain. Already Unlikely. Does not Likely. Requires Certain.

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 11 OF 12

board filters working. seem accessible access to Necessary

through SDKs. utx_imgproc.dll modifications in
LIB and headers. source code
possible.
2.3.1 Overlooked Likely. Access to Unlikely. No Uncertain. Likely. Access to
source code. access to source Limited access to source code.
code. Probably source code.
requires new Probably requires
version by new version by
Ultrasonix. Ultrasonix.
2.3.2 Future Likely. Access to Unlikely. No Uncertain. Likely. Access to
source code. access to source Limited access to source code.
code. Probably source code.
requires new Probably requires
version by new version by
Ultrasonix. Ultrasonix.
2.3.3 Future bugs Likely. Access to Impossible. No Unlikely. Limited Likely. Access to
fixing source code. access to source access to source source code.
code. Requires code. Probably
new version by requires new
Ultrasonix. version by
Ultrasonix.
2.3.4 Information Likely. Access to Impossible. No Unlikely. Limited Likely. Access to
source code. access to source access to source source code.
code. Requires code. Probably
answers from requires new
Ultrasonix. version by
Ultrasonix.

SUMMARY Very Likely. Very Uncertain. Uncertain. Almost Certain.

(86% average) (41% average) (55% average) (90% average)

4.2 Conclusion
The overall need fulfillment of each option was calculated by assigning a value to each
probability (Impossible = 0%, Unlikely = 25%, Uncertain = 50%, Likely = 75%, Certain =
100%) and averaging the results. It is obvious from the table that options 3.2 and 3.3 are very
likely to be unusable (45% and 31% less likely to fulfill our needs than the current option (3.1).
However, option 3.4 is more likely to fulfill our needs than the current option, enough to justify
the disadvantages that come with it (possibly time-consuming implementation). The different
needs were not weighted, but option 3.4 makes fulfilling our new needs much more likely than
option 3.1, and may be the only way to fulfill them.
This analysis makes clear that unless we have full access to Ultrasonix buildable source code
for both high and low level DLLs, it is not a good move, and may be even impossible, to
integrate the new Ultrasonix SDK. Because it may be necessary to do so to fulfill our new
needs, option 3.4 seems the only choice. This implies that Ultrasonix must be convinced that
providing their source code is necessary for us and not a disadvantage for them.

CONFIDENTIAL – DO NOT REPRODUCE

ULTRASONIX SDK 3.0 INTEGRATION PAGE 12 OF 12

CONFIDENTIAL – DO NOT REPRODUCE