I'm still here :D I've made some investigation and now I'm sure that TwoBitField sends it's bit in the wrong order to the reader.
Regarding LLRP specifications bit array should be sent to the reader in MSB order. encodeBinary and decodeBinary send/receive it in LSB order. I've done this test: I've created this ADD_ACCESS_SPEC <?xml version="1.0" encoding="UTF-8"?> <llrp:ADD_ACCESSSPEC xmlns:llrp="http://www.llrp.org/ltk/schema/core/encoding/xml/1.0"; Version="1" MessageID="5"> <llrp:AccessSpec> <llrp:AccessSpecID>1</llrp:AccessSpecID> <llrp:AntennaID>1</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>1</llrp:MB> <llrp:Match>1</llrp:Match> <llrp:Pointer>0</llrp:Pointer> <llrp:TagMask>00000000000000000000000000000000</llrp:TagMask> <llrp:TagData>00000000000000000000000000000000</llrp:TagData> </llrp:C1G2TargetTag> </llrp:C1G2TagSpec> <llrp:C1G2Read> <llrp:OpSpecID>1</llrp:OpSpecID> <llrp:AccessPassword>0</llrp:AccessPassword> <llrp:MB>1</llrp:MB> <llrp:WordPointer>0</llrp:WordPointer> <llrp:WordCount>6</llrp:WordCount> </llrp:C1G2Read> </llrp:AccessCommand> <llrp:AccessReportSpec> <llrp:AccessReportTrigger>End_Of_AccessSpec</llrp:AccessReportTrigger> </llrp:AccessReportSpec> </llrp:AccessSpec> </llrp:ADD_ACCESSSPEC> I've sent it to the reader I've sniffed the transmission using wireShark and sent the sniffed protocol to the online LLRP protocol decoder (http://llrp.org/tools/decode.html) The returned xml is this: <Message from_ip="192.168.1.27" from_port="3334" to_ip="192.168.1.212" to_port="5084"> − <llrp:ADD_ACCESSSPEC Version="1" MessageID="5"> − <llrp:AccessSpec> <llrp:AccessSpecID>1</llrp:AccessSpecID> <llrp:AntennaID>1</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>true</llrp:Match> <llrp:Pointer>0</llrp:Pointer> <llrp:TagMask Count="128">00000000000000000000000000000000</llrp:TagMask> <llrp:TagData Count="128">00000000000000000000000000000000</llrp:TagData> </llrp:C1G2TargetTag> </llrp:C1G2TagSpec> − <llrp:C1G2Read> <llrp:OpSpecID>1</llrp:OpSpecID> <llrp:AccessPassword>0</llrp:AccessPassword> <llrp:MB>2</llrp:MB> <llrp:WordPointer>0</llrp:WordPointer> <llrp:WordCount>6</llrp:WordCount> </llrp:C1G2Read> </llrp:AccessCommand> − <llrp:AccessReportSpec> <llrp:AccessReportTrigger>End_Of_AccessSpec</llrp:AccessReportTrigger> </llrp:AccessReportSpec> </llrp:AccessSpec> </llrp:ADD_ACCESSSPEC> </Message> As you can see, the transmitted MB is 2, not 1 so I'm pretty sure I'm right. Fabio Bondioli ha scritto: > Hi, > I'm new to this list and I wrote because I found an annoiyng behaviour > with the java toolkit. > > When creating AccessSpec, it seems that the TwoBitField Class used to > parse the MB parameter for C1G2TargetTag, C1G2Write, C1G2Read, ecc is > wrong in regarding the bit order. > > Specifyng a MB value of "2" refers to the EPC bank while an MB value of > "1" refers to the "TID" bank but it's supposed to be the exact opposite. > The "bug" appears both creating objects from java code and from xml code. > This bug appears also when using the fosstrak llrp commander plugin. > > All the example I found on Internet (no one in java but the xml should > be the same, no?) use "1" as MB parameter for EPC bank and "2" for TID bank. > > So it's this really a bug or I've missed somethig? > > Thanks for any reply > > Best Regards > Fabio > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > llrp-toolkit-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel > ------------------------------------------------------------------------ > > > Nessun virus nel messaggio in arrivo. > Controllato da AVG - www.avg.com > Versione: 8.5.432 / Database dei virus: 270.14.126/2601 - Data di rilascio: > 01/05/10 07:35:00 > > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
