Yes this is exactly what I mean. If I want to write to EPC bank, according to C1G2 specifications, I have to write to MB = 1 but using C1G2Write Access command in LLRP I actually need to write to MB=2 that's sound totally wrong to me. To Read/Write to TID Memory bank I've to write to MB=1 so TID bank and EPC bank seems to be swapped in Java LLRP Toolkit.
I'm using llrp toolkit 1.0.0.6 with Impinj Speedway and Revolution readers and monza2/3 tags. I think Paul was correct since in an Impinj Java example they stated that trying to use Session 2 (session is specified with a TwoBitField also) worked in NET implementation but failed in Java implementation and I think this is because in java Session 2 became Session 1 and vice-versa. At the moment I' m absolutely sure that TwoBitField messed up bit order or at least it's handled ok in TwoBitField but it's sent to the reader in the wromg order when using twoBitField in messages. Regarding to bug 2796315, probably before the fix encoding/decondig of twobitField was wrong but actually, at least, sending twobitField to reader is not handled correctly in my opinion. Regards Fabio Chris Delaney ha scritto: > > Basil, > > > > I think you are referring to the enumeration for the > C1G2LockDataField, which also has an entry for User Memory (value 4). > For the MB field within C1G2Read, C1G2Write, etc., there is no > enumeration defined within the LLRP Specification. But if you look in > the C1G2 Spec (section 6.3.2.1), they are defined as: > > > > 0: Reserved > > 1: EPC > > 2: TID > > 3: User > > > > Thanks, > > > > Chris > > > > ------------------------------------------------------------------------ > > *From:* Basil Gasser [mailto:[email protected]] > *Sent:* Tuesday, January 05, 2010 11:29 PM > *To:* LLRP Toolkit Development List > *Subject:* Re: [ltk-d] Bug in TwoBitField Java class? > > > > hi all, > > according to llrp specification the memory banks are defined as following: > 0 Kill Password > 1 Access Password > 2 EPC Memory > 3 TID Memory > > Fabio, can you provide a code sample where you explain what you think > is going wrong and I will look into it. Too add: internally, > TwoBitField is a Array of Bits, so maybe somewhere we mixed up MSB and > LSB but to find out where, the code sample would help. > > greets, Basil > > On Tue, Jan 5, 2010 at 7:11 PM, Luciano Koenigkan <[email protected] > <mailto:[email protected]>> wrote: > > Hi Fabio, > > I'm using this in java accessspec xml and work fine for me: > > <AccessCommand> > <C1G2TagSpec> > <C1G2TargetTag> > <MB>2</MB> > <Match>true</Match> > <Pointer>32</Pointer> > <!--GID-96 looks like hex 300035 --> > <!-- Use the mask so the 11 remaining PC bits are > don't care --> > <TagMask>ffffffffffffffffffffffff</TagMask> > <TagData>100000000000000000000001</TagData> > > </C1G2TargetTag> > </C1G2TagSpec> > <!--read the first two words of user memory--> > <C1G2Write> > <OpSpecID>1</OpSpecID> > <AccessPassword>0</AccessPassword> > <MB>2</MB> > <WordPointer>2</WordPointer> > <WriteData>0000 0000 0000 0000 0000 0002</WriteData> > </C1G2Write> > </AccessCommand> > > Att. > > Luciano > > 2010/1/5 Fabio Bondioli <[email protected] > <mailto:[email protected]>> > > > > 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 > > > > ------------------------------------------------------------------------------ > 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.127/2603 - Data di rilascio: > 01/06/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
