Read this on the understanding that I really have not grasped the usb process in terms of what are defined as packets, frames, urbs or all the other bits, so I have probably used the wrong terms.
I have done a bit more capture, this time using a trial version of USBlyzer. This is rather more illuminating than USBPcap because it shows the read requests and when the output packet is acknowledged by the device - as we get with the Linux capture. I started USBlyzer, plugged in the wmr300 console and then selected the port for logging, started logging and started WOSP. The first relevant thing I saw was the initial a6 packet did not return a 57. The read request was issued, and 100ms later the 73 packet was written. So, the windows software times out as well, and ignores it. The read request for the packet 73 ACK from the wmr300 actually returns with its first D4. WOSP then happily acks this packet and forgets about wondering why the ack from the packet 73 failed to arrive. The other newly visible characteristic is the sequencing of events. USBLyzer report with a resolution of microseconds, and does actually resolve differences of 1 microsec. However, things seem out of sequence at the millisecond level. For example, at a stage when WOSP is just reading current results... time zero...packet D3 comes in; 6us usb read request sent out 13us software writes ACK D3 01 1000us packet DC comes in 1006us usb read request 1013us wosp writes ACK DC 01 2000us device sends "write success" handshake 2998us device sends another "write success" handshake 3999us device sends yet another "write success" handshake -- slight break, then 0.63 seconds later a D3 packet arrives. Elsewhere there have been backlogs of up to 16 sequential write success handshakes. There are lots of places with jumps of very close to 1ms, which leaves me suspicious of the validity of the timing, however if the timing is real then it implies significant asynchrony in the dataflow. I can only understand this if the WOSP code is multi-threaded, with different threads for read and write, or if the i/o routines are non-blocking. Perhaps there are limitations in the usb code on the wmr300 console that cause lockups when we try to access it with single-threaded blocking i/o. But I'm only guessing at this stage.
