2010/12/2 Tóth András <to...@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 <to...@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 <ma...@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 <ma...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
