En/na Luca Olivetti ha escrit:
> Hello,
> I'd like to write a driver (or a userspace program) to interface with
> this phone:
>
> http://www.topcom.net/productfiche.php?i=432&g=17
>
> I contacted topcom but I doubt they'll reply with the required
> information (besides, I doubt they are the real designer of these
> phones), so I'll have to do some sniffing under windows, however I'm
> having some problems with it (the program controlling the device hangs
> if I'm sniffing so it's kinda difficult to get the data).
Ok, I was sniffing the wrong device.
Looking at the data, I have a slight idea of the communication protocol:
1) status is read using URB_FUNCTION_VENDOR_DEVICE (always using the
same parameters)
2) commands are sent with one or more bulk transfers
3) the reply to 1) only comes back when a command has been executed or
(I suppose) some key has been pressed, so the reply could come back
after several seconds or immediately, depending on what's happening
4) right after the status reply, another URB_FUNCTION_VENDOR_DEVICE
(with different parameters) is used to read how many bytes the previous
status returned (wtf?)
5) all bulk transfers have exactly 8 bytes of data, the first byte is
alway 8x, where x tells how many of the following bytes are useful
(again, wtf?)
an example (processed with the parser.pl that comes with usbreplay):
000022: OUT: 000004 ms 018017 ms c0 04 02 50 00 00 80 00 <<< f0 04 22
00 1e 3c
000023: OUT: 003678 ms 018021 ms c0 04 0d 50 00 00 02 00 <<< 00 06
000024: OUT: -03668 ms 021699 ms c0 04 02 50 00 00 80 00 <<< f0 02 8c 8c
000025: OUT: 003584 ms 018031 ms BULK[00003] >>> 84 f0 02 22 22 00 00 00
000026: OUT: 000040 ms 021615 ms BULK[00003] >>> 87 f0 0a 8c 01 02 00 00
000027: OUT: 000048 ms 021655 ms BULK[00003] >>> 85 00 00 00 00 8f 00 00
000028: OUT: 020599 ms 021703 ms c0 04 0d 50 00 00 02 00 <<< 00 04
urb 22 is a status read that returns 6 bytes
urb 23 says that the previous status was 6 bytes ("<<< 00 06")
urb 24 is another status read, it was sent before urb 25 but the reply
came back after urb 27 (note the second ms column that tells the
absolute time)
urb 25 is the first part of a command (probably the command code), with
4 ("84") useful bytes
urb 26 is the continuation of the command (data?), 7 useful bytes (or
maybe it's another command altogether: there are 3 seconds from urb 25)
urb 27 is the last part of the command, 5 useful bytes
urb 28 says that the previous status (urb 24) was 4 bytes long
Does it make sense? Does it ring a bell to someone that saw a similar
device?
Bye
--
Luca
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
