> Here are a few more observations from packet captures using usbpcap and
> wireshark.
>
1. *unknown 6th byte at end of ACK and a6 packets.*
I think these are probably rubbish left over in a static buffer. The byte
at this position occasionally get used by other payloads, at which time its
contents are changed to something else.
2. *Battery level*
I have packet captures covering the time from when the console notices low
battery to when the WOSP software shows it has seen - but I still cannot
see which packet carries the information. I can't see it in packet 0x57.
3. *Startup*.
This is the most complex description, as there are three different
scenarios.
3.1 *WOSP running, and then the is USB connected*:
This does not correspond to weewx usage, but I thought I'd report it anyway.
1. status scan of hub ports replies with status and status-change flags
set to indicate PORT_CONNECTION
2. IN packet with flag 0x04 (1 byte payload) arrives in from console
3. Windows driver is still messing around with hub port 2- getting
status, clearing flags, resetting
4. steps 2,3 repeated twice
5. gets descriptor (vendor, product codes, configurations, interfaces
6. (sometimes) messes about with getting HID bootloader status (3 times)
7. send out an a6 packet to device.
8. packet 57 in in response.
9. packet 73 out
10. ACK packet in.
11. live data packet in.
3.2 *USB plugged in (idle for a while), then WOSP started*.
- capture starts: time 0: gets status for each port (1 to 6)
- USB plugged in: time ~ 10 s# status scan of hub ports replies with
status and status-change flags set to indicate PORT_CONNECTION
1. Windows driver is messing around with hub port 2- getting status,
clearing flags, resetting
2. within this time, packet with flag 0x04 (no data payload) arrives
in from console
3. steps 2,3 repeated twice
4. gets descriptor (vendor, product codes, configurations, interfaces
- WOsP started: at ~ 27s
1. messes about with getting HID bootloader descriptor (3 times)
2. send out an a6 packet to device.
3. packet 57 in in response.
4. packet 73 out
5. ACK packet in.
6. live data packet in.
3.3 *System logging, then WOSP stopped, capture started, and WOSP restarted
after ~30seconds* .
1. console sending, no ACKS
2. a bit of traffic to hub or usb controller
3. send out an a6 packet to device.
4. packet 57 in in response.
5. packet 72 out, to which there is NO ACK
6. live data packet in.
3.4 *WOSP has been running, logging data, and exits delays a long time
(several minutes) then restarts*.
This is the same as the last section of 3.2
Several mysteries, or at least gaps in my undertanding:
1. I thought usb peripherals in interrupt mode cannot send anything
until requested by the host. So when WOSP stops, what is causing the steady
stream of current weather that runs for about 100 seconds with no ACKs?
Does it imply the windows driver is interrogating any usb device to see if
it has anything to say? Is it only doing this because no software has the
device open, or does it do this preemptively all the time?
2. What condition makes WOSP decide to use packet 72 at startup rather
than 73, and why does one give an ACK and the other not (is that just a
bug?)
