hi all, Lorischider came up with the problem described in his first e-Mail, seems to be the same or at least similar issue as reported earlier this year. ( http://sourceforge.net/mailarchive/message.php?msg_name=4BDB1DD4.5070808%40autentiweb.com )
The reader used, however, is a different one, I attached the stack trace which contains also a Hex Dump of the message. Could the firmwares of the two readers cause the same problem? greets Basil On Wed, May 26, 2010 at 12:05 PM, floerkem <[email protected]> wrote: > > Is this the same problem that was reported on the mailing list before? I > remember that there was an issue with a certain firmware update by Impinj. > > Christian > > PS: Can you guys keep the discussion on the LTK mailing list? Otherwise, we > will be discussing the same issues repeatedly. > > On May 26, 2010, at 8:57 AM, Basil Gasser wrote: > > hi, > > seems like your reader is returning an illegal value. In the stack trace > you see the decodeBinary method which tries to decode a message. A illegal > argument exception is thrown when trying to decode > ImpinjBlockPermalockResult, so either the reader is returning a illegal > value or whe have a bug. > Using the Hex dump given by the stack trace, we should be able to figure > out what's going on. I'll look into this on the weekend. > > Meanwhile, can you run your application in debug mode, setting a > breakpoint in ImpinjBlockPermalockOpSpecResult.decodeBinarySpecific? > > Walking through this method step by step should exactly tell us what's > causing the problem. > > Thanks, > > Basil > > On Tue, May 25, 2010 at 9:32 PM, Lorischider Honório Resplandes da Silva < > [email protected]> wrote: > >> Hello >> >> I was doing some tests while I wait your answer. >> >> I connected my application to the reader without using the mine and did >> the same mistake then I think the problem is another. >> >> I would expect any notification. >> >> Sincerely, Lorischider >> >> ---------- Forwarded message ---------- >> From: Lorischider Honório Resplandes da Silva <[email protected]> >> Date: 2010/5/25 >> Subject: Fwd: [IMPINJ] Help with ltk configuration >> To: [email protected] >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Lorischider Honório Resplandes da Silva <[email protected]> >> Date: 2010/5/21 >> Subject: Re: [IMPINJ] Help with ltk configuration >> To: Basil Gasser <[email protected]> >> Cc: [email protected], [email protected] >> >> >> Hello, >> >> First, thanks for the reply! I will give you the background of my >> problem and some files attached to aid (the stack trace, the rospec >> and class that I use to test). >> >> I'm participating in a project aiming to find objects (people, etc.) >> within an closed environment. I purchased the Impinj Speedway reader >> Revolution 420. Initially came to the conclusion that the RSSI could >> use for testing the distance tag / antenna. >> >> I noticed that if a tag was in the area of more than one antenna, only >> come to notice TagReportData in one. Searching I discovered that I >> could recompile the extensions added LTKToolkit manufacturer Impinj >> (version Speedway Revolution Octane 4 2 0). I did this successfully >> and solved my problem. (Despite having encountered problems in the >> code itself as some try / catch is not completed and a parameter xs: >> int the xml not recognized but that is another matter ...). Tested and >> worked. >> >> When starting the tests I realized that no one could standardize the >> RSSI for distance tag / antenna. Again in research, I discovered that >> there was a recent firmware upgrade for the equipment (version >> Speedway Revolution Octane 4 4 0) with interesting updates as >> ImpinjEnablePeakRSSI, and ImpinjEnableRFPhaseAngle >> ImpinjEnableSerializedTID. I upgraded the firmware but the error >> happened with these extensions that you have mentioned in previous >> email. Yes, the error occurs in the framework mine. If I do not place >> these extensions in ROSPEC the application functions normally. >> >> I'm sending attached the stack trace, the rospec and the class that I >> realize the tests and the manufacturer's specifications. >> >> Thanks in advance. >> >> >> 2010/5/21 Basil Gasser <[email protected]> >> >> hi, >>> >>> >>> To me it doesn't look like the extension is the problem as the exception >>> is caused by mina which is the framework used on the network layer so I >>> assume there is something wrong in the connection from your application to >>> the reader. >>> >>> Can you give some more information, maybe send the whole stack trace and >>> some source code? >>> >>> >>> thanks, >>> >>> Basil >>> >>> On Thu, May 20, 2010 at 8:30 PM, Lorischider Honório Resplandes da Silva >>> <[email protected]> wrote: >>> >>>> Helo, >>>> >>>> I´m trying to use a new extension of Impinj reader (octane 4.4) with the >>>> ltk toolkit, but my application fails after start the ROSpec. >>>> The returned error is: >>>> org.apache.mina.filter.codec.ProtocolDecoderException >>>> >>>> The new extension that I use is ImpinjEnablePeakRSSI. I observed, using >>>> the LLRP Commander, that RO_ACCESS_REPORT is being sent (see the attached >>>> file). >>>> >>>> Even I having added the extensions, it seems that LLRP toolkit cannot >>>> recognize the RO_ACCESS_REPORT containing the custom data. >>>> >>>> Is there anything that I forgot? Help me, please. >>>> >>>> Best Regards, >>>> >>> >>> >> >> >> > >
------------------------------------------------------------------------------
_______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
