Programming with the ALE and ALEPC APIs

Writing Tags by Using the ALEPC API

The following sections describe the ALEPC API programming components that you use to write tags and include a formal, abstract specification of the ALEPC API. The external interface is defined by the ALEPC interface (See ALEPC: Main Tag Writing Interface with UML Diagrams). This interface makes use of a number of complex data types that are documented in the sections starting at PCSpec. BEA extensions to the interface are described in BEA Gen2 Write Support.

Overview of the ALEPC API Implementation

One or more clients make method calls to the ALEPC interface. Each method call is a request, which causes the ALE engine to take some action and return results. Thus, methods of the ALEPC interface are synchronous.

The ALEPC interface also enables clients to subscribe to events that are delivered asynchronously. You implement this capability by invoking methods that take a URI as an argument. Such methods return immediately, but subsequently the ALE engine within the Edge Server can asynchronously deliver information to the consumer denoted by the URI argument.

In the sections that follow, the API is described by using UML class diagram notation, as shown below:

The box as a whole refers to a conceptual class, having the specified data members and methods.

The ALEPC API is realized in several equivalent forms within WebLogic RFID Edge Server:

Each of these concrete forms of the ALEPC API has a slightly different structure and gives slightly different names to the different conceptual classes, data members, and methods defined in the UML within these sections. This variation is unavoidable, owing to syntactic constraints and stylistic norms within these different implementation technologies.

In most cases, the mapping from conceptual UML to the concrete details of any particular binding is very straightforward; where it is not, the specific documentation for each binding will make clear the relationship to the UML. The UML-level descriptions in these sections should be considered normative.

ALEPC: Main Tag Writing Interface with UML Diagrams

ALEPC is the main interface that you use to program tags. The term "tag programming" refers to the act of associating an EPC value with some physical entity, such as an RFID tag or a printed label.

The Java implementation package is com.connecterra.alepc.api. Also see "BEA Gen2 Write Support" on page 6-31.

PCSpec

A PCSpec is a complex type that describes a programming cycle. A programming cycle is an interval of time during which a single tag is written and verified.

Java implementation package: com.connecterra.alepc.api. See also "BEA Gen2 Write Support" on page 6-31.

The following sections provide information about a PCSpec:

A PCSpec contains:

A PCSpec also contains an optional "application data" string, which is simply copied unmodified into every PCWriteReport instance generated from this PCSpec.

For a narrative description of programming cycles and their use of PCSpec instances, see Programming Cycles.

PCSpecInfo

Java implementation package: com.connecterra.alepc.api

Describes administrative information for a PCSpec.

PCSubscriptionControls

Java implementation package: com.connecterra.alepc.api

Describes how to handle failures in notification delivery. It is used by PCSubscriptionInfo (see PCSubscriptionInfo) and ALEPC.subscribe(String, URI, PCSubscriptionControls). Also see ALEPC: Main Tag Writing Interface with UML Diagrams).

PCSubscriptionInfo

Java implementation package: com.connecterra.alepc.api

Describes administrative information about a subscription.

AccessSpec

An AccessSpec contains an ordered list of OpSpec objects and a name. The list of OpSpecs represent the sequence of operations to be performed on each tag in field. The base OpSpec class is abstract; each subclass of OpSpec refers to a specific command.

The Java implementation package is com.connecterra.alepc.api.See also "BEA Gen2 Write Support" on page 6-31.

The following sections provide information related to an AccessSpec:

Java and XML Implementation Notes:

An <accessSpec> element (repeatable) in a PCSpec describes what commands to issue to each tag in a field, as they are "singulated." An accessSpec has a name in order to match it with an accessReport included in a PCWriteReport.

An accessSpec can contain a <stopOnError> subelement, which contains a Boolean value. If stopOnError is true, for any given tag, any error in an operation will halt processing for that tag. The inventory round then continues to the next tag in the field, and processing starts on that tag with the first operation. If omitted, stopOnError is assumed to be false.

A PCSpec that contains no accessSpec element acts as if it has a single implicit accessSpec element with a single write operation. If the PCSpec contains a cacheName element, the writeOpSpec uses that value for its epcCache. This is the only point at which the top-level cacheName element is used. Otherwise, the write specifies a param value of epc, which will be substituted using the data from the poll or immediate ALEPC API call.

If restrictSingleTag was specified in the PCSpec, explicitly or implicitly (through the lack of accessSpecs), the PCWriteReport contains the epc element which contains the EPC value of the single tag written. This element is omitted in the PCWriteReport of any PCSpec that does not restrict operations to a single tag, whether one more multiple tags were discovered in the field. Additionally, a PCSpec that contains no accessSpec element will use the older form of PCWriteReport, containing no opReport.

OpSpec

Java implementation package: com.connecterra.alepc.api

The base OpSpec class is abstract; each subclass of OpSpec refers to a specific command: LockOpSpec, KillOpSpec, PasswordOpSpec, ReadOpSpec, WriteOpSpec.

Each <accessSpec> element contains an <operations> subelement, which is the list of opSpecs that describe the commands to issue to each tag ("operations"). These operations are read, write, password, lock, and kill.

There are two URI forms for specifying a memory location on a tag for a read or write operation:

For absolute addressing, the URI needs to include a selection for bank, an offset within the memory bank, and a length of the memory extent, in bits.

urn:connecterra:tagmem:@bankid.length[.offset]

Where bankid is, in Gen2, one of the four values: epc, tid, user, or reserved. Length and offset are integer values in bits, specified as decimal. The default offset value is 0.

When referring to a symbolic name, the URI simply includes the name.

urn:connecterra:tagmem:name

In the current implementation, the only valid value for name is epc.

For a stack light device, the bankid has one value: stacklight. The memory bank is 20-bits wide, and each 4-bit segment corresponds to one light. For example, urn.connecterra:tagmem:@stacklight.4.12 and value urn:epc:raw:64.x9 will turn on the amber light.

The following code fragment demonstrates programmatic stack light control. The update value of 092F0 will turn off the White light (0), turn on the Blue light until next update (9), turn on the Green light for 10 seconds (2), do nothing to the Amber light (F), and turn off the Red light (0):

ALEPC alePCClient = new AxisALEPCClient(<alepcServiceURL>);
ALEPCFactory alePCFactory = AxisALEPCFactory.getInstance();
PCSpec pcSpec = alePCFactory.createPCSpec();
pcSpec.addLogicalReaderName("StackLight");
alePCClient.immediate(
             pcSpec, new URI("urn:connecterra:stacklight:update=092F0"));

For more information on stack light control, see Configuring and Controlling Stack Lights in the RFID Reader Reference manual.

A <read field="..."> element is used to read from a segment of tag memory. The field attribute contains the URI to the tag memory location. The resulting opReport contains the status and the read memory value. Data is padded as a 64-, 96-, or 128-bit value before being returned. For example, 48 bits of data would be returned as a padded 64-bit value.

A <write field="..."> element is used to write a segment of tag memory. The field attribute contains the URI to the segment tag memory location to write. The write operation contains one of three elements that can provide the data to be written to the specified memory. These elements, called data elements, are:

A <password> element attempts to transition the tag to secured mode. The password operation contains one of the data elements specified above in the <write> element description - this data is used as the password in the Gen2 "access" operation. It is an error to use an epcCache data element for this element.

A <lock> element contains a mask element and a value element, both of which should contain a raw URI that provides an integer value. These raw URIs should be 10-bits wide when operating with Gen2 tags. For any of the bits in the mask element that are set, the corresponding lock bit on the tag is set to the bit in value at that position.

A 10-bit value is provided for the "mask" and "value" of the lock command. In the mask, the bits that are set map to the bits in the value, to be applied to the state.

In each field, the high bit represents the "lock" value for that field, while the low bit represents the field's "permalock" value.

For the EPC, TID, and User memory fields:

For the password fields:

Note the differences between the meanings for the bits in the two types of fields.

Lock operations are described in fuller detail in EPC Radio-Frequency Identity Protocols Class-1 Generation-2 UHF RFID Protocol for Communications at 860 MHz-960 MHz, Version 1.0.9.

A <kill> element contains the kill password, which will be used to kill the tag. You specify this password using the same data subelement that the <password> element uses. It is an error to use an epcCache data element for this element.

For XML examples, see Gen2 PCSpec Examples.

DataSpec

Java implementation package: com.connecterra.alepc.api

The base DataSpec class is abstract. Public implementations are: LiteralDataSpec, EPCCacheDataSpec, and ParamDataSpec.

PCWriteReport

Java implementation package: com.connecterra.alepc.api

A PCWriteReport describes the tag writing operation of a programming cycle.

The following sections provide information related to a PCWriteReport:

AccessReport

Java implementation package: com.connecterra.alepc.api

An AccessReport contains the name of the associated accessSpec. Each <accessReport> element contains a list of <tag epc="epc"> elements, one per tag detected in field.

TagReport

Java implementation package: com.connecterra.alepc.api

A TagReport contains the EPC of the tag, and an ordered list of OpReport objects. There is a one-to-one correspondence between each OpReport in the named AccessReport and each OpSpec in the corresponding AccessSpec, and the ordering is preserved.

OpReport

Java implementation package: com.connecterra.alepc.api

An OpReport contains a status element that reports the operation was successful or provides failure information. For read and write operations, the opReport also contains memory operation results. These results include a field element that matches the memory bank URI specified in the original opSpec, and a value element that gives the value of the memory as a URI.

In the case of a write, the format of the value URI is exactly as provided as input - the literal write value, the parameter value, or the EPC URI provided by the cache. For a read, the value is formatted as described in the includedMemory

PCStatus

Java implementation package: com.connecterra.alepc.api

PCStatus is an enumerated type that identifies the termination status of a programming cycle.

PCTerminationCondition

Java implementation package: com.connecterra.alepc.api

PCTerminationCondition is an enumerated type that describes the conditions that can cause a programming cycle to terminate with a failure.

EPCCacheSpec

Java implementation package: com.connecterra.alepc.api

An EPCCacheSpec describes a tag cache.

The following sections provide information related to an EPCCacheSpec:

EPCCacheReport

Java implementation package: com.connecterra.alepc.api

An EPCCacheReport indicates that an EPC cache is low.

EPCCacheSpecInfo

Java implementation package: com.connecterra.alepc.api

Describes administrative information about an EPC cache.

EPCPatterns

Java implementation package: com.connecterra.alepc.api

A list of EPC pattern URIs.

XML Representations

The focal points of the ALEPC tag writing interface from an application perspective are the PCSpec, PCWriteReport, EPCCacheSpec, and EPCCacheReport objects. The RFID Edge Server provides a standard means of representing instances of these objects in XML. The XML form of PCWriteReport and EPCCacheReport is used by most of the asynchronous delivery mechanisms, as described in Asynchronous Notification Mechanisms. The XML forms are also very useful to user applications as a means of interchange, and for persistent storage.

The XML forms are defined by the XSD schema. This schema is in the RFID Edge Server installation in the file share/schemas/ALEPC.xsd.

The Java binding for ALE provides XML serializer and deserializer classes for translating between the XML representation and the Java representation of the PCSpec, PCWriteReport, EPCCacheSpec, and EPCCacheReport types. Applications can use these facilities to process reports received via the Edge Server's asynchronous delivery mechanisms, and for other purposes. See Using XML Serializers and Deserializers from Java for more information.

The following sections present examples of PCSpec, PCWriteReport, EPCCacheSpec, and EPCCacheReport as rendered into XML. These examples include additional line breaks and whitespace for the sake of readability. RFID Edge Server permits (but does not require) this whitespace when reading XML; usually RFID Edge Server omits this whitespace when writing XML.

For PCSpec examples that demonstrate Gen2 capabilities, see Gen2 PCSpec Examples.

PCSpec - Example

<?xml version="1.0" encoding="UTF-8"?>
<PCSpec xmlns="http://schemas.connecterra.com/alepc">

<!-- The name of the EPC cache from which this PCSpec obtains EPC
         values for tag programming operations. Optional. -->
    <cacheName>mycache</cacheName>

    <!-- Specifies a string to be included in PCWriteReport instances
          generated by this PCSpec.  Optional. -->

    <applicationData>application-specific data here</applicationData>
    <logicalReaders>
        <!-- determines which logical reader(s) will be used by this
             PCSpec.  Logical reader names are defined in edge.props. -->
        <logicalReader>TagWriteStation</logicalReader>
    </logicalReaders>

    <!-- Specifies name/value pairs to be passed down to reader drivers used
         by this PCSpec's programming cycles.  Optional. -->
    <readerParameters>
        <readerParameter name="paramName">paramValue</readerParameter>
        <readerParameter name="anotherParamName">another parameter
             value</readerParameter>
    </readerParameters>

    <!-- Determines when this programming cycle starts and stops. -->
    <boundarySpec>
        <!-- Trigger that starts a programming cycle.  Optional -->
        <startTrigger> trigger URI here... </startTrigger>

        <!-- Trigger that stops a programming cycle.  Optional -->
        <stopTrigger> trigger URI here... </stopTrigger>

        <!-- Specifies maximum number of tag writing trials.  Optional,
             default is unlimited number of trials. --> 
        <trials>1</trials>

        <!-- Specifies maximum number of milliseconds to spend retrying failed
             tag writing operations.  Optional, default is no time limit. -->
        <duration>1000</duration>
    </boundarySpec>
</PCSpec>

PCWriteReport - Example

<?xml version="1.0" encoding="UTF-8"?>
<PCWriteReport date="2004-05-27T18:56:31.179Z" 
               savantID="test-edge-server"
               specName="testspec"
               totalMilliseconds="10"
               totalTrials="1"
               xmlns="http://schemas.connecterra.com/alepc">

    <applicationData>application-specific data here</applicationData>
    <wasSuccessful>true</wasSuccessful>
    <status>SUCCESSFUL</status>

    <physicalReaders>
        <physicalReader>tws1</physicalReader>
    </physicalReaders>
    <failedLogicalReaders/>
    <cacheName>mycache</cacheName>
    <cacheSize>11</cacheSize>
    <epc>urn:epc:tag:gid-64-i:1.5.1</epc>
    <successfulLogicalReader>TagWriteStation</successfulLogicalReader>
</PCWriteReport>

EPCCacheSpec - Example

<?xml version="1.0" encoding="UTF-8"?>
<EPCCacheSpec xmlns="http://schemas.connecterra.com/alepc">

    <!-- Specifies a string to be included in EPCCacheReport instances
         generated by this EPCCacheSpec.  Optional. -->
    <applicationData>cache-specific data here</applicationData>

    <!-- Specifies that when this cache's size drops to (or below) the
         given number of EPC values, a EPCCacheReport should be issued. -->
    <threshold>2500</threshold>

    <!-- Specifies that EPCCacheReport instances should include the current
         contents of the cache.  Optional, default is false. -->
    <includeCacheContent>true</includeCacheContent>

</EPCCacheSpec>

EPCCacheReport - Example

<?xml version="1.0" encoding="UTF-8"?>
<EPCCacheReport date="2004-05-27T18:59:32.890Z" 
                savantID="test-edge-server"
                xmlns="http://schemas.connecterra.com/alepc">

    <cacheName>mycache</cacheName>
    <applicationData>cache-specific data goes here</applicationData>
    <cacheSize>10</cacheSize>
    <cacheContent>
        <pattern>urn:epc:pat:gid-64-i:1.5.[3-12]</pattern>
    </cacheContent>
    <threshold>2500</threshold>
</EPCCacheReport>

XML Schema for PCSpec, PCWriteReport, EPCCacheSpec, and EPCCacheReport

The share/schemas/ALEPC.xsd file in the RFID Edge Server installation defines an XML representation for PCSpec, PCWriteReport, EPCCacheSpec, and EPCCacheReport instances, using the W3C XML Schema language.

Using the ALEPC Tag Writing API from Java

To use the ALEPC tag writing API, you create an instance of the AxisALEPCClient class provided in the com.connecterra.alepc.client package. This class implements the ALEPC interface as described in ALEPC: Main Tag Writing Interface with UML Diagrams and provides all of the methods described there. It also provides an additional method, getALEPCFactory, which returns a factory for creating instances of other types, described below. The AxisALEPCClient interacts with an WebLogic RFID Edge Server over the network using SOAP over HTTP. When you construct an instance of AxisALEPCClient, you provide a service URL for the Edge Server with which you want to interact.

When using the AxisALEPCClient class, you need to create instances of PCSpec, EPCCacheSpec, and other types described in this chapter. The ALEPCFactory interface. in package com.connecterra.alepc.api, provides methods for creating instances of those types. You obtain an instance of the ALEPCFactory interface by calling the getALEPCFactory method provided by the AxisALEPCClient class. When passing arguments to methods of a specific AxisALEPCClient instance, you must always use the factory instance provided by that AxisALEPCClient instance.

Using XML Serializers and Deserializers from Java

The Java binding of the ALE API provides some additional utility classes for writing XML representations of the data types used in the ALE API. With these classes, you can convert a Java object representation of a particular data type into XML ("serialization"), and likewise convert an XML representation of a particular data type back into a Java object ("deserialization"). The XML schemas are located in your RFID Edge Server installation directory at:

/share/schemas/EPCglobal-ale-1_0.xsd
/share/schemas/EPCglobal.xsd
/share/schemas/EPCglobal-ale-1_0-RFTagAware-extensions.xsd
/share/schemas/ALEPC.xsd

To read and write XML for types used in the ALE tag writing API, you use an instance of the PCXMLSerializationFactory provided in the com.connecterra.alepc.encoding package. There is only one static instance of this class, which you obtain using the static method getInstance(), with no argument. Using the PCXMLSerializationFactory instance, you can create instances of PCXMLSerializer and PCXMLDeserializer to serialize and deserialize instances of the following classes: PCSpec, PCWriteReport, PCSpecInfo, PCSubscriptionInfo, PCSubscriptionControls, EPCCacheSpec, EPCCacheReport, and EPCCacheSpecInfo.

BEA Gen2 Write Support

The following sections summarize BEA support for Gen2 command access:

Extended API Support

In support of the UHF Generation 2 Air Interface Protocol, BEA provides extensions to the following classes:

Multiple Tags in Field

In Gen2, it becomes meaningful to perform work while multiple tags are in the reader field. For backward-compatibility, a PCSpec that is not identifiably Gen2 (a PCSpec that does not contain one or more AccessSpecs) will require that the field contain only a single tag, while a PCSpec that contains Gen2 elements will allow multiple tags by default.

A new <restrictSingleTag/> element has been added to the PCSpec to restrict a Gen2 PCSpec to return an error if there are multiple tags in field. This element is implicit in a PCSpec that contains no AccessSpecs. This restriction is on a best-effort basis, and does not represent a guarantee. The current release will only work on a single tag in field.

Parameter Substitutions

The ALEPC poll() and immediate() calls add PCSpec parameters, providing values for use within the processing of the Programming Cycle. The poll and immediate calls accept a parameter map: a map from parameter name to parameter value. The old-style ALEPC calls, which only take a single EPC value, will generate a parameter map from the parameter epc to the provided value.

The values in this parameter map can be used in three ways:

The write, password, and kill operations can take a <param> element for the data needed for the operation. The contents of that element are used as the key into the parameter map, and the associated parameter value is used as the data. For example, the PCSpec can specify the epc cache and a user memory value that indicates the manufacturer, and poll() can specify a date code.

Users of the readerParameters of the PCSpec have been modified to check these parameters for a match before searching the readerParameters.

Gen2 PCSpec Examples

The following PCSpec examples demonstrate XML encoding of some Gen2 features:

The following examples are complete: readEPCBank.xml, writeTagMemory.xml and PCWriteReport, and stackLight.xml. The remaining examples show only the <accessSpec> portion of the PCSpec. They use the same <logicalReaders> and <boundarySpec> elements as readEPCBank.xml.

readEPCBank.xml

For all tags in field, report the EPC value of that tag.

<PCSpec xmlns="http://schemas.connecterra.com/alepc">
   <applicationData>application specific data can go here</applicationData>
   <logicalReaders>
      <logicalReader>ConnecTerra1</logicalReader>
   </logicalReaders>
   <boundarySpec>
      <trials>1</trials>
      <duration>4000</duration>
   </boundarySpec>
   <accessSpec>
      <operations>
         <operation>
            <read field="urn:connecterra:tagmem:epc"/>
         </operation>
      </operations>
   </accessSpec>
</PCSpec>

readAbsolute.xml

For all tags in field, read the raw EPC bank including the CRC and control bits, and report that value.

   <accessSpec>
      <operations>
         <operation>
            <read field="urn:connecterra:tagmem:@epc.96"/>
         </operation>
      </operations>
   </accessSpec>

readPassword.xml

For all tags in field, use 0x0000AAAA as the (32-bit) access password and report the first 32 bits of the reserved bank, followed by the next 32 bits. In a Gen2 tag these areas of the tag are the kill password, and the access password, respectively.

   <accessSpec>
      <operations>
         <operation>
            <password>
               <literal>urn:epc:raw:96.x0000AAAA</literal>
            </password>
         </operation>
         <operation>
            <read field="urn:connecterra:tagmem:@reserved.32"/>
         </operation>
         <operation>
            <read field="urn:connecterra:tagmem:@reserved.32.32"/>
         </operation>
      </operations>
   </accessSpec>

writePassword.xml

For all tags in field, use 0x11111111 as the access password and write the EPC value specified there to the EPC bank.

   <accessSpec>
      <operations>
        <operation>
	   <password><literal>urn:epc:raw:64.x11111111</literal></password>
	 </operation>
        <operation>
          <write field="urn:connecterra:tagmem:epc">
            <literal>urn:epc:tag:sgtin-96:1.0037000.123456.1</literal>
          </write>
        </operation>
      </operations>
   </accessSpec>

writePasswords.xml

For all tags in field, write 0x00000001 as the kill password and write 0x00000002 as the access password.

   <accessSpec>
      <operations>
         <operation>
            <!-- write x00000001 into the KILL password  -->
            <write field="urn:connecterra:tagmem:@reserved.32">
                <literal>urn:epc:raw:64.1</literal>
            </write>
         </operation>
         <operation>
            <!-- write x00000002 into the ACCESS password  -->
            <write field="urn:connecterra:tagmem:@reserved.32.32">
                <literal>urn:epc:raw:64.2</literal>
            </write>
         </operation>
      </operations>
   </accessSpec>

writeTagMemory.xml

For all tags in field, write that raw value to the full EPC bank, overwriting the CRC and control bits.

  <accessSpec>
   <operations>
    <operation>
     <write field="urn:connecterra:tagmem:@epc.128">
        <literal>urn:epc:raw:128.973572063680812240853843738361866</literal>
     </write>
    </operation>
   </operations>
  </accessSpec>

writeTagMemory.xml and PCWriteReport.xml

<PCSpec xmlns="http://schemas.connecterra.com/alepc">
    <applicationData>Write Tag Memory</applicationData>
    <logicalReaders>
        <logicalReader>ConnecTerra1</logicalReader>
    </logicalReaders>
    <boundarySpec>
        <trials>1</trials>
        <duration>4000</duration>
    </boundarySpec>
    <accessSpec>
        <operations>
            <operation>
                <write field="urn:connecterra:tagmem:epc">
                    <literal>urn:epc:tag:sgtin-96:1.0037000.123456.1</literal>
                </write>
            </operation>
        </operations>
    </accessSpec>
</PCSpec>

<PCWriteReport date="2006-04-04T21:45:55.369Z" savantID="Warren"
 specName="write" totalMilliseconds="1141" totalTrials="0"
 xmlns="http://schemas.connecterra.com/alepc">
 <applicationData>Write Tag Memory</applicationData>
 <wasSuccessful>true</wasSuccessful>
 <status>SUCCESSFUL</status>
 <physicalReaders>
  <physicalReader>SimReadr</physicalReader>
 </physicalReaders>
 <failedLogicalReaders/>
 <cacheSize>0</cacheSize>
 <accessReport>
  <tag epc="urn:epc:tag:sgtin-96:1.0037000.123456.1">
   <opReport>
    <status>SUCCESSFUL</status>
    <field>urn:connecterra:tagmem:epc</field>
    <value>urn:epc:tag:sgtin-96:1.0037000.123456.1</value>
   </opReport>
  </tag>
 </accessReport>
</PCWriteReport>

kill.xml

For all tags in field, try to kill the tag with the provided (32-bit) kill password (0x22222222):

   <accessSpec>
      <operations>
         <operation>
            <kill>
               <literal>urn:epc:raw:64.572662306</literal>
            </kill>
         </operation>
      </operations>
   </accessSpec>

lock.xml

For all tags in field, try to perform the specified lock operation with the provided password (0x11111111):

   <accessSpec>
      <operations>
         <operation>
            <password>
               <literal>urn:epc:raw:64.286331153</literal>
            </password>
         </operation>
         <operation>
            <lock>
               <mask>urn:epc:raw:64.3</mask>
               <value>urn:epc:raw:64.3</value>
            </lock>
         </operation>
      </operations>
   </accessSpec>

stackLight.xml

Write tag memory with stack light information, turning on the Amber stack light indefinitely:

<?xml version="1.0" encoding="UTF-8"?>
<PCSpec xmlns="http://schemas.connecterra.com/alepc">
    <applicationData>
     Turn on Amber stack light indefinitely
     (starting from bit 12, 4 bits)
    </applicationData>
    <logicalReaders>
       <logicalReader>StackLight</logicalReader>
    </logicalReaders>
    <boundarySpec>
       <trials>1</trials>
       <duration>4000</duration>
    </boundarySpec>
    <accessSpec>
       <operations>
          <operation>
          <!-- write EPC memory -->
             <write field="urn:connecterra:tagmem:@stacklight.4.12">
                   <literal>urn:epc:raw:64.x9</literal>
             </write>
          </operation>
       </operations>
    </accessSpec>
</PCSpec>

For more information on stack light control, see Configuring and Controlling Stack Lights in the RFID Reader Reference manual.