Re: HID Report Communication with USB RFID Reader

2010/12/2 Tóth András <totha <at> iit.bme.hu>
>
> Hello
>
> Fist excuse me:
>
> Yes I have hard problems because I think I'm a little bit stupid. :(

Not at all, USB in general is hard to discuss.

>
> After:
>
> I have spoken about the URB 7! The snoop trace says that the first
>eight byte is the response to the URB 7 packet. I thought that the
>numbers of the URBs are not correct, but in this case the problem
>is that  I have sent the setup packet with the right data content, and
>it is also in wireshark too, but the JAVA API has thrown USB
>STALL exception. As you think this packet is in the right format
>and has the right data content.

URB 7, ok, that's the interrupt in buffer.  Like I said, you have to
submit a UrbIrp to the interrupt endpoint so the system will start
polling the endpoint.  Once the endpoint has data to send to you, it
will put it in that UsbIrp's buffer and return it to you.  For
interrupt in endpoints, you should always have a pending UsbIrp, and
you can queue up several to ensure the endpoint is continually polled.
 So are you submitting at least a single UsbIrp to the interrupt
endpoint/pipe that URB 7 corresponds to?

I know it's rather confusing, but the javax.usb spec was designed to
adhere as closely as possible to the USB spec, and the USB spec is a
hugely confusing beast.

>
> There two problem in my viewpoint. One of these is in the snoop
>log I can't find the GET_Request setup packet witch is necessary
>to indicate the device to send the data. As you mentioned the
>setup packet contains the buffer size. But you can see in the
>original log, there is 00 hex at that place. I find that this scale
>device can 8 bytes max data size, so I should download all of the
>information a lot of eight bytes. It would be enough at this point, if I
>could get the first eight byte...

I'm sorry, I still don't understand specifically what the problem
is...can you paste in the specific parts of your snoop trace that
you're talking about, and point out what data you are having trouble
with?

>
> The other problem is what I mentioned before, the number of the
>Set_Request URB is the 9th, but the data response comes with the
>7th number. I don't understand why, but it is very interesting if this
>device keeps the standard HID communication rules. I don't have
>the specification about this device, because we want to build this
>device to a home-care test environment.

This is typical with HID devices, data from the device almost always
comes in on the interrupt in pipe.  The only other alternative to get
data is to perform control pipe get_request commands.  Since the
interrupt in pipe is kind of "asynchronous" and thus can provide data
to the host immediately instead of waiting for the host to ask for it,
that is what is used.

I put "asynchronous" in quotes above because it isn't really
asynchronous - the host controller actually polls the device at a
interval defined in the device's descriptors.  However it won't poll
the device at all unless you have provided a buffer - which is why you
have to submit at least one UsbIrp to the interrupt in pipe.  That
UsbIrp will not complete until the device sends data, so typically you
would either use a dedicated Thread to get the interrupt in data, or
you could asyncSubmit() one or more UsbIrps and add a UsbPipeListener
to the pipe to handle the irps as they complete (make sure to
asyncSubmit a new UsbIrp for each one that completes, so you always
have at least one buffer pending on the interrupt pipe).

>
> Thank you a lot, you help so much, but I can't explain my problem exactly. I think it is not clear at all, but it
is not a usual USB communication problem.
>
> Best Regards
> András Tóth
> PhD Student
>
> 2010.12.02. 20:07 keltezéssel, Dan Streetman írta:
>
> Ok, I'm still having a pretty hard time following what your problem is.
> You mentioned a specific data pattern, and in your snoop trace it looks like you are talking about "URB 9"?
 If so, then that command is a control transfer out (meaning you set the contents of the data array, and the
device reads it; for control in transfers, you provide a data buffer, and the device writes to it).  Are
you sending this URB with the right setup packet as well as the correct data content?
>
> On Thu, Dec 2, 2010 at 6:03 AM, Tóth András doktorandusz <totha <at> iit.bme.hu> wrote:
>>
>> Hello
>>
>> You are right! But the problem is, that anyway a try to send this command with 10 00 00 00 00 00 00 data
content, the response of the scale device is USBStall Exception. I think the cause of this is the device
cannot understand this setup packet. And the other interesting think is, is this setup packet is for
Set_Request step, than where is the Get_Request setup pocket in the log. I can't find it.
>>
>> After I has collect the setup packet I check the communication with wireshark. There is the same setup
packet. Every time I try to send this the device throw exception.
>>
>> So the main problem is, if I would like to copy the steps from the specification, the device has thrown
misunderstood exceptions. Than I think, I should send the same packets what is in the original log file.
But the device has thrown exception too. I thought that the log file has explain another communication
protocol, what I can't understand and the expert USB JAVA programmers can help me.
>>
>> Thank you very much for your help! Excuse me for disturbing you!
>>
>> Best Regards
>>
>> András Tóth
>>
>> P.s.: Excuse me for my english... :(
>>
>> 2010-12-01 17:09 keltezéssel, Dan Streetman írta:
>>
>> >Because I don't know the parameters to set the right
>> >Set_Request setup packet with the right data content. The only
>> >chance is to copy it from the sniffer log, but I don't find this
>> >information! There is no 21 hex and A1 hex communication
>> >packets in the sniffer!
>> I'm still not completely sure I understand what you're asking, but I think you are asking what in the
sniffer log indicates what values to use for the set-request and get-request commands?
>> Your sniffer log shows exactly what to put into the control setup packet, it's shown as (for example):
>> SetupPacket          =
>>    00000000: 21 0a 00 00 00 00 00 00
>> See the USB spec for specific details on the setup packet; essentially, byte 0 is the bmRequestType, byte
1 is bRequest, bytes 2 and 3 are wValue, bytes 4 and 5 are wIndex, and bytes 6 and 7 are the transfer buffer
length.  Note that all the 2-byte fields are little-endian.
>> Is that what you were asking?
>> 2010/12/1 Tóth András <mater <at> sch.bme.hu>
>>>
>>> Hello,
>>>
>>> Excuse me, but one question !
>>>
>>>
>>> Hello,
>>> Brian Weischedel is the maintainer of javax.usb now, I am not directly involved in it anymore.  You
should send future questions to the mailing list and/or him.
>>>
>>> To address below, I don't quite understand what you are asking, although I'll point out what may be a key misunderstanding:
>>> >The device has one control channel and it's type is interrupt.
>>> Actually all USB devices have a "Default Control Pipe" (DCP), which is almost always the only
Control-type pipe/endpoint on the device.  Many devices also have other pipes/endpoints.  HID-type
devices, which it sounds like may be what you have, usually have a single interrupt-in pipe in addition to
the DCP (although the HID specification allows for more interrupt pipes).
>>> >In this topic I found that I have to send a SET_Request message ,
>>> >after this I can get the data with Get_Request command.
>>> Those are Control-type commands; you would not use those on the interrupt pipe.  You have to execute
those commands on the DCP.
>>> >I have analyzed
>>> >the log from the USB Sniffer and I didnt find this conversation steps.
>>> >I found a command witch has stated with 21 hex but I has not been
>>> >followed with a1 command.
>>>
>>> You have to send both the commands yourself.  You create a UsbControlIrp with the appropriate setup
packet fields, then submit it to the UsbDevice.  First submit the SET command, then the GET command.
 Also, some devices refuse to operate unless their interrupt-in endpoint is being polled so you should
make sure to always have an outstanding UsbIrp waiting for data on the device's interrupt in endpoints.
>>>
>>> I really understand and thank you very much for these information, but this step I couldn't found in the
sniffer log. Because I don't know the parameters to set the right Set_Request setup packet with the right
data content. The only chance is to copy it from the sniffer log, but I don't find this information! There is
no 21 hex and A1 hex communication packets in the sniffer!
>>>
>>>
>>> Excuse me, kind regards
>>> András Tóth
>>>
>>>
>>> If you have more questions, reply back to the mailing list and hopefully Brian and/or someone else on the
list can help.
>>>
>>> 2010/11/30 Tóth András <mater <at> sch.bme.hu>
>>>>
>>>> Excuse me Mr Streetman
>>>>
>>>> I'm a PHD student at Budapest University of Technology and Economics in Hungary. I'm working on a Human
Scale device USB communication protocol in an AAL project. We would like to use a public scale device of
Beurer Inc, but this device has no datasheet about it's USB protocol. The first step of its method is
measuring the humen weight and fat percent and so on. After the measure phase we can connect the device to
the PC via USB port. The scale device was packed together with an MFC program witch can read all of the
information about the patient. At university I have the task to connect this device to Linux. The main plan
was that to develop a data reading method witch can realize the scale device has connected to the device and
start the reading process at the PC.
>>>>
>>>> We are working in OSGi system, but i would like to prove a solution with a simple javax JSR80 JAVA
application first. If it can solve this problem we can implement it in OSGi environment. So as I mentioned I
try to implement it with javax API. I have a lot of log file about the communication. I used google to get some
information, there I have met your name.
>>>>
>>>> As read your experiences and help for the mates on the Internet. I can solve the communication between
the PC and Scale device. I can send the control commands to the device and a have got answers too. But I cant
read the stored data.
>>>>
>>>> The device has one control channel and it's type is interrupt. In this topic I found that I have to send a
SET_Request message , after this I can get the data with Get_Request command. I have analyzed the log from
the USB Sniffer and I didnt find this conversation steps. I found a command witch has stated with 21 hex but I
has not been followed with a1 command.
>>>>
>>>> Please Excuse me for disturbing you. I would be very thankful, if you can help me. i can't understand how
indicate the application the scale device to start sending data. The other problem is, I can't guess what
should I do in JSR80 API to copy this method.  I will copy a part of my log to the end of my letter. Can you help
me to get the answer witch commands can be good for getting the magic informations or how can I make the scale
device to send those?
>>>>
>>>> Tank you very much
>>>> András Tóth
>>>> PhD Student
>>>
>>>
>>
>>
>
>

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
javax-usb-devel mailing list
javax-usb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel