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]>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]
> > 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
>
------------------------------------------------------------------------------
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

Reply via email to