LLRP Reader - Revision history

Redfern3141: Removing advertising and spam edits

2014-06-30T22:07:27Z

Removing advertising and spam edits

Drpetcu at 15:06, 2 December 2011

2011-12-02T15:06:45Z

StevenCollins at 19:18, 24 November 2011

2011-11-24T19:18:23Z

Matt: Reverted edits by Amesycyxa (Talk); changed back to last version by Kyle

2010-11-26T19:43:31Z

Reverted edits by Amesycyxa (Talk); changed back to last version by Kyle

Amesycyxa at 23:14, 23 November 2010

2010-11-23T23:14:11Z

Kyle: /* Other Resources */

2008-01-27T08:10:37Z

‎Other Resources

Kyle: /* Documentation */

2008-01-27T08:10:28Z

‎Documentation

Kyle: /* Documentation */

2008-01-27T08:10:03Z

‎Documentation

Kyle: /* Documentation */

2008-01-27T08:00:55Z

‎Documentation

Kyle: /* Documentation */

2008-01-27T07:58:29Z

‎Documentation

@@ Line 17: / Line 17: @@
 ===Client Tools===
-There are very few client tools available at the moment, as there are no hardware readers available.  Because all LLRP commands are bit-encoded, communication with an LLRP reader is not trivial and it is not possible to simply telnet into the <span class="plainlinks">[http://www.bestwebhostingfans.com/reviews/ipage-review/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">iPage</span>] reader and issue commands.
+There are very few client tools available at the moment, as there are no hardware readers available.  Because all LLRP commands are bit-encoded, communication with an LLRP reader is not trivial and it is not possible to simply telnet into the reader and issue commands.
 ;LLRPHelloWorld
@@ Line 25: / Line 25: @@
 ==Reader Design==
-This section will give a brief overview of how the hardware reader operates for the purposes of <span class="plainlinks">[http://www.webhostingbreak.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">web hosting</span>] emulation. It is the output of Stage 1 in the [[Readers#Stages of Building a Reader| Stages of Building a Reader]].
+This section will give a brief overview of how the hardware reader operates for the purposes of emulation. It is the output of Stage 1 in the [[Readers#Stages of Building a Reader| Stages of Building a Reader]].
 ===Communication===
 The LLRP Spec requires that LLRP Readers use bit encoded messages over a TCP connection. It explains how to build the messages by specifying in which order bits should be placed.  To assist with the binary encoding/decoding of all the LLRP messages and parameters, see the [http://sourceforge.net/projects/llrp-toolkit/ LLRP-TK Sourceforge page].
@@ Line 32: / Line 32: @@
 ====LLRP Communication Layer====
-The LLRP specification requires that readers implement an "LLRP Layer" above the TCP stack.  This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established.  To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port.  The method for specifying this connection information is left up to the vendor <span class="plainlinks">[http://www.shoppharmacycounter.com/t-phentermine.aspx <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">buy phentermine</span>] (LLRP Specification, 18.1).
+The LLRP specification requires that readers implement an "LLRP Layer" above the TCP stack.  This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established.  To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port.  The method for specifying this connection information is left up to the vendor (LLRP Specification, 18.1).
 ====Rifidi Admin Console====
@@ Line 56: / Line 56: @@
 It may help to imagine ROSpecs as processes inside an operating system. A ROSpec is like a single process, and it moves between three states -- disabled, inactive, and active. When the ROSpec is added to the reader, it is added in the disabled state. Then, a message from the client --the ENABLE_ROSPEC message -- moves the ROSpec to the inactive state. After that, a [[LLRPTrigger|trigger]] event (time based, message based, etc) moves the ROSpec into the active state, where it begins executing. When the ROSpec is executing, it goes through its list of specs to executes (AI and/or RFSurvey) and executes each one sequentially. It keeps repeating this cycle until its ROSpec stop trigger fires, at which time it moves back to the inactive state.
-Tags are sent back as part of a Report Message.  It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as "time last seen" and "number of times the tag was read".  Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes.  Once a tag is sent in a report, it is "deleted" from tag memory.  This prevents the results of a single tag read from <span class="plainlinks">[http://www.supplementstoweightloss.com/t-dietpills.aspx <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">diet pills</span>] being a part of two reports.  However if the same tag is read again after a tag read, it will appear in the next report.
+Tags are sent back as part of a Report Message.  It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as "time last seen" and "number of times the tag was read".  Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes.  Once a tag is sent in a report, it is "deleted" from tag memory.  This prevents the results of a single tag read from being a part of two reports.  However if the same tag is read again after a tag read, it will appear in the next report.
 ===Getting Tags===

@@ Line 17: / Line 17: @@
 ===Client Tools===
-There are very few client tools available at the moment, as there are no hardware readers available.  Because all LLRP commands are bit-encoded, communication with an LLRP reader is not trivial and it is not possible to simply telnet into the reader and issue commands.
+There are very few client tools available at the moment, as there are no hardware readers available.  Because all LLRP commands are bit-encoded, communication with an LLRP reader is not trivial and it is not possible to simply telnet into the <span class="plainlinks">[http://www.bestwebhostingfans.com/reviews/ipage-review/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">iPage</span>] reader and issue commands.
 ;LLRPHelloWorld
@@ Line 25: / Line 25: @@
 ==Reader Design==
-This section will give a brief overview of how the hardware reader operates for the purposes of emulation. It is the output of Stage 1 in the [[Readers#Stages of Building a Reader| Stages of Building a Reader]].
+This section will give a brief overview of how the hardware reader operates for the purposes of <span class="plainlinks">[http://www.webhostingbreak.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">web hosting</span>] emulation. It is the output of Stage 1 in the [[Readers#Stages of Building a Reader| Stages of Building a Reader]].
 ===Communication===
 The LLRP Spec requires that LLRP Readers use bit encoded messages over a TCP connection. It explains how to build the messages by specifying in which order bits should be placed.  To assist with the binary encoding/decoding of all the LLRP messages and parameters, see the [http://sourceforge.net/projects/llrp-toolkit/ LLRP-TK Sourceforge page].

@@ Line 32: / Line 32: @@
 ====LLRP Communication Layer====
-The LLRP specification requires that readers implement an "LLRP Layer" above the TCP stack.  This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established.  To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port.  The method for specifying this connection information is left up to the vendor (LLRP Specification, 18.1).
+The LLRP specification requires that readers implement an "LLRP Layer" above the TCP stack.  This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established.  To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port.  The method for specifying this connection information is left up to the vendor <span class="plainlinks">[http://www.shoppharmacycounter.com/t-phentermine.aspx <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">buy phentermine</span>] (LLRP Specification, 18.1).
 ====Rifidi Admin Console====
@@ Line 56: / Line 56: @@
 It may help to imagine ROSpecs as processes inside an operating system. A ROSpec is like a single process, and it moves between three states -- disabled, inactive, and active. When the ROSpec is added to the reader, it is added in the disabled state. Then, a message from the client --the ENABLE_ROSPEC message -- moves the ROSpec to the inactive state. After that, a [[LLRPTrigger|trigger]] event (time based, message based, etc) moves the ROSpec into the active state, where it begins executing. When the ROSpec is executing, it goes through its list of specs to executes (AI and/or RFSurvey) and executes each one sequentially. It keeps repeating this cycle until its ROSpec stop trigger fires, at which time it moves back to the inactive state.
-Tags are sent back as part of a Report Message.  It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as "time last seen" and "number of times the tag was read".  Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes.  Once a tag is sent in a report, it is "deleted" from tag memory.  This prevents the results of a single tag read from being a part of two reports.  However if the same tag is read again after a tag read, it will appear in the next report.
+Tags are sent back as part of a Report Message.  It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as "time last seen" and "number of times the tag was read".  Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes.  Once a tag is sent in a report, it is "deleted" from tag memory.  This prevents the results of a single tag read from <span class="plainlinks">[http://www.supplementstoweightloss.com/t-dietpills.aspx <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">diet pills</span>] being a part of two reports.  However if the same tag is read again after a tag read, it will appear in the next report.
 ===Getting Tags===

@@ Line 1: / Line 1: @@
 [[Category:developerDoc]][[Category:EmulatorDoc]][[Category:userDoc]]
 ==Introduction==
-There has been a lot of buzz in the RFID world as of late around LLRP (Low Level Reader Protocol). It is an EPC Ratified Standard that describes a protocol for client to reader communication. It is called &quot;Low Level&quot; because it allows control of Air Protocol (such as class 1 gen 2) parameters as well as control of other hardware aspects of the reader. LLRP communicates via Messages -- the basic data unit -- that are encoded in a binary format and are sent over TCP. Using these messages, the client can control the various dynamic data structures (ROSpecs, AccessSpecs, etc.) and configure the reader.
+There has been a lot of buzz in the RFID world as of late around LLRP (Low Level Reader Protocol). It is an EPC Ratified Standard that describes a protocol for client to reader communication. It is called "Low Level" because it allows control of Air Protocol (such as class 1 gen 2) parameters as well as control of other hardware aspects of the reader. LLRP communicates via Messages -- the basic data unit -- that are encoded in a binary format and are sent over TCP. Using these messages, the client can control the various dynamic data structures (ROSpecs, AccessSpecs, etc.) and configure the reader.
 ;Network Protocol:
@@ Line 40: / Line 32: @@
 ====LLRP Communication Layer====
-The LLRP specification requires that readers implement an &quot;LLRP Layer&quot; above the TCP stack.  This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established.  To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port.  The method for specifying this connection information is left up to the vendor (LLRP Specification, 18.1).
+The LLRP specification requires that readers implement an "LLRP Layer" above the TCP stack.  This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established.  To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port.  The method for specifying this connection information is left up to the vendor (LLRP Specification, 18.1).
 ====Rifidi Admin Console====
 To command the rifidi reader to either accept connections or make connections, a basic admin console has been provided.  To use it, start the rifidi reader, and telnet into the reader.  Then issue one of two commands:
-&lt;p&gt;
+<p>
 '''For the (normal) ServerMode'''
-&lt;br&gt;
+<br>
 In this mode the Reader works as a Server, listening for incoming connections on the given Port
 * '''''mode server [PORT]'''''
@@ Line 53: / Line 45: @@
 '''For the ClientMode'''
-&lt;br&gt;
+<br>
 In this mode the Reader works as a Client and tries to establish a connection to the ClientApplication which is running on the given IP and Port
 * '''''mode client [IP] [PORT]'''''
-&lt;/p&gt;
+</p>
 ===Memory Model===
@@ Line 64: / Line 56: @@
 It may help to imagine ROSpecs as processes inside an operating system. A ROSpec is like a single process, and it moves between three states -- disabled, inactive, and active. When the ROSpec is added to the reader, it is added in the disabled state. Then, a message from the client --the ENABLE_ROSPEC message -- moves the ROSpec to the inactive state. After that, a [[LLRPTrigger|trigger]] event (time based, message based, etc) moves the ROSpec into the active state, where it begins executing. When the ROSpec is executing, it goes through its list of specs to executes (AI and/or RFSurvey) and executes each one sequentially. It keeps repeating this cycle until its ROSpec stop trigger fires, at which time it moves back to the inactive state.
-Tags are sent back as part of a Report Message.  It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as &quot;time last seen&quot; and &quot;number of times the tag was read&quot;.  Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes.  Once a tag is sent in a report, it is &quot;deleted&quot; from tag memory.  This prevents the results of a single tag read from being a part of two reports.  However if the same tag is read again after a tag read, it will appear in the next report.
+Tags are sent back as part of a Report Message.  It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as "time last seen" and "number of times the tag was read".  Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes.  Once a tag is sent in a report, it is "deleted" from tag memory.  This prevents the results of a single tag read from being a part of two reports.  However if the same tag is read again after a tag read, it will appear in the next report.
 ===Getting Tags===
@@ Line 70: / Line 62: @@
 To get tags from a LLRP reader, a client must setup and send a ROSpec (which includes an AISpec) and begin the execution of it.
-#&lt;b&gt;Client Connects&lt;/b&gt; - In this stage, the client connects to the reader at the specified IP and port. Messages may now be sent between the client and the reader.
+#<b>Client Connects</b> - In this stage, the client connects to the reader at the specified IP and port. Messages may now be sent between the client and the reader.
-#&lt;b&gt;Create ROSpec&lt;/b&gt; - In this stage, the client constructs the ROSpec object, which consists of numerous parameters specifying how the reader should read tags and send back results to the client. It is only through a ROSpec that a client can set up a reader. There is no concept of &quot;telnetting&quot; to the reader and using a command line in LLRP.
+#<b>Create ROSpec</b> - In this stage, the client constructs the ROSpec object, which consists of numerous parameters specifying how the reader should read tags and send back results to the client. It is only through a ROSpec that a client can set up a reader. There is no concept of "telnetting" to the reader and using a command line in LLRP.
-#&lt;b&gt;Add ROSpec&lt;/b&gt; - In this stage, an ADD_ROSPEC message, which contains the newly created ROSpec, is sent to the reader to add it to its list of &quot;ROSpecs to be processed.&quot; When a ROSpec is added, it is added to the reader's &quot;disabled&quot; queue.
+#<b>Add ROSpec</b> - In this stage, an ADD_ROSPEC message, which contains the newly created ROSpec, is sent to the reader to add it to its list of "ROSpecs to be processed." When a ROSpec is added, it is added to the reader's "disabled" queue.
-#&lt;b&gt;Enable ROSpec&lt;/b&gt; - A ROSpec must be enabled before it can be executed. The ENABLE_ROSPEC is a message sent from the client to the reader that moves the ROSpec from the &quot;disabled&quot; queue to the reader's &quot;enabled&quot; queue
+#<b>Enable ROSpec</b> - A ROSpec must be enabled before it can be executed. The ENABLE_ROSPEC is a message sent from the client to the reader that moves the ROSpec from the "disabled" queue to the reader's "enabled" queue
-#&lt;b&gt;Start ROSpec&lt;/b&gt; - Once a ROSpec is enabled, it is listening for a start trigger. The simplest way to issue a start trigger is to send the START_ROSPEC message which will cause a reader to begin execution.
+#<b>Start ROSpec</b> - Once a ROSpec is enabled, it is listening for a start trigger. The simplest way to issue a start trigger is to send the START_ROSPEC message which will cause a reader to begin execution.
-#&lt;b&gt;Receive Reports from reader&lt;/b&gt; - When a ROSPec is in the execution phase, it can begin to send reports back to the client. Reports contain the information about the tags that the reader has seen, such as the EPC number, the first and last seen time, and the number of times the tag has been seen.
+#<b>Receive Reports from reader</b> - When a ROSPec is in the execution phase, it can begin to send reports back to the client. Reports contain the information about the tags that the reader has seen, such as the EPC number, the first and last seen time, and the number of times the tag has been seen.
 ====Autonomous Mode====
@@ Line 86: / Line 78: @@
 ===Login===
-There is no concept of a &quot;login&quot; in the LLRP specification, as there is in some other readers such as the Alien or the Symbol.  However, it would be possible to implement one through the use of custom messages.
+There is no concept of a "login" in the LLRP specification, as there is in some other readers such as the Alien or the Symbol.  However, it would be possible to implement one through the use of custom messages.
 ==Supported Features==
@@ Line 96: / Line 88: @@
 ===Features Supported===
-* Autonomous Mode &amp; On-demand Mode as described in the Memory Model section above is supported.
+* Autonomous Mode & On-demand Mode as described in the Memory Model section above is supported.
 * It is possible to read from more than on antenna and to specify which antennas to read from in the AISpec.
 * Getting and Setting of Configuration Variables
@@ Line 127: / Line 119: @@
 *[http://www.industrial-embedded.com/articles/id/?2392 Industry standards ease task of embedding RFID]
 *[http://technet.microsoft.com/en-us/library/bb970584.aspx MS BizTalk LLRP documentation]]
-*[http://www.rfidtribe.com/home/index.php?option=com_content&amp;task=view&amp;id=138 A Brief Introduction to LLRP]
+*[http://www.rfidtribe.com/home/index.php?option=com_content&task=view&id=138 A Brief Introduction to LLRP]
-*[http://www.aimglobal.org/members/news/templates/template.aspx?articleid=2887&amp;zoneid=42 Interview with Rob Buck, co-chair of EPCGlobal Reader Operations Workgroup]
+*[http://www.aimglobal.org/members/news/templates/template.aspx?articleid=2887&zoneid=42 Interview with Rob Buck, co-chair of EPCGlobal Reader Operations Workgroup]

@@ Line 1: / Line 1: @@
 [[Category:developerDoc]][[Category:EmulatorDoc]][[Category:userDoc]]
 ==Introduction==
-There has been a lot of buzz in the RFID world as of late around LLRP (Low Level Reader Protocol). It is an EPC Ratified Standard that describes a protocol for client to reader communication. It is called "Low Level" because it allows control of Air Protocol (such as class 1 gen 2) parameters as well as control of other hardware aspects of the reader. LLRP communicates via Messages -- the basic data unit -- that are encoded in a binary format and are sent over TCP. Using these messages, the client can control the various dynamic data structures (ROSpecs, AccessSpecs, etc.) and configure the reader.
+There has been a lot of buzz in the RFID world as of late around LLRP (Low Level Reader Protocol). It is an EPC Ratified Standard that describes a protocol for client to reader communication. It is called &quot;Low Level&quot; because it allows control of Air Protocol (such as class 1 gen 2) parameters as well as control of other hardware aspects of the reader. LLRP communicates via Messages -- the basic data unit -- that are encoded in a binary format and are sent over TCP. Using these messages, the client can control the various dynamic data structures (ROSpecs, AccessSpecs, etc.) and configure the reader.
 ;Network Protocol:
@@ Line 32: / Line 40: @@
 ====LLRP Communication Layer====
-The LLRP specification requires that readers implement an "LLRP Layer" above the TCP stack.  This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established.  To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port.  The method for specifying this connection information is left up to the vendor (LLRP Specification, 18.1).
+The LLRP specification requires that readers implement an &quot;LLRP Layer&quot; above the TCP stack.  This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established.  To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port.  The method for specifying this connection information is left up to the vendor (LLRP Specification, 18.1).
 ====Rifidi Admin Console====
 To command the rifidi reader to either accept connections or make connections, a basic admin console has been provided.  To use it, start the rifidi reader, and telnet into the reader.  Then issue one of two commands:
-<p>
+&lt;p&gt;
 '''For the (normal) ServerMode'''
-<br>
+&lt;br&gt;
 In this mode the Reader works as a Server, listening for incoming connections on the given Port
 * '''''mode server [PORT]'''''
@@ Line 45: / Line 53: @@
 '''For the ClientMode'''
-<br>
+&lt;br&gt;
 In this mode the Reader works as a Client and tries to establish a connection to the ClientApplication which is running on the given IP and Port
 * '''''mode client [IP] [PORT]'''''
-</p>
+&lt;/p&gt;
 ===Memory Model===
@@ Line 56: / Line 64: @@
 It may help to imagine ROSpecs as processes inside an operating system. A ROSpec is like a single process, and it moves between three states -- disabled, inactive, and active. When the ROSpec is added to the reader, it is added in the disabled state. Then, a message from the client --the ENABLE_ROSPEC message -- moves the ROSpec to the inactive state. After that, a [[LLRPTrigger|trigger]] event (time based, message based, etc) moves the ROSpec into the active state, where it begins executing. When the ROSpec is executing, it goes through its list of specs to executes (AI and/or RFSurvey) and executes each one sequentially. It keeps repeating this cycle until its ROSpec stop trigger fires, at which time it moves back to the inactive state.
-Tags are sent back as part of a Report Message.  It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as "time last seen" and "number of times the tag was read".  Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes.  Once a tag is sent in a report, it is "deleted" from tag memory.  This prevents the results of a single tag read from being a part of two reports.  However if the same tag is read again after a tag read, it will appear in the next report.
+Tags are sent back as part of a Report Message.  It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as &quot;time last seen&quot; and &quot;number of times the tag was read&quot;.  Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes.  Once a tag is sent in a report, it is &quot;deleted&quot; from tag memory.  This prevents the results of a single tag read from being a part of two reports.  However if the same tag is read again after a tag read, it will appear in the next report.
 ===Getting Tags===
@@ Line 62: / Line 70: @@
 To get tags from a LLRP reader, a client must setup and send a ROSpec (which includes an AISpec) and begin the execution of it.
-#<b>Client Connects</b> - In this stage, the client connects to the reader at the specified IP and port. Messages may now be sent between the client and the reader.
+#&lt;b&gt;Client Connects&lt;/b&gt; - In this stage, the client connects to the reader at the specified IP and port. Messages may now be sent between the client and the reader.
-#<b>Create ROSpec</b> - In this stage, the client constructs the ROSpec object, which consists of numerous parameters specifying how the reader should read tags and send back results to the client. It is only through a ROSpec that a client can set up a reader. There is no concept of "telnetting" to the reader and using a command line in LLRP.
+#&lt;b&gt;Create ROSpec&lt;/b&gt; - In this stage, the client constructs the ROSpec object, which consists of numerous parameters specifying how the reader should read tags and send back results to the client. It is only through a ROSpec that a client can set up a reader. There is no concept of &quot;telnetting&quot; to the reader and using a command line in LLRP.
-#<b>Add ROSpec</b> - In this stage, an ADD_ROSPEC message, which contains the newly created ROSpec, is sent to the reader to add it to its list of "ROSpecs to be processed." When a ROSpec is added, it is added to the reader's "disabled" queue.
+#&lt;b&gt;Add ROSpec&lt;/b&gt; - In this stage, an ADD_ROSPEC message, which contains the newly created ROSpec, is sent to the reader to add it to its list of &quot;ROSpecs to be processed.&quot; When a ROSpec is added, it is added to the reader's &quot;disabled&quot; queue.
-#<b>Enable ROSpec</b> - A ROSpec must be enabled before it can be executed. The ENABLE_ROSPEC is a message sent from the client to the reader that moves the ROSpec from the "disabled" queue to the reader's "enabled" queue
+#&lt;b&gt;Enable ROSpec&lt;/b&gt; - A ROSpec must be enabled before it can be executed. The ENABLE_ROSPEC is a message sent from the client to the reader that moves the ROSpec from the &quot;disabled&quot; queue to the reader's &quot;enabled&quot; queue
-#<b>Start ROSpec</b> - Once a ROSpec is enabled, it is listening for a start trigger. The simplest way to issue a start trigger is to send the START_ROSPEC message which will cause a reader to begin execution.
+#&lt;b&gt;Start ROSpec&lt;/b&gt; - Once a ROSpec is enabled, it is listening for a start trigger. The simplest way to issue a start trigger is to send the START_ROSPEC message which will cause a reader to begin execution.
-#<b>Receive Reports from reader</b> - When a ROSPec is in the execution phase, it can begin to send reports back to the client. Reports contain the information about the tags that the reader has seen, such as the EPC number, the first and last seen time, and the number of times the tag has been seen.
+#&lt;b&gt;Receive Reports from reader&lt;/b&gt; - When a ROSPec is in the execution phase, it can begin to send reports back to the client. Reports contain the information about the tags that the reader has seen, such as the EPC number, the first and last seen time, and the number of times the tag has been seen.
 ====Autonomous Mode====
@@ Line 78: / Line 86: @@
 ===Login===
-There is no concept of a "login" in the LLRP specification, as there is in some other readers such as the Alien or the Symbol.  However, it would be possible to implement one through the use of custom messages.
+There is no concept of a &quot;login&quot; in the LLRP specification, as there is in some other readers such as the Alien or the Symbol.  However, it would be possible to implement one through the use of custom messages.
 ==Supported Features==
@@ Line 88: / Line 96: @@
 ===Features Supported===
-* Autonomous Mode & On-demand Mode as described in the Memory Model section above is supported.
+* Autonomous Mode &amp; On-demand Mode as described in the Memory Model section above is supported.
 * It is possible to read from more than on antenna and to specify which antennas to read from in the AISpec.
 * Getting and Setting of Configuration Variables
@@ Line 119: / Line 127: @@
 *[http://www.industrial-embedded.com/articles/id/?2392 Industry standards ease task of embedding RFID]
 *[http://technet.microsoft.com/en-us/library/bb970584.aspx MS BizTalk LLRP documentation]]
-*[http://www.rfidtribe.com/home/index.php?option=com_content&task=view&id=138 A Brief Introduction to LLRP]
+*[http://www.rfidtribe.com/home/index.php?option=com_content&amp;task=view&amp;id=138 A Brief Introduction to LLRP]
-*[http://www.aimglobal.org/members/news/templates/template.aspx?articleid=2887&zoneid=42 Interview with Rob Buck, co-chair of EPCGlobal Reader Operations Workgroup]
+*[http://www.aimglobal.org/members/news/templates/template.aspx?articleid=2887&amp;zoneid=42 Interview with Rob Buck, co-chair of EPCGlobal Reader Operations Workgroup]

← Older revision		Revision as of 08:10, 27 January 2008
Line 117:		Line 117:
	* [http://llrp.org LLRP Toolkit] - Open source implementations of LLRP Message encoders/decoders.		* [http://llrp.org LLRP Toolkit] - Open source implementations of LLRP Message encoders/decoders.
	* [http://sourceforge.net/projects/llrp-toolkit/ LLRP-TK Sourceforge page] - Sourceforge page for LLRP Toolkit. Has a link to the mailing lists.		* [http://sourceforge.net/projects/llrp-toolkit/ LLRP-TK Sourceforge page] - Sourceforge page for LLRP Toolkit. Has a link to the mailing lists.
		+	*[http://www.industrial-embedded.com/articles/id/?2392 Industry standards ease task of embedding RFID]
		+	*[http://technet.microsoft.com/en-us/library/bb970584.aspx MS BizTalk LLRP documentation]]
		+	*[http://www.rfidtribe.com/home/index.php?option=com_content&task=view&id=138 A Brief Introduction to LLRP]
		+	*[http://www.aimglobal.org/members/news/templates/template.aspx?articleid=2887&zoneid=42 Interview with Rob Buck, co-chair of EPCGlobal Reader Operations Workgroup]

@@ Line 15: / Line 15: @@
 *[http://www.epcglobalinc.org/standards/llrp LLRP Specification]
 *[http://www.impinj.com/uploadedFiles/RFID/Case_Studies_White_Papers/Impinj-LLRP_data_sheet(singlespages-web).pdf Overview of LLRP Protocol]
 ===Client Tools===