I can confirm that with this fix to TwoBitField Class now LTK Java works as expected related to bank selection in read/write operation.
Thanks and regards Fabio Basil Gasser ha scritto: > Fabio, you are correct. TwoBitField is encoded/decoded LSB first, so > this is wrong. > I will fix it and commit the code asap, you could then build it from > source to get the correct version. > > thanks & regards. > > Basil > > On Thu, Jan 7, 2010 at 9:46 AM, Fabio Bondioli > <[email protected] <mailto:[email protected]>> wrote: > > 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] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel > > > ------------------------------------------------------------------------ > > > > > > Nessun virus nel messaggio in arrivo. > > Controllato da AVG - www.avg.com <http://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] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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.129/2605 - Data di rilascio: > 01/07/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
