ActiveX Tech Notes
Circuit fails when loaded using 64-bit Matlab
Date Added: 2016-08-02
Using 64-bit Matlab to load a circuit that uses the HP_LP_Filter macros or the PZ5_Control macro will fail. The 64-bit RPcoX control is unable to load any circuit that uses a ScriptTag component. The error message in 64-bit Matlab looks like this:
"Error using COM.RPco_x/LoadCOF Error: Object returned error code: 0x2686BFC0"
In v78 and above LoadCOF will fail with no error.
This failure occurs because these macros use a VBScript component that isn't 64-bit compatible.
The HP_LP_Filter can be replaced using cascading HP/LP Biquad filters in the circuit, which is functionally equivalent.
There is currently no workaround for the PZ5_Control macro. Contact TDT support for assistance.
Use 32-bit Matlab or replace the functionality of the ScriptTag component in your own custom code.
ConnectPA5 method always fails (returns 0)
Date Added: 2009-04-28
The ActX for PA5 installation is not compatible with version 68 of TDT Drivers. Attempting to call the ConnectPA5 method will always return a 0 (fail) even if the PA5 is correctly connected and detectable in zBUSmon.
Upgrade to v70 or above.
Writing console applications with ActiveX or OpenDeveloper controls
Product: ActiveX, OpenDeveloper
Version: > 66
Date Added: 2008-05-13
Console-based ("formless") applications written in C++ or Python (console driven and no user interface) are not compatible with previous versions of ActiveX and OpenDeveloper controls. Methods called on an instantiated ActiveX or OpenDeveloper control fail to work.
The latest versions of ActiveX and OpenDeveloper controls provide support for formless applications. Update to the latest version of ActiveX or OpenDeveloper.
GetStatus method with RX devices returns erroneous information
Date Added: 2008-05-09
When using the
GetStatus method with RX devices, the method returns erroneous
values. RX devices return higher bit information, and this causes issues with
the status values described in the ActiveX help documentation.
For example, a
GetStatus value 7 corresponds to a device that is connected and
has a circuit loaded and running. Using the
GetStatus method on a connected RX
device that has a circuit loaded, and running will not return the value 7, but
will return the value 7 plus high bit information resulting in the erroneous
To access relevant status information in Matlab, use
bitget (or the equivalent
in other programming languages) to read each bit directly. For example, the
following code is compatible with RX devices:
if all(bitget(RP.GetStatus,1:3)) disp('Circuit loaded and running'); end
If RP.GetStatus And 7 <> 7 Then Msgbox("Error loading circuit") End If
Converting WAV File Sampling Rates
Date Added: 2008-03-05
Before .wav files can be played using TDT System 3 devices, they must often be resampled. The sample rate of the file must match the sample rate of the device. CoolEdit or other audio editing programs can be used to resample and save .wav files. After the file is resampled, it can be played from RPvdsEx using a SourceFile component. MATLAB can also be used to resample .wav files in real- time just before they are played. The file data can then be written to an RPvdsEx buffer for playing. This is especially helpful if many files are being used.
The example code below reads in a .wav file and returns resampled data that is ready to play out on the DAC. WriteTagV is used to load the data into the SerialBuf component of an RPvdsEx circuit. In the example circuit, the data is fed to the SerialBuf using the "data_in" parameter tag.
wav_filename = 'c:\tmp\myfile.wav'; % put path of .wav file here new_sample_rate = 24414.0625; % put sample rate of RP here [data, sample_rate, bps] = wavread(wav_filename); [p, q] = rat(sample_rate / new_sample_rate, 0.0001); new_data = resample (data, q, p); RP.WriteTagV('data_in', 0, new_data'); RP.SoftTrg(1);
This example can also be applied to other types of data (e.g. 16-bit integers).
LoadCOFsf to set arbitrary sampling rates yields erroneous results
Date Added: 2008-02-27
The ActiveX method
LoadCOFsf is used to load a Control Object File (*.rco or
*.rcx) and set the sampling frequency of a device.
LoadCOFsf also allows
arbitrary sampling rates to be set for rates of 50 and above, however not all
devices support arbitrary rates. Setting unsupported arbitrary rates for the
device yields erroneous results. Specifically, the RX6 and RX8 devices equipped
with sigma-delta A/D or D/A converters do not support arbitrary sampling rates,
so care should be taken to specify only realizable rates.
The RV8 and RX8 devices equipped with PCM A/D or D/A converters support arbitrary sampling rates.
When using the RX6 or RX8 devices equipped with sigma-delta A/D or D/A converters refer to the RX6 realizable rates table on the RX6 Fast Facts on the TDT website.
Repeated use of the ActiveX Connect command causes the system to crash
Date Added: 2007-04-13
System crashes after repeatedly using the ActiveX Connect command (e.g.,
Connect command only once to connect to a device, and then use
LoadCOF commands to upload or reload the control object to
implement changes to the signal.
GetStatus returns incorrect information for bit-0 on an RZ2
Product: RZ2, ActiveX
Version: Microcode version 62 and below
Date Added: 2007-01-07
GetStatus always returns a zero for bit-0 on an RZ2 with microcode v62 and below.
Update to latest version of TDT Drivers. After installing the drivers, reprogram the RZ2 with the new microcode. Keep in mind that reprogramming the microcode on an RZ processor will take about five minutes per DSP.
Unlike the Medusa base station, bit-0 of the GetStatus return value is not used to report PZ amplifier status. RZ users should refer to the LCD screen for amplifier status information.
Buffering a long signal at a high sample rate causes a memory allocation error
Product: RX, ActiveX
Date Added: 2006-12-04
The memory allocation for the buffer on an RX device is 14450300 samples. When the buffer required exceeds this limit a memory allocation error is reported.
Either use two buffers each holding half of the data then use ScaleAdd to sum them together, or compress the data into 16-bit integers and expand back into 32-bit floats on the hardware.
If the signal can be expressed in 16-bit format, use the ActiveX command WriteTagVEX and ExpandFrom16 as shown in the figure below. Scale the input data so the maximum values scale to ± 32767. Write the 16-bit data to the Data port of the source component. Expand from 16 to 32 bits using the ExpFrom16 component with the inverse of the scale factor used in the first step. Note: not recommended for 32-bit signals such as wav files or signals acquired on a TDT device.
This Matlab example assumes an input to the SerSource component bounded by unity:
s = 1:2000; s = sin(s); % input bounded by unity s = s*32760; % scale the data to best fit the range +/- 32767
2000 16-bit input data points fit into the SerSource buffer of size 1000.
RCO files created with RPvdsEx v50 or earlier might fail to load when using ActiveX v60 and greater
Version: > 59
Date Added: 2006-10-27
After upgrading to v60 ActiveX or greater, some older RCO files may fail to load using ActiveX commands.
If an existing RCO fails to load to a device using ActiveX 2.0 commands, rebuild the RCO with RPvdsEx v60 or greater. Also, beginning with RPvdsEx v60, users can utilize the new combined (RCX) file format. See Tech Note #0226 for more information.
zBusSync always returns zero when using USB2, Gigabit, or Optibit interfaces
Date Added: 2006-05-21
The zBusSync command has no effect and returns a zero when used with a USB 2.0 (UZ2/UB2), Gigabit (FI5/PI5) or Optibit (PO5/FO5) interface.
The zBusSync ActiveX Command is used for synchronizing caddies with USB1.1 (UZ1/UZ4) interfaces and should not be used with other types of interfaces. The Optibit and Gigabit interfaces are automatically phase locked to a single clock and the USB 2.0 interface is automatically synchronized when the Sync line is used. For more information on these interfaces see the System 3 Manual.
GetStatus returns zero or zBus error 'Failed locking device.'
Product: FI5, ActiveX
Date Added: 2005-08-19
Attempting to connect to a TDT device more than once using the ActiveX methods
ConnectRP2 etc.) can cause a communication failure
when using the gigabit interface.
Connect to a device only once and then use
LoadCOF to ensure that a
new .rco file is loaded.
Memory leaks occur in Matlab when calling ActiveX functions with improper capitalization
Date Added: 2005-07-28
When using ActiveX controls such as ReadTagV with Matlab 6.5, calling the
function with the characters
readtagv (all lowercase) will cause a memory leak
of 8 bytes per point returned. When using ActiveX controls such as GetTagVal
with Matlab 7.0, calling the function with the characters
lowercase) will cause a memory leak of 40 bytes per function invocation.
To avoid these leaks, make sure to call the functions exactly as designed (with
the proper capitalization, e.g.
HardwareReset always returns 0
Version: > 3.6
Date Added: 2005-03-10
HardwareReset returns 0 both when the reset is successful and when it is not.
You can determine the status of the hardware reset by viewing the module's front panel LCD display or front panel LEDs while the method is being called. The LCD display and status LEDs on an RXn device will display the boot loader sequence and the indicator LEDs on an RPx device will light accordingly.
GetStatus always returns a 0 for the RA16BA connection status (least significant bit)
Date Added: 2004-12-30
Although ActiveX seems to connect and properly load a circuit to the RA16BA (Medusa Base Station), the GetStatus method will consistently return a 0 for connection status.
Use the second (circuit loaded) and third (circuit running) bits.
Synchronizing devices using zBusSync
Date Added: 2004-09-01
There are several things to notice when synchronizing devices through the ZbusSync in ActiveX.
First, there is a crystal that drives the processor for each device. The crystals have small differences in their actual frequency, which is less than .001%. However, over several seconds this slight difference can have a large effect between racks that is in the milliseconds range. In order to remove this problem, all devices are driven by the same clock. For the gigabit interface the PI5 controls the clock. However, for the USB interface the clock is in the USB connection, which will often create more of a delay between racks.
The second issue is the start and stop time for devices. When two or more devices are running there will always be a slight delay between the start of one and the start of the other (several milliseconds).
A ZBUSsyncA or B can be used to ensure that they are synced. This trigger can be used to reset the buffers sync clocks and then synchronize the devices. Once they are synched, the only differences between devices will be a slight jitter of no more than ½ a sample period.
Invoking the ActiveX zTrigA or zTrigB calls always returns a zero
Version: > 56
Date Added: 2004-08-12
Invoking the ActiveX zTrigA or zTrigB calls always returns a zero, irrespective of the actual result.
You can monitor the actual result in one of two ways. In your RPvdsEx circuit:
Link the output of the TrgIn component to a digital output on your device. This will allow you to view the trigger result on the front panel of the device.
Link a parameter tag to the output of the TrgIn component. You can then read this tag using RPcoX's GetTagVal method.
After upgrading the ActiveX controls, VC++, VB, and Delphi programs that used to work no longer work correctly
Date Added: 2002-11-13
After upgrading the ActiveX controls, VC++, VB, and Delphi programs that used to work no longer work correctly. Typically, the problem is seen with the connect functions, such as ConnectRP2 and ConnectZBUS. These functions will always return 0 (failure). However, other functions such as ReadTag and SetTagVal may also fail.
This problem occurs because VC++, VB, and Delphi remember the older ActiveX version. Remove the ActiveX control instances from the project and re-create them.
ZTrig does not work while using ActiveX with USB
Date Added: 2002-01-10
Logical devices may have changed when racks were turned on and off. For example, a single device might have shifted from device 1 to device 2. This will cause sending out a global zTrig to fail because zTrig uses the first rack as the Master from which all the others are set. This should only be a problem with USB and not Gigabit interfaces. Rebooting solves this problem.