The Universal Radio Communication Tester R&S CMU is a modular platform supporting a wide range of network standards with specific, preconfigured measurements and generators. For the remainder of this section, measurements and generators are both termed Objects.
In general, the testers are capable of running several objects in parallel. E.g. the GSM900 RF generator can be used to establish a connection to a mobile station under test, and to perform a Receiver Quality and a Modulation measurement simultaneously. Conflicts between different objects may occur if they rely upon the same system resources.
The Task Priority Management parameter in the Setup – Remote tab provides a control mechanism for conflicting objects, leaving it up to the user’s choice whether a running object should persist, or whether it should be released when the next object is initiated.
|
Persistent Objects |
If Task Priority Management is disabled, all objects are persistent. This means that a running object (measurement state RUN) has priority over any new object that is in conflict with the running object. If an attempt is made to initiate a new object, the CMU generates the SCPI error –213, Init ignored. The old object continues to be executed, whereas the new object remains in the OFF state. To start a new object, it is necessary to abort the running object explicitly or wait until valid results are available and the measurement status is RDY (for measurement objects only; see Conflicting Measurement Objects).
|
|
Releasable Objects |
If Task Priority Management is enabled, all objects are releasable. This means that any new object has priority over a running object (or several running objects, measurement state RUN) that is in conflict with the new object. If a new object is initiated, the CMU aborts the running object. The old object enters the OFF state, whereas the new object enters the RUN state. A new object can be started without delay irrespective of the instrument state.
|
|
Selection Criteria |
Whether to attribute the priority to running or to new objects depends on the measurement task and the preferences of the programmer, see examples below.
|
|
Examples |
The following examples illustrate the different behavior of the instrument for the two task priority schemes. The remote control commands are taken from the GSM900-MS Non Signalling and GSM900-MS Signalling function groups. |
Consider the RF Generator in Non Signalling mode and the BS Signal generator in Signalling mode. The two generator objects are in conflict. The generator states can be queried by means of FETCh:RFGenerator:STATus? (Non Signalling) and SIGNalling:STATe? (Signalling), using the appropriate secondary addresses.
|
Command Sequence |
Current Scheme: |
Alternative Scheme: |
||
|
|
Object 1: |
Object 2: Signalling Generator (BS Signal) |
Object 1: |
Object 2: Signalling Generator (BS Signal) |
|
*RST |
OFF |
OFF |
OFF |
OFF |
|
Sec_Addr. 1: INITiate:RFGenerator |
RUN |
OFF |
RUN |
OFF |
|
Sec_Addr. 2: PROCedure:SIGNalling:ACTion SON |
RUN |
OFF (—> Init ignored) |
OFF |
SON |
Assume that two measurements <Meas_1> and <Meas_2> are in conflict. The status of the measurements can be queried by means of FETCh:<Meas_1>:STATus? and FETCh:<Meas_2>:STATus?. If <Meas_1> is terminated using a FETCh:<Meas_1>? command before <Meas_2> is initiated, then the two task priority schemes are equivalent.
|
Command Sequence |
Current Scheme: Persistent Objects |
Alternative Scheme: Releasable Objects |
||
|
|
Object 1: |
Object 2: |
Object 1: |
Object 2: |
|
*RST |
OFF |
OFF |
OFF |
OFF |
|
INITiate:<Meas_1> |
RUN |
OFF |
RUN |
OFF |
|
INITiate:<Meas_2> |
OFF |
RUN |
OFF |
RUN |
Assume that two measurements <Meas_1> and <Meas_2> are in conflict. The status of the measurements can be queried by means of FETCh:<Meas_1>:STATus? and FETCh:<Meas_2>:STATus?.
|
Command Sequence |
Current Scheme: Persistent Objects |
Alternative Scheme: Releasable Objects |
||
|
|
Object 1: |
Object 2: |
Object 1: |
Object 2: |
|
*RST |
OFF |
OFF |
OFF |
OFF |
|
INITiate:<Meas_1> |
RUN |
OFF |
RUN |
OFF |
|
INITiate:<Meas_2> |
RUN |
OFF (—> Init ignored) |
OFF |
RUN |
|
FETCh:<Meas_2>? |
RUN |
OFF (results: NAN) |
OFF |
RDY (valid results) |
|
FETCh:<Meas_1>? |
RDY (valid results) |
OFF |
OFF (results: NAN) |
RDY |
Assume that <Signalling_i> and <Meas_i> (I = 1, 2) denote the BS Signal generator and a measurement in function groups GSM900 and GSM1800, respectively. The two generator objects are in conflict, and so are the measurement objects which we assume to rely upon the generator signals.
The generator states can be queried by means of SIGNalling:STATe? (Signalling), using different secondary addresses. The status of the measurements can be queried by means of FETCh:<Meas_1>:STATus?, again using the appropriate secondary addresses.
|
Command Sequence |
Current Scheme: Persistent Objects |
|||
|
|
<Signalling_1> |
<Meas_1> |
<Signalling_2> |
<Meas_2> |
|
*RST |
SOFF |
OFF |
SOFF |
OFF |
|
Sec_Addr. 1: |
SON |
OFF |
SOFF |
OFF |
|
Sec_Addr. 1: |
SON |
RUN |
SOFF |
OFF |
|
Sec_Addr. 1: |
CEST |
RUN |
SOFF |
OFF |
|
Sec_Addr. 2: |
CEST |
RUN |
SOFF —> Init ignored) |
OFF |
|
Sec_Addr. 2: |
CEST |
RUN |
SOFF |
OFF (—> Init ignored) |
|
Command Sequence |
Alternative Scheme: Releasable Objects |
|||
|
|
<Signalling_1> |
<Meas_1> |
<Signalling_2> |
<Meas_2> |
|
*RST |
SOFF |
OFF |
SOFF |
OFF |
|
Sec_Addr. 1: |
SON |
OFF |
SOFF |
OFF |
|
Sec_Addr. 1: |
SON |
RUN |
SOFF |
OFF |
|
Sec_Addr. 1: |
CEST |
RUN |
SOFF |
OFF |
|
Sec_Addr. 2: |
SOFF |
OFF |
SON |
OFF |
|
Sec_Addr. 2: |
SOFF |
OFF |
SON |
RUN |
