Kyle,

Joel hit on what I believe the primary use of the N field, specifically
that if N=1, the Client should expect one RO_ACCESS_REPORT for each tag
singulation by the Reader.

When N>1, the number of RO_ACCESS_REPORTS should be a function of both
the number of tags singulated and what is enabled in the
TagReportContentSelector.  For example, if N=2 and one tag is in the FOV
of the reader, if there are no accumulated parameters enabled in the
TagReportContentSelector, the Client should not expect a
RO_ACCESS_REPORT since it would only contain a single TagReportData
(regardless of the number of times that tag is singulated).  However, if
Antenna (an accumulated parameter) is enabled and the tag is seen by
more than one antenna, the Client should expect a RO_ACCESS_REPORT each
time a second TagReportData parameter is created by a singulation on a
second antenna.  This is all of course assuming that the Reader supports
accumulation.

Thanks,

C

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Joel Peshkin
Sent: Friday, November 02, 2007 4:03 PM
To: LLRP Toolkit Development List
Subject: Re: [ltk-d] RoReportSpec

 

Kyle,

   I believe that if N=1, you should get separate access reports.  That
may not sound so important when N=1, but it seems like poor form for an
app that is willing to buffer 100 reports to suddenly get hit with 150
because more came in at the same time.

-Joel


<?xml version="1.0"?>
<RO_ACCESS_REPORT Version="1" MessageID="2323">
  <TagReportData>
    <EPC_96>
      <EPC>1111222233334444555500B8</EPC>
    </EPC_96>
    <ROSpecID>
      <ROSpecID>1</ROSpecID>
    </ROSpecID>
  </TagReportData>
</RO_ACCESS_REPORT>

<?xml version="1.0"?>
<RO_ACCESS_REPORT Version="1" MessageID="2323">
  <TagReportData>
    <EPC_96>
      <EPC>111122223333444455550083</EPC>
    </EPC_96>
    <ROSpecID>
      <ROSpecID>1</ROSpecID>
    </ROSpecID>
  </TagReportData>
</RO_ACCESS_REPORT>


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel

Reply via email to