Hello again,
In addition of the bug mentionned by Fabio, there was a bug in the function
matchTag in RifidiEmulator. I modify the code and now it works.
Regards,
Wafa.
________________________________
De : [email protected] [mailto:[email protected]]
Envoyé : jeudi 14 octobre 2010 15:14
À : [email protected]
Objet : Re: [ltk-d] Filtering in an AccessSpec doesn't work ?
Fabio,
Thank you for your answer but it still doesn't work.
I've build the "ltkjava 1.0.0.7" integrating the Impinj extensions and I've
already detect the problem of swaped MB. If you write :
MB=1 in the AccessSpec ===> Fosstrak swapped into MB=2 ===> Rifidi retrieve
the TID memory
That's why I write :
MB=2 in the AccessSpec ===> Fosstrak swapped into MB=1 ===> Rifidi retrieve
the EPC memory
So, I'm sure that Rifidi retrieve the right part of the tag meaning the "EPC
memory". But, still it doesn't filter on the right tag :-(
If you have any example of C1G2TargetTag tested with a TargetMask & TargetTag
that works, it will be great for me !!!
I'm still waiting for an answer from the Rifidi community (bug in Rifidi ?)
Regards,
Wafa.
________________________________
De : Fabio Bondioli [mailto:[email protected]]
Envoyé : jeudi 14 octobre 2010 14:14
À : LLRP Toolkit Development List
Objet : Re: [ltk-d] Filtering in an AccessSpec doesn't work ?
There is a bug in the current Java Implementation (1.0.0.6) used by fosstrak.
TwoBitField class swaps bit order so bank 1 became bank 2, and you are actually
filtering on TID bank, not on EPC bank
I've spotted it near a year ago in this mailing list. The sources available on
svn are updated and have this bug fixed.
I've build a "1.0.0.7 with impinj extensions" version of the jar from sources,
renamed it to match the "1.0.0.6" and replaced the jar used under eclipse by
fosstrack. This way fosstrack is behaving as expected
It seems to me that the java version of the LLRP protocol is used by very few
people and not developed/tested as much as other versions. You should link to
svn and build it by yourself if you want a more stable build.
Best regards
Fabio.
2010/10/14 <[email protected]>
Hello,
I have created a RifidiTag with the following EPC code : 00 00 00 00
30 74 02 18 44 01 06 40 07 30 04 6D
I want to send a llrp-message from Fosstrak to write in the UserMemory
of this specific tag.
So I define an Rospec and an AccessSpec to filter on this tag. Below
the defined AccessSpec :
<?xml version="1.0" encoding="UTF-8"?>
<llrp:ADD_ACCESSSPEC
xmlns:llrp="http://www.llrp.org/ltk/schema/core/encoding/xml/1.0";
xmlns:Impinj="http://developer.impinj.com/ltk/schema/encoding/xml/1.0";
Version="1" MessageID="5">
<llrp:AccessSpec>
<llrp:AccessSpecID>1</llrp:AccessSpecID>
<llrp:AntennaID>0</llrp:AntennaID>
<llrp:ProtocolID>EPCGlobalClass1Gen2</llrp:ProtocolID>
<llrp:CurrentState>Disabled</llrp:CurrentState>
<llrp:ROSpecID>1</llrp:ROSpecID>
<llrp:AccessSpecStopTrigger>
<llrp:AccessSpecStopTrigger>Operation_Count</llrp:AccessSpecStopTrigger>
<llrp:OperationCountValue>1</llrp:OperationCountValue>
</llrp:AccessSpecStopTrigger>
<llrp:AccessCommand>
<llrp:C1G2TagSpec>
<llrp:C1G2TargetTag>
<llrp:MB>2</llrp:MB>
<llrp:Match>1</llrp:Match>
<llrp:Pointer>32</llrp:Pointer>
<llrp:TagMask>ffffffffffffffffffffffff</llrp:TagMask>
<llrp:TagData>30740218440106400730046d</llrp:TagData>
</llrp:C1G2TargetTag>
</llrp:C1G2TagSpec>
<llrp:C1G2Write>
<llrp:OpSpecID>1</llrp:OpSpecID>
<llrp:AccessPassword>0</llrp:AccessPassword>
<llrp:MB>3</llrp:MB>
<llrp:WordPointer>0</llrp:WordPointer>
<llrp:WriteData>0011 000A 2000 0419 0730 046D
0100</llrp:WriteData>
</llrp:C1G2Write>
</llrp:AccessCommand>
<llrp:AccessReportSpec>
<llrp:AccessReportTrigger>End_Of_AccessSpec</llrp:AccessReportTrigger>
</llrp:AccessReportSpec>
</llrp:AccessSpec>
</llrp:ADD_ACCESSSPEC>
But, it doesn't filter on this tag.
Where is the problem ? the definition of the filter is wrong or there
is a bug in Rifidi Toolkit (I'll also post this mail in the Rifidi Community) ?
Can you just tell me if I have understood correctly the use of
filtering in AccessSpec to retrieve this tag ?
Thank you in advance for your help.
Wafa.
Picture (Metafile)
Wafa SOUBRA
Orange Labs
905, rue Albert Einstein
06921 - Sophia Antipolis Cedex
[email protected] <mailto:[email protected]>
Picture (Metafile)
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
--
Fabio Bondioli
Autentieweb s.r.l. - http://www.autentiweb.com
via dei Marmorari 84 - 41057 - Spilamberto (MO) - ITALY
TEL: +39 059 7862702
FAX: +39 059 784615
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
