| Script | Function |
| /opt/dtp/host/bin/start_platform.sh | Starts the x86StandaloneNode node (platform).No arguments required. |
| /opt/dtp/host/bin/stop_platform.sh | Stops the x86StandaloneNode node (platform) if running.No arguments required. |
| /opt/dtp/host/bin/start_node.sh | Starts the x86Node and binds it into the DTP4700 platform running on the Thunder target system. This script expects the NameService reference as an argument in the format:-ORBInitRefNameService=corbaloc:iiop:1.2@:2809/NameService |
| /opt/dtp/host/bin/stop_node.sh | Stops the x86Node and removes it from the DTP4700 target domain.No arguments required. |
# 4.5 Configuring the System
The adopted hardware supporting the DTP4700 SCA platform is the Thunder system from DataSoft Inc. The hardware assembly is comprised of baseband and RF/Transceiver sub-systems, and incorporates a front-end module for connection to various peripheral devices.1
This section describes the facilities that make-up the DTP4700 SCA platform in terms of the connectivity provided by the hardware and the configuration required to support the signal processing capabilities of the radio.
# 4.5.1 General Approach to Platform Configuration
The general approach to the configuration of the DTP4700 SCA platform is to alter configuration property values assigned to platform components that abstract hardware device drivers. This is entirely consistent with the SCA. There are a number of mechanisms that can be used to alter configuration property values.
• Assign property values to the component model: default values are generated from the component definition and are persisted as part of its property descriptor. Default values can be overridden at the assembly level and are persisted as part of the assembly descriptor. Descriptors are parsed by the core framework and property values are set when instantiating component instances. The procedure for setting the values of configuration properties is described in Section 4.5.1.1, Changing Property Values in the Model, below.
• Override configurable property values at runtime: assuming the property is writable, the value can be set by calling the configure operation of the component where the property is assigned. This is a programmatic approach that can be included as part of the application implementation itself, or made available as a general facility. The runtime monitor feature of Spectra CX is an example of the latter, where components can be interrogated at runtime, and configuration property values changed. The use of the Spectra CX runtime monitor is described in Chapter 8, and examples of programmatically setting property values using the supplied waveforms are given for Tx and Rx baseband sample rate in Sections 4.5.2.2.1 and 4.5.2.2.2 respectively.
# 4.5.1.1 Changing Property Values in the Model
The general procedure for changing component default property values is described in this section. For illustration purposes, the default value of the txFrequency property assigned to the platform component RfCtrlDevice is used.
Step 1: Using Spectra CX, expand the DTP4700 model project folder in the Project Explorer view. Then expand the DTP4700 platform model folder, and the DTP4700 > RfCtrlDevice folders to display the model elements that make up the RfCtrlDevice component definition. Double-click the diagram element named RfCtrlDevice contained within the RfCtrlDevice package. This will display the diagram for the RfCtrlDevice component definition as in Figure 11.
Step 2: Select the txFrequency property assigned to the RfCtrlDevice component in the diagram. Properties are displayed on the component (structural realisation) model element as attributes.
Step 3: Open the Properties view and select the SCA tab to display the model elements associated with the txFrequency property. Change the default value as required in the field named Value. Note: The default value is initially set as 446006250 Hz.
Having changed the default value of the property txFrequency, the new definition for RfCtrlDevice can be generated as part of the SCA descriptors for the component.
Figure 11 RfCtrlDevice component definition
Figure 12 Generating Descriptors
Step 4: Right-click the RfCtrlDevice model element either by using the model element (structural realisation) displayed in the diagram or in the Project Explorer view, and choose Generate > Descriptor(s) from the menu, as shown in Figure 12. Notice that this procedure creates a folder DTP4700\_src in the workspace to contain the generated descriptor artefacts, and that the model is validated prior to generating the required files.
Step 5: Expand the DTP4700\_src descriptors folder in the Project Explorer view to display the generated descriptor artefacts for the DTP4700 project. Double-click on the profile descriptor for the RfCtrlDevice component (RfCtrlDevice.prf.xml) to view the file contents in Spectra. Using the file editor search for the text string ‘txFrequency’ to examine the XML elements describing the property, including the assigned default value. This is illustrated in Figure 13.
Figure 13 Profile descriptor
# 4.5.2 Radio Frequency/Transceiver Sub-system
The hardware components and parameters available for controlling the RF/Transceiver sub-system of the Thunder are illustrated in Figure 14.
Figure 14 RF/Transceiver sub-system and Control Parameters
Referring to Figure 14, the software interface to the DAC (Tx) and the ADC (Rx) to the baseband domain is provided by a device driver controlling an FPGA device mounted on the digital board of the Thunder (See Figure 2 on page 6). Control functionality for the RF/Transceiver sub-system is implemented in a separate FPGA device mounted on the RF board which is also controlled using the driver from the GPP. As described earlier in this chapter, the WfFPGAProxy and RfCtrlDevice components provide the necessary SCA abstraction for the device driver, where, in the case of data, the WfFPGAProxy is capable of sending/receiving interleaved 16-bit sampled complex baseband signal data to/from the RF/Transceiver sub-system (See Section 6.3, Connecting Waveform with Platform, on page 51, for more information).
The digital tuner is provided as a separate processing unit connected to the Wf FPGA. By default, signals are routed through the digital tuner. Alternatively, the digital tuner can be bypassed.
The Thunder RF/Transceiver sub-system hardware includes an Automatic Gain Control (AGC) function which supports two control loops:
• wide-band – affecting the Rx signal upstream of the low-pass filter (LPF) by attenuation of the signal at the Power Amplification (PA) phase (illustrated as ‘att’ in Figure 14).
• narrow-band – affecting the Rx signal downstream of the low-pass filter (LPF) by parameters controlling the Rx Variable Gain Amplifier (RXVGA).
The AGC function can be disabled in either mode which assumes maximum gain.
The various control parameters required to control the RF/Transceiver sub-system, as shown in Figure 14, are exposed as SCA properties assigned to the RfCtrlDevice component provided as part of the DTP4700 SCA platform. Table 4 provides an overview of those properties directly affecting the RF/Transceiver sub-system control.
Table 4 SCA Properties for RfCtrlDevice Component
| SCA Property Name | SCA Property Type/Action | Units/Default Value | Function/range |
| txOutPutPower | Short/Configure | dBm/0 | Tx output power -45 to +5 dBm range |
| txFrequency | Ulong/Configure | Hz/446006250 | Tx output frequency |
| txLpfBandwidth | Ulong/Configure | Hz/20000 | Tx lowpass filter bandwidth (cut-off frequency) |
| txOutputEnable | Boolean/Configure | false | Enable Tx output |
| txDacSampleRate | Ulong/Configure | sps/48000 | DAC sample rate |
| rxFrequency | Ulong/Configure | Hz/446006310 | Rx input frequency |
| rxAdcSampleRate | Ulong/Configure | sps/6144000 | ADC sample rate |
| rxLpfBandwidth | Ulong/Configure | Hz/20000 | Rx lowpass filter bandwidth (cut-off frequency) |
| rxInbandAgc | Boolean/Configure | true | Enable automatic gain control (AGC) |
| rxVGA | Short/Configure | dB/0 | Gain, only settable if rxInbandAgc is disabled /0-40 |
| rxDcOffsetLoop | Boolean/Configure | true | DC offset compensation |
| rxAttenuator1 | Short/Configure | dBm/31 | Only settable if rxWidebandAgc is disabled |
| rxAttenuator2 | Short/Configure | dBm/31 | Only settable if rxWidebandAgc is disabled |
| extRefPII | Boolean/Configure | false | External ref phase lock loop |
| rxWidebandAgc | Boolean/Configure | true | Enable Rx wideband automatic gain control |
# 4.5.2.1 The Digital Tuner
The digital tuner is used to decimate the sample rate and sharply filter the input signal, i.e., reduce or eliminate aliasing caused by the ADC process1 . By default, the digital tuner's decimation rate is 128, and the decimation filter cut-off frequency is 0.8 PI radians/sample at the decimated rate.
The decimation rate and filter cut-off can be changed by programming the digital tuner using the following method,
Step 1: Read the current configuration into memory by opening the device /dev/ad6620, reading into a buffer, and typecasting the buffer to "struct AD6620\_PARAMETERS\_STRUCT" (defined in ad6620\_ioctl.h).
Step 2: The parameters can be changed as required then written back to the device.
To bypass the digital tuner, set bit 13 to 0 in Wf FPGA register 0x48. Alternatively, to route the signal through the digital tuner, set bit 13 to 1 in Wf FPGA register 0x48.
This can be achieved programmatically as follows:
```c
#include <wf_fpga/wf_fpga_ioctl.h>
int fd;
fd = open("/dev/wf_fpga", O_RDWR);
if( fd < 0 )
{
// Handle error
}
T_WF_FPGA_MEM_IO req;
req.ctrl_reg = 0x48;
if( ioctl(fd, WF_FPGA_MEM_IO_READ, &req) != 0 )
{
// Handle error
}
// Uncomment the appropriate line.
// req.val = (req.val & ~(0x2000)); // Bypass tuner
// req.val = (req.val & ~(0x2000)) | 0x0200; // Route through tuner
if( ioctl(fd, WF_FPGA_MEM_IO_WRITE, &req) != 0 )
{
// Handle error
}
```
# 4.5.2.2 Changing Sample Rates
This section outlines the capabilities of the DTP4700 for tuning the sample rates of digital signals to meet various application demands.
# 4.5.2.2.1 Baseband Tx Sample Rate
The Tx sample rate is controlled using the txSampleRate configure property on the RfCtrlDevice (see Table 4).
The baseband Tx sample rate can be changed programmatically via the configure operation exposed by the RfCtrlDevice through its supports interface and the rfctrl\_device\_ctrl provides port. To change the rate programatically from a waveform application a connection must be made to the rfctrl\_device\_ctrl port as application components are unable to connect directly to a supports interface on an SCA Device.
As an example the AssemblyController component from the DTP4700Fm example waveform controls the sample rate from the \_CF\_Resource\_start operation through its RfCtrlDeviceCtrl uses port which is connected to the rfctrl\_device\_ctrl provides port on the RfCtrlDevice. The code to change the sample rate is as follows:
```cpp
CF::Properties p;
p.length(1);
p[0].id = "txSampleRate";
p[0].value <<= (CORBA::ULong) 48000; // samples per second
RfCtrlDeviceCtrl_->configure(p);
```
# 4.5.2.2.2 Baseband Rx Sample Rate
The baseband Rx sample rate is controlled using the rxSampleRate configure property on the RfCtrlDevice (see Table 4). However, this value must be considered in the context of the additional parameters set on the digital tuner where t h i s i s n o t b y p a s s e d . T h e a c t u a l s a m p l e r a t e i s d e t e r m i n e d b y t h e rxAdcSampleRate configure property divided by the decimation rate set on the digital tuner. In addition, the cut-off frequency set on the digital tuner is expressed in terms of PI radians per sample, therefore this must be adjusted to reflect the ratio of sample rate and frequency required for the application.
The baseband Rx sample rate can be changed programmatically via the configure operation exposed by the RfCtrlDevice through its supports interface and the rfctrl\_device\_ctrl provides port. To change the rate programatically from a waveform application a connection must be made to the rfctrl\_device\_ctrl port as application components are unable to connect directly to a supports interface on an SCA Device.
As an example the AssemblyController component from the DTP4700Fm example waveform controls the sample rate from the \_CF\_Resource\_start operation through its RfCtrlDeviceCtrl uses port which is connected to the rfctrl\_device\_ctrl provides port on the RfCtrlDevice. The code to change the sample rate is as follows:
```txt
CF::Properties p;
p.length(1);
p[0].id = "rxSampleRate";
p[0].value <<= (CORBA::ULong)(48000 * 128); // samples per second
RfCtrlDeviceCtrl_->configure(p);
```
# 4.5.2.2.3 Audio Sample Rate
The AudioPortDevice component supplied as part of the DTP4700 SCA platform provides an abstraction of the Advanced Linux Sound Architecture (ALSA) drivers installed as part of the Linux operating system kernel running on the ARM core of the OMAP processing unit.
The audio sample rate set on the ALSA driver is modelled as a property type (named ‘rate’) that has the SCA property kind set as execparam. Consequently, the core framework will interpret the AudioPortDevice rate property as an executable parameter for use when the component is first instantiated. The property is not configurable and its value can only be changed at the modelling (descriptor) level. This is achieved in the same way as described in Section 4.5.1 for changing the default values of configurable properties. The default value for the sample rate used by the AudioPortDevice is 16 kilo-samples/sec.
# CHAPTER
# Sample Waveforms
A number of Spectra CX models are included in the software package supporting the DTP4700 product. These provide sample application assemblies (waveforms) for use in platform validation and testing procedures, and for general purpose SCA training.
Using Spectra CX, the sample models can be deployed as waveform applications to the DTP4700 SCA platform as described in Chapter 8.
# 5.1 Restrictions on the use of the DSP
The DTP4700 does not support dynamic reconfiguration of the DSP core of the OMAP device. Consequently, a restriction is imposed whereby a single loadable image containing all the application and kernel symbols is loaded and executed only once. The approach adopted for the DTP4700, in SCA terms, is to configure a ResourceFactory to co-locate all components required for the DSP, and package the ResourceFactory together with kernel libraries as a single image using the DSP tool-chain. At the time of deployment, an SCA device running on the ARM core as part of the DTP4700 SCA platform is used as a proxy to manage the lifecycle of the DSP image. This approach is entirely conformant with the SCA.
# 5.2 Analog Audio (DTP4700Fm)
The functional parts of the DTP4700Fm waveform consists of four SCA components (implementation of the SCA Resource interface) used to transmit and receive Frequency Modulated (FM) analog audio signals over the air interface (RF) of the Thunder hardware platform. The modulation and demodulation functions are implemented in C for deployment on the DSP processor and the up-sampling and down-sampling functions are implemented in C++ for deployment on the ARM processor. Figure 15 shows the Spectra CX model of the waveform.
Figure 15 DTP4700Fm Application Assembly model
The DTP4700Fm application assembly illustrates the use-case where the mod and demod component instances are co-located together with a resourceFactory such that these can be deployed as a single binary image to the DSP.
mod: model element represents an instance of the Mod component definition. The component instance (implementation of Resource) receives audio samples from the upsampler component instance and performs a frequency modulation on the data pushing resulting complex I&Q samples to the WfFpgaProxy component instance running on the platform.
demod: model element represents an instance of the Demod component definition. The component instance (implementation of Resource) receives complex I&Q samples from the WfFpgaProxy component instance running on the platform and performs a frequency de-modulation on the data pushing resulting audio sample data to the downsampler component instance.
upsampler: model element represents an instance of the Resampler component definition that performs rate conversion. The upsampler instance re-samples the signal received from the AudioPortDevice component running on the platform from 16 to 48 kilo-samples/sec pushing resulting samples to the mod component instance.
downsampler: model element represents an instance of the Resampler component definition that performs rate conversion. The downsampler instance re-samples the signal received from the demod component instance f r o m 4 8 t o 1 6 k i l o - s a m p l e s / s e c p u sh i n g r e s u l t i n g s a m p l e s t o t h e AudioPortDevice component running on the platform.
assemblyController: model element represents an instance of the AssemblyController component definition. Generally, the SCA requires that an assembly controller is used to delegate lifecycle operations (e.g., start/stop) to connected application components using the Resource interface. Consequently, in the case of the Analog FM application, uses port connections to all other components are modelled, including, where appropriate, with platform components using a uses device relationship.
NOTE: The general convention is adopted for the DTP4700 models where the text ‘Ctrl’ is appended to uses port names denoting components connected to the assembly controller. Note also that in the case where connections to platform components are required, an equivalent provides port is required on the platform component to represent the platform side of the resource connection.
r e s o u r c e F a c t o r y : m o d e l e l e m e n t r e p r e s e n t s a n i n s t a n c e o f t h e ResourceFactory component definition. This provides a mechanism based on a factory design pattern for co-locating runtime instances of assigned Resource types with the resourceFactory itself. In the case of the Analog FM application, this component creates the mod and demod components.
# 5.3 Digital Audio (DTP4700FskVoice)
The DTP4700FskVoice waveform can be used to transmit and receive digital audio signals over the air interface (RF) of the Thunder hardware platform.
The functional parts of the waveform consist of four SCA components (implementation of SCA Resource interface) to provide a simple digital voice link. The encoding/modulation and decoding/demodulation functions are implemented in C for deployment on the DSP processor. Figure 16 shows the Spectra CX model of the waveform.
Figure 16 DTP4700FskVoice Application Assembly model
cVSDEncoder: model element represents an instance of the CVSDEncoder component definition. The encoder accepts a digitised voice signal from the AudioPortDevice component running on the platform and encodes it using Continuously Variable Slope Delta-modulation (CVSD). The voice input is 16 kilo-samples/sec, 16 bit linear quantisation. The syllabic integrator time constant is 3.5 milliseconds. The reconstruction integrator time constant is 620 us. The 16 kilo-bits/sec encoded output is pushed to the fSKModulator component instance.
fSKModulator: model element represents an instance of the FSKModulator component definition. The fSKModulator modulates a CVSD bit stream received from the cVSDEncoder using Frequency Shift Keying (FSK). The deviation is +/- 4 kHz, and the symbol rate is 16 kilo-symbols/sec. This form of FSK is known as Minimum Shift Keying (MSK). Each symbol comprises 4 samples. The digital I&Q baseband signal at 64 kilo-samples/sec generated output is pushed to the WfFpgaProxy component instance running on the platform.
fSKDemodulator: model element represents an instance of the FSKDemodulator component definition. The fSKDemodulator receives a digital I&Q baseband signal at 64 kilo-samples/sec from the WfFpgaProxy component instance running on the platform. Demodulation is performed by deciding whether each sample represents a positive or a negative frequency. Symbol timing recovery is unsophisticated, and is achieved by looking for transitions in the demodulated sample stream. The output is a bit stream at 16 kilo-bits/sec, passed to the cVSDDecoder component instance.
cVSDDecoder: model element represents an instance of the CVSDDecoder component definition. The decoder takes the bit stream from the fSKDemodulator component instance and carries out CVSD decoding, using the same parameters as the encoder. The output is 16 kilo-samples/sec, 16 bit linear quantisation pushed to the AudioPortDevice component running on the platform.
assemblyController: model element represents an instance of the AssemblyController component definition.
r e s o u r c e F a c t o r y : m o d e l e l e m e n t r e p r e s e n t s a n i n s t a n c e o f t h e ResourceFactory component definition. In the case of the Digital Audio application, this component creates the cVSDEncoder, fSKModulator, fSKDemodulator and cVSDDecoder components.
# 5.4 Data (DTP4700FskData)
The DTP4700FskData waveform can be used to transmit and receive data over the radio link of the Thunder system. The waveform makes a connection to the PacketService on the platform which provides the necessary data source/sink over the network stack of the DTP4700. The functional part of the waveform consists of four SCA components as shown in Figure 17. The deployment of the waveform has been modelled using Spectra CX such that the modulator and demodulator are installed on the DSP, and the framer and deframer are installed on the GPP of the Thunder system.
Figure 17 DTP4700FskData Application Assembly
framer: model element contained within the DTP4700FskData assembly represents an instance of the Framer component definition in Spectra CX. The framer accepts data from an instance of the PacketService component running on the platform. The data payload is encoded using a frame delimitation scheme based on HDLC1. The resulting signal is provided as input to the modulator.
deframer: model element contained within the DTP4700FskData assembly represents an instance of the Deframer component definition in Spectra CX. The deframer accepts a digital signal from an instance of the WfFpgaProxy component running on the platform. The input signal is decoded using a frame delimitation scheme based on HDLC. The resulting data is provided as input to an instance of the PacketService component running on the platform.
modulator: model element contained within the DTP4700FskData assembly represents an instance of the Modulator component definition in Spectra CX. The component modulates the input signal received from the framer using Frequency Shift Keying (FSK) scheme. The modulator produces a digital I&Q baseband signal at 64 kilo-samples/sec for the radio link by providing the signal as input to an instance of the WfFpgaProxy component running on the platform.
demodulator: model element contained within the DTP4700FskData assembly represents an instance of the Demodulator component definition in Spectra CX. The component demodulates the digital I&Q baseband signal received from the radio link via an instance of the WfFpgaProxy component running on the platform. The demodulated signal is provided as input to the deframer.
assemblyController: model element represents an instance of the AssemblyController component definition. The control parameters supporting the data waveform are set on the RfCtrlDevice by the assemblyController programmatically on application start-up.
resourceFactory: model element contained within the DTP4700FskData assembly represents an instance of the ResourceFactory component definition. The resourceFactory is responsible for creating instances of components of type Modulator and Demodulator.
# CHAPTER
# 6 Connectivity and Communication
When forward engineering applications for the DTP4700 platform using Spectra CX, the connections between components are exclusively defined at the SCA modelling level.
The SCA definition includes all port connections between application components and those which connect waveform with platform. The communication model adopted for the DTP4700 platform ensures that components deployed onto the GPP and/or the DSP cores of the OMAP processing unit over such connections is facilitated using CORBA at the middleware level1. The actual transport used, however, is adaptable, and is typically based on the physical interconnect fabric available. In the DTP4700, the inter-device transport used for connections made between the GPP and DSP OMAP cores is based on the Message Queue Transport (MQT) from Texas Instruments. This is also used for intra-DSP connections.
# 6.1 Spectra CX Build Configurations for the DTP4700
The Spectra CX system uses a ‘build configuration’ to configure content and control elements of the code generation procedure applied to individual components. Principally, the build configuration is used to assign the required implementation language for a given component; however, additional features may be built-in that affect the capabilities of the generated code. Typically, therefore, the selection of a build configuration may determine the level of debugging support and/or enable the use of a particular message transport at the middleware level.
A series of build configurations have been packaged with Spectra CX to reflect the platform-specific capabilities of the DTP4700 system and the underlying Thunder hardware. Table 5 provides a summary of the build configurations provided.
Table 5 Spectra CX Build Configurations
| Build Configuration | Target OS/Architecture | Description |
| eorb-dspbios-cl6x::eorb20-dspbios-cl6x-linux-c-dtp4700-build | DSPBios/C6416 | C based build configuration including MSGQIOP transport only |
| eorb-dspbios-cl6x::eorb20-dspbios-cl6x-linux-c-dtp4700+ probes-build | DSPBios/C6416 | C based build configuration including MSGQIOP transport and support for Spectra DTP4700 Probe Toolbox |
| eorb20-linux-gcc-arm::eorb20-linux-gcc-arm-dtp4700+ msgqiop-build | TILinux/ARM | C++ based build configuration including MSGQIOP and IIOP transports |
| eorb20-linux-gcc-arm::eorb20-linux-gcc-arm-dtp4700+msgqiop+ probes-build | TILinux/ARM | C++ based build configuration including MSGQIOP and IIOP transports as well as support for Spectra DTP4700 Probe Toolbox |
| eorb20-linux-gcc-arm::eorb20-linux-gcc-arm-dtp4700-build | TILinux/ARM | C++ based build configuration including IIOP transport only |
| eorb20-linux-gcc-x86::eorb20-linux-gcc-x86-build | Linux/x86 | C++ based build configuration including IIOP transport only |
| eorb20-linux-gcc-x86-c::eorb20-linux-gcc-x86-c-build | Linux/x86 | C based build configuration including IIOP transport only |
Debug versions of the build configurations listed in Table 5 are also provided.
# 6.2 Modelling Platform Specific Elements
Inter-device communication between the GPP and DSP on the DTP4700 platform is facilitated at the modelling level by assigning the associated component implementation model element in Spectra CX with the appropriate build configuration (see Table 5 above and Figure 18 on page 51).
The build configuration affects code generation for the component to which it is assigned, including the installation of the required transport to be used for the connections made at runtime between component ports. All data transports are integrated at the middleware level using the Extensible Transport Framework (ETF)
of the Spectra ORB, however, this procedure is entirely transparent to the end-user. In the case of connectivity with the DSP the native DSP/BIOS Message Queue transport mechanism from Texas Instruments is used.
Figure 18 Definition of Demod Component
# 6.3 Connecting Waveform with Platform
There are currently three SCA platform services provided with this version of the DTP4700: one for audio, one for making connections to the network interface, and one for the radio link (RF/Transceiver sub-system). These are provided by the AudioPortDevice, the PacketService, and by a combination of the RfCtrlDevice and WfFpgaProxy components supporting the radio link respectively. The latter provides an SCA abstraction of the low-level Wf FPGA device driver libraries allowing configuration and control of the Thunder RF/Transceiver sub-system hardware, and a connection for exchanging sampled complex baseband signal data for the RF transmit and receive paths.
This section of the User Guide provides guidance for modelling connections between application components and DTP4700 platform components. In general waveform components (CF::Resource) connect to the platform by specifying uses device dependencies based on allocation properties defined by the DTP4700 platform. Table 6 shows the allocation properties defined by the various DTP4700 platform components and the value required to create a connection.
Table 6 DTP4700 Platform Allocation Properties
| Component | Ports | Properties |
| Demod | dataIn: Exposes the UshortStream interface for incoming interleaved I&Q data and control | No configurable properties |
| dataOut: Sends sample data via the SampleStream interface |
| Resampler | dataIn: Exposes the SampleStream interface for incoming UshortStream data and control | numerator: A CORBA::short to hold the FIR filter numerator value.The numerator value is used in rate conversion such that output rate = input rate (numerator/denominator) |
| dataOut: Sends filtered data via the SampleStream interface | denominator: A CORBA::short to hold the FIR filter denominator value.The denominator value is used in rate conversion such that output rate = input rate (numerator/denominator) |
| filterGainAdj: A CORBA::short to hold the gain adjust for the FIR filter1 |
| FilterCoeffs: A sequence of CORBA::short values to hold the fixed-point filter coefficients for the FIR filter |
1. The filterGainAdj property on the Resampler is set with a default gain at the output of the filter of -32768 to adjust the dynamic range. The gain adjustment is applied in addition to the default gain. A filterGainAdj of 0 would leave the default gain unchanged.
Each filter output sample is shifted by N bits, where N > 0, the shift is to the left; where N < 0, the shift is to the right, and N is given by:
filterGainAdj > 0: round( log base 2( filterGainAdj ) ) – 15 or
filterGainAdj < 0: round( -log base 2( -filterGainAdj ) ) – 15
# 8.2 The FM Tutorial Step-by-step
# 8.2.1 Starting Spectra CX
For convenience a link is provided under the PrismTech menu under Spectra > DTP4700 > Workspaces > Spectra CX (DTP4700 workspace) on the host development system desktop that can be used to open a pre-existing Spectra CX workspace containing all the supplied model projects.
If starting Spectra CX using the above link, please continue this tutorial from Section 8.2.4, Generating DTP4700 Platform Artefacts, on page 73.
Alternatively to run Spectra CX creating a new workspace, choose IBM Software Delivery Platform > IBM Rational Software Architect 9.1 from the PrismTech menu, then continue this tutorial from Section 8.2.2, Choosing a Workspace, below.
# 8.2.2 Choosing a Workspace
When you start Spectra CX a dialog appears for you to choose where to locate your workspace. A workspace is a folder where the projects that you create will be stored. If you do not specify a workspace, a default workspace will be created for you.
Click OK when you have decided on your workspace location.
Figure 25 Select or create a workspace
The first time you open Spectra CX or create a new workspace, you will see a ‘Welcome’ screen.
Close the Welcome screen by clicking X on the tab or by clicking the Workbench icon (circled in Figure 26 below).
Figure 26 The ‘Welcome’ screen
The illustration overleaf (Figure 27) shows the default Workbench layout before any projects have been created.
Figure 27 Default Workbench showing empty workspace
If you already have projects under development in Spectra CX then those projects are displayed in the Project Explorer pane. If, however, this is your first project, then the Project Explorer will show no projects in your workspace.
To w o r k w i t h D T P 4 7 0 0 m o d e l s , t h e t o o l m u s t b e s w i t c h e d t o t h e Spectra CX Modeling perspective.
F i g u re 2 8 , F i g u re 2 9 a n d F ig u re 3 0 s h o w h o w t o s w i t c h i n t o t h e Spectra CX Modeling perspective.
Figure 28 Click the Open Perspective button (circled)
Figure 29 Open the Spectra CX Modeling perspective
Figure 30 The Spectra CX Modeling environment ready to start
# 8.2.3 Importing the DTP4700 Tutorial Packages
To import the DTP4700 tutorial packages into the workspace, perform the following steps.
Step 1: On the menu bar, choose File > Import; the dialog shown in Figure 31 will appear.
Figure 31 The Import Wizard
Step 2: Select Existing Projects into Workspace and click Next.
Step 3: Click the radio button for Select archive file and click the Browse button.
Step 4: Locate and select the zip file that contains the DTP4700 projects (projects are stored in /opt/dtp/models.zip).
i The models.zip archive contains five model projects:
- DTP4700: the DTP4700 SCA platform model.
- DTP4700Fm: the analog FM audio waveform used in this tutorial.
- DTP4700FskData: the data waveform which uses FSK modulation.
- DTP4700FskVoice: the digital audio waveform which uses CVSD encoding and FSK modulation.
- x86: additional platform nodes that can be used to deploy application components to the host development system.
Step 5: Click OK to use the selected archive.
Step 6: Click Finish to complete the import operation.
Step 7: The DTP4700 Platform and Tutorial FM waveform now appear in the Project Explorer pane.
Figure 32 Project Explorer showing imported projects
# 8.2.4 Generating DTP4700 Platform Artefacts
This section describes how to generate the domain profile and code for the DTP4700 platform.
Step 1: In the Project Explorer, expand the DTP4700 project, navigate to Models > DTP4700 > DTP4700, and double-click the DTP4700 diagram element in the tree.
Figure 33 DTP4700 diagram element selected in Project Explorer
This will display the diagram showing the platform model element containing an instance of the DTP4700Node named dtp4700Node. This is shown in Figure 34.
Figure 34 The DTP4700 Platform Model Element
Step 2: Double-click the DTP4700Node diagram element in the tree. This will display the diagram showing the DTP4700Node and the component instances contained within it, as shown in Figure 35.
Figure 35 Components in the DTP4700Node
# 8.2.4.1 Generating DTP4700 SCA Descriptors
This section describes how to generate the XML domain profile for the DTP4700 platform.
Step 1: In the DTP4700 diagram, right-click on DTP4700 platform to open its context menu, then choose Generate > Descriptor(s).
Figure 36 Generating SCA Descriptors
When the platform descriptors have been generated, the console will show validation status, errors, and warnings.
Figure 37 After generating Platform Descriptors
In Figure 37 the Console tab shows the results of the Model Validation Procedure.
# 8.2.4.2 Generating DTP4700 SCA Source Code
This section describes how to generate source code for the DTP4700 platform.
Step 1: On the DTP4700 diagram, right-click the DTP4700 platform component, then choose Generate > SCA Code from the context menu.
Figure 38 Generating SCA Source Code
Following the generation of descriptors and binaries from the platform model element, the Project Explorer view in Spectra CX will display two new folders in the workspace containing the generated files. The convention for folder names is configurable using Spectra CX, in this case DTP4700\_src will contain the descriptors, and DTP4700\_src\_CPP will contain the binaries. Note in Figure 39 that the code generation procedure also generated the required build instructions resulting in the new elements being displayed in the Make Target view.
i
Please note that the DTP4700 platform models reference existing binaries and therefore no source code will be generated. During generation the pre-existing binaries are copied into the obj directory underneath the source project. If the platform is extended then source code will be generated for any new components.
Figure 39 Workspace projects containing the generated files
# 8.2.5 Building the DTP4700 Platform
To build the DTP4700 platform:
Step 1: Left-click the DTP4700\_src\_CPP folder in the Make Target view to expand the target elements.
Step 2: Double-click the all target (see Figure 40).
i Please note that as no code is generated for the DTP4700 platform components then during the Make Targets step no code will be compiled. Instead the makefile copies the pre-existing binaries referenced by the components into the obj directory underneath the source project.
Figure 40 Building the DTP4700 platform
# 8.2.6 Generating the FM Waveform Artefacts
This section describes how to generate profile descriptors and source code for the tutorial FM waveform.
Step 1: In the Project Explorer, expand the folders DTP4700Fm > Models > DTP4700Fm > DTP4700Fm, and double-click the DTP4700Fm diagram model element to display the application assembly diagram as shown in Figure 41.
Figure 41 Application Assembly Diagram for the FM waveform
# 8.2.6.1 Generating FM Waveform SCA Descriptors
To generate domain profile descriptors for the FM tutorial waveform, right-click the DTP4700Fm application and then choose Generate > Descriptor(s) from the context menu.
Figure 42 Generating Descriptors
# 8.2.6.2 Generating FM Waveform SCA Source Code
The DTP4700Fm project contains a combination of C and C++ components. To generate source code for the tutorial FM waveform:
Step 1: To generate C++ code, right-click the DTP4700Fm application and choose Generate > SCA Code from the context menu.
Figure 43 Generating C++ source code
Step 2: To generate C code, right-click the DTP4700Fm application and choose Generate > SCA C Code from the context menu.
Figure 44 Generating C source code
i Both C and C++ code, as well as descriptors, can also be generated by choosing Generate > All.
When the waveform descriptors and SCA code have been generated, projects containing the generated files will appear in the Project Explorer view:
DTP4700Fm\_src contains the descriptor files
DTP4700Fm\_src\_CPP contains the C++ code files
DTP4700Fm\_src\_C contains the C code files
Figure 45 Generating All
Figure 46 shows the generated projects in the Project Explorer.
Figure 46 Generated projects
# 8.2.7 Building the FM Waveform
To build the waveform:
Step 1: Click to expand the DTP4700Fm\_src\_CPP folder in the Make Target view.
Step 2: Double-click on the all target element to compile and link the C++ source code.
Step 3: Click to expand the DTP4700Fm\_src\_C folder in the Make Target view.
Step 4: Double-click on the all target element to compile and link the C source code.
Figure 47 Compiling and Linking
# 8.2.8 Packaging XML and Binaries for Deployment
Before running the generated platform and waveform it is first necessary to package the generated XML and binaries into a bundle on the target file system which is suitable for deployment.
# 8.2.8.1 Platform
Step 1: Open the Ubuntu File Browser by clicking the Home Folder icon on the Unity Launcher.
Step 2: From the Computer list in the File Browser select File System.
Step 3: Navigate to the target file system: mnt > targetfs.
Step 4: Navigate to the opt > dtp > platform directory on the target file system.
Step 5: In Spectra CX select the platform descriptors folder (found under the DTP4700\_src project) and drag the folder into the platform directory in the Ubuntu file browser.
Step 6: In the Ubuntu File Browser rename the descriptors folder to be xml-DTP4700-tutorial.
i The generated XML is configured to expect the platform binaries to be in the ../bin directory. As the platform binaries are already present in the appropriate location there is no need to copy the binaries onto the target file system.
# 8.2.8.2 Waveform
Step 1: Open the Ubuntu File Browser by clicking the Home Folder icon on the Unity Launcher.
Step 2: From the Computer list in the File Browser select File System.
Step 3: Navigate to the target file system: mnt > targetfs.
Step 4: Navigate to the opt > dtp > applications directory on the target file system.
Step 5: In Spectra CX select the waveform descriptors folder (found under the DTP4700Fm\_src project) and drag the folder into the applications directory in the Ubuntu file browser.
Step 6: In the Ubuntu File Browser rename the descriptors folder to be DTP4700Fm-tutorial.
Step 7: Copy the Demod.out, Mod.out and ResourceFactory.out binaries from Spectra CX (found under the obj directory in the DTP4700Fm\_src\_C project) to the DTP4700Fm-tutorial directory in the Ubuntu File Browser.
Step 8: Copy the AssemblyController and Resampler binaries from Spectra CX (found under the obj directory in the DTP4700Fm\_src\_CPP project) to the DTP4700Fm-tutorial directory on the Ubuntu File Browser.
# 8.2.9 Creating a DTP4700 SD Card
A utility script (mksdboot.sh) is provided in the /opt/dtp/bin directory of the LiveUSB system to create a bootable SD card for the DTP4700 system. Please refer to Section 3.1.1.5, Utility Scripts, on page 16, for instructions on using this script.
The script will create a file system consisting of the TI Linux operating system and a copy of the target file system from the host. The target file system contains several platform and waveforms including the ones copied onto the target file system in Section 8.2.8, Packaging XML and Binaries for Deployment, on page 87.
i When running the mksdboot.sh script you will be asked to choose which platform version you would like to be run when the target system boots. Select 3: Other and then enter xml-DTP4700-tutorial as the name of the platform.
Ensure the SD card is plugged into the Thunder system’s SD/MMC slot before booting the target system.
# 8.2.10 Running the FM Waveform
This section describes how to run the compiled example FM Waveform on the DTP4700 platform.
# 8.2.10.1 Configuring Ubuntu Host Network
By default the Ubuntu host system is configured to acquire an IP address via DHCP, but the Thunder system is configured with a static IP address. In such a configuration the two systems will not be able to communicate.
To configure the Ubuntu host system with a static IP address compatible with the Thunder target:
Step 1: Left-click the PrismTech icon on the system menu to activate the PrismTech menu.
Step 2: From the PrismTech menu choose Spectra > IP Address > Switch to Static IP.
Figure 48 Setting a static IP address
# 8.2.10.2 Connecting Spectra CX Monitor to DTP4700
The monitor object in the model contains details of the DTP4700 and how to connect to it. The details of how to connect to a NameService and the name under which the SCA DomainManager is registered is contained in the Monitor. The values can be modified if required.
To connect to the platform, first open the SCA Monitor:
Step 1: In the Project Explorer, expand the folders DTP4700 > Models > DTP4700, and right-click on Monitor.
Step 2: Choose Open SCA Monitor (see Figure 49).
Figure 49 Opening the SCA Monitor
Connecting to the DTP4700 will display the running SCA platform, as shown in Figure 50.
Figure 50 Monitor showing running SCA platform
i In the Monitor view, the DomainManager and DeviceManager are implicit, and are therefore not displayed in the Control or Deployment panes.
# 8.2.10.3 Installing the FM Waveform
To install the FM Waveform:
Step 1: Right-click Applications and from the pop-up menu choose Install Application Factory.
Step 2: Select /DTP4700Domain/DTP4700Node/applications/DTP4700Fm-tutorial/DTP4700Fm.s ad.xml
Figure 51 Installing the FM Waveform
# Step 3: Click OK.
When the application is successfully installed, its Application Factory is displayed in the Control pane (see Figure 52).
Figure 52 FM Waveform successfully installed
# 8.2.10.4 Creating the FM Waveform
To create an instance of the FM Waveform from the installed Application Factory:
Step 1: Right-click the DTP4700Fm application and choose Create Application.
Step 2: Enter a name for the instance (for this example, the name is “a1”).
Figure 53 Naming the new application instance
Step 3: Click OK.
Figure 54 Successful creation of an application instance
Figure 54 shows a successful instantiation of the DTP4700Fm application. The Deployment pane shows the instantiated waveform components of the application a1 running on the DTP4700 SCA platform components.
i The components that were deployed on the DSP device appear greyed-out in the Monitor as these components do not implement the IIOP transport profile so the Monitor cannot communicate with them. In such a case the Monitor displays only the information present in the XML descriptors for the component. The cfadmin utility that runs on the Thunder target hardware can be used to view the details of all running waveform components including those based on transports other than IIOP. Please refer to Section 8.3, Running the FM Tutorial using cfadmin, on page 102 for more details.
# 8.2.10.5 Starting the FM Waveform
To start the newly-created instance of the application:
Step 1: Set the Transmit Frequency.
Select the rfCtrlDevice in the Control pane and switch to the Properties view, then select the SCA Properties tab. Select the txFrequency property and set the value to the frequency you wish to transmit on.
NOTE: If transmitting over the air, please ensure that the frequency chosen is legal in your country.
Step 2: Set the Receive Frequency.
Select the rfCtrlDevice in the Control pane and switch to the Properties view, then select the SCA Properties tab. Select the rxFrequency property and set the value to the frequency you wish to transmit on.
i To run the application in loopback mode the transmit and receive frequencies must be compatible. This could be achieved by setting the Rx and Tx frequencies to the same value. However it is recommended that the Rx frequency should be configured to be +60Hz or -60Hz of the Tx frequency. Please refer to the DTP4700 Release Notes for more details.
Figure 55 Setting the Transmit Frequency
Step 3: Choose Start from the application’s context menu.
Figure 56 Choose Start from the context menu
i Output from the running application is written to the file /var/log/dtp.log. The application should now be running in receive mode. To enable transmission of FM audio from the Audio In port:
Step 1: Enable ptt (push to talk).
Select the audioPortDevice in the Control pane and switch to the Properties view, then select the SCA Properties tab. Select the ptt property and set the value to true.
Figure 57 Setting the ptt property
To disable transmission of FM audio:
Step 1: Disable ptt.
Select the audioPortDevice in the Control pane and switch to the Properties view, then select the SCA Properties tab. Select the ptt property and set the value to false.
# 8.2.10.6 Stopping the FM Waveform
To stop the running application instance:
Step 1: In the Control pane, right-click on the instance a1 of the application DTP4700Fm.
Step 2: Choose Stop from the context menu.
Figure 58 Stopping a running application instance
Stopping the application halts the processing of audio samples.
# 8.2.10.7 Releasing the FM Waveform
To release the resources of the stopped application instance:
Step 1: In the Control pane, right-click on the instance a1 of the application DTP4700Fm.
Step 2: Choose Release from the context menu.
A successful release will tear down the application instance and it will disappear from the Application folder in the Control pane (see Figure 59 and Figure 60). The relevant components also disappear from the Deployment pane.
Figure 59 Releasing a stopped application instance
Figure 60 Application instance successfully released
# 8.2.10.8 Uninstalling the FM Waveform
To uninstall the FM Waveform application:
Step 1: In the Control pane, right-click on the DTP4700Fm application.
Step 2: Choose Uninstall from the context menu.
Successfully uninstalling the application removes the waveform from the DTP4700 platform (see Figure 61 and Figure 62).
Figure 61 Uninstalling an application
Figure 62 Application successfully uninstalled
# 8.3 Running the FM Tutorial using cfadmin
The CF platform comes with a console-based utility, cfadmin, to control the lifecycle of SCA waveforms. cfadmin runs on the Thunder target so that it can interact with all application and platform components.
i This section only gives an example of how to start cfadmin; please refer to the Spectra CF User Guide for a full description of cfadmin, and for step-by-step instructions showing how to use it to install, create, start, stop, release and uninstall waveforms.
# 8.3.1 Starting cfadmin
Step 1: Open a serial console (GtkTerm, telnet or SSH) session on the Thunder system and log in as root.
Step 2: Start cfadmin, passing it the reference of the Naming Service started by the DomainManager:
```txt
cfadmin -ORBInitRef
NameService=corbaloc:iiop:1.1@172.31.255.1:2809/NameService
-NAME_BINDING /DTP4700Domain/DomainManager
```
cfadmin will display a text menu of options to display and manage various aspects of the domain. Entering ‘V’ at the menu prompt will display all components that belong to the domain, including application factories, applications (and their resources), device managers, devices and services.
Figure 63 cfadmin output confirming application has been created
In Figure 63 above, the application a1 shows that it is comprised of six resources. cfadmin only displays the instantiation UUIDs of the components as defined in the SAD XML descriptor. An annotated listing of the application components is shown below:
```txt
DCE:89e1a725-ffe8-4917-91a6-6de669eab1a2: a1 [downsampler]
DCE:eb68c78c-47ed-4030-9aca-a0d7bdb6a4bf: a1 [upsampler]
DCE:1b84de4a-6129-4915-aac5-8cd7e2a3a5d7 [demod]
DCE:a56c8d6e-ce23-46a6-b3fc-e4574ccea384 [mod]
DCE:d1f8b818-a109-4cea-ba11-168c56078e97: a1 [resourceFactory]
DCE:ac77eb92-0bbb-47e1-8a05-8a47a9859ea6: a1 [assemblyController]
```
[🔗 Link to the original document](.spectra-dtp4700-userguide/spectra-dtp4700-userguide.pdf)