Synchronization

Overview
The Sonix systems allow for synchronization through BNC ports on the Ultrasonix PCI card installed on all systems. Depending on the system, the number of ports may vary. The BNC is a 5V TTL signal by nature, however some hardware modification may needed due to filters placed on the PCI to draw out the signal and lower the amplitude for signal connectivity to thermal printer devices.

BNC Layout
The Sonix RP has 2 BNC ports, one input and one output, and the SonixTOUCH Research has 4 BNC ports, two inputs and two outputs; the diagram below shows the configuration as installed within the system.



Output Synchronization
By default the pulse on the output will look as below, an approximately 25ns 1V peak-to-peak pulse. This may be inadequate for triggering some devices, therefore the instructions below should be implemented to change the characteristics.



With PCI modification as described below, the following 3-5V peak-to-peak pulse can be achieved:



PCI Modification
By default, the Sonix systems have resistors on the PCI card to draw out the TTL pulse on the BNC output signals and reduce the amplitude to properly trigger thermal printers used, often in clinical environments. To amplify the pulse for other device synchronization including triggering the SonixDAQ, the below modifications should be made:

SonixTOUCH Research:
 * Short R32 with 0 ohm resistor
 * Short XR41 with 0 ohm resistor
 * Remove XC32
 * Remove C52

Sonix RP:
 * Short R32 with 0 ohm resistor
 * Remove C52

Note that for the SonixTOUCH Research, the capacitors and resistors are located on the other side of the board.



General Details

 * The input BNC should receive a 3-5 V TTL pulse, with a duration of 50-100 ns in order to trigger the system properly.
 * The hardware only looks at the rising edge of the signal.
 * Currently, the SonixTOUCH Research only supports 1 input signal (Input BNC #1), as no method for differentiation of signals has been implemented.

Missing Frames
While triggering the system to acquire data, it is important to implement some safeguards with respect to frames being dropped:
 * From a hardware perspective it is important not to trigger the system faster than the programmed frame rate (or PRF if in scanline mode), otherwise trigger signals will be ignored while the system is still in the process of transmitting and receiving scanline/frame data.
 * From a software perspective, if a callback has been implemented in one of the SDKs, it is important not to block the callback for very long, otherwise the software interrupt will be overlooked. Typically, the amount of work in a callback should just be to memcpy data into another buffer and set another worker thread to do the processing.

Software Callbacks
It should be noted that a frame is found through a software implemented collector thread that looks for new frame headers. The software looks for the frame header of the next frame to determine that the previous frame is ready. This is important to note as it may have some implications in programming the system. If the software were to trigger a callback when the current frame is being collected, it may recognize the frame as being valid too soon. For example, the first scanline (of a multi-scanline frame) includes the 4 byte frame header. If recognized by the thread while other scanlines are still being transmit/receive for the frame, then the copy of data from memory may be errorneous by the fact that invalid data would be contained in the memory for that frame.

The collector thread thus looks for the frame header of the next frame to ensure that the previous frame has finished its transmit/receive. This of course adds a slight delay to when the frame is actually recognized vs when the frame has actually finished acquired. This delay is small, and can be calculated at roughly FR*(1/LD), where FR is the frame-rate of imaging, and LD is the number of scanlines that make up the image.

Triggering and software interrupts can be summarized in the below diagram.



For continuous capture, the above explanation warrants only the fact that for triggered capture, at least 2 triggers must be sent to the system for a frame to be acknowledged within the collector thread. Of course, for non-continuous capture, this poses some more problems. For example, in the second frame collection from diagram above, a delay of n is imposed after triggering two frames. Once the third trigger is received, frame ID=1 will be acknowledge, which will be of course n time units in the past. A double triggering method should then be employed all the time to ensure real-time frame data is collected via software properly.