On Jan 10, 2014, at 4:46 PM, Ariel Wainer wrote:> On 10/01/14 01:53, Charles Lepple wrote: >> I am curious about why the Interrupt Out packet is sent by the Windows software if it isn't to turn off the UPS. Is it possible to do some more testing with shorter timeouts so that the battery doesn't get depleted? You would need to record the exact time when it shuts down, I think. > > Sure, I will do the test during the weekend.If it's not too late for your tests, I committed a v0.03 to the 'atcl' branch, with string matching to avoid confusion with other 0001:0000 devices.> I'm not sure if it's related, but, using the driver these days I noted > that I sometimes the connection to the ups drops and resets, like this, > while I hear the click sound of a relay:We've definitely heard of cases where an UPS will generate enough noise on the USB bus that it disconnects. The best we can do is try to re-attach to the same device when it comes back. The current driver should handle this - if not, please send debug output from the driver. (Probably at least -DDD) -- Charles Lepple clepple at gmail
On 11/01/14 15:27, Charles Lepple wrote:> On Jan 10, 2014, at 4:46 PM, Ariel Wainer wrote: > >> On 10/01/14 01:53, Charles Lepple wrote: >>> I am curious about why the Interrupt Out packet is sent by the Windows software if it isn't to turn off the UPS. Is it possible to do some more testing with shorter timeouts so that the battery doesn't get depleted? You would need to record the exact time when it shuts down, I think.Ok, I did some more testing, with or without load and the observed result is that te UPS completly powers down arround 30 seconds after the interrput out packet that is sent during windows shutdown process. Strangely, when this happens I don't see any new packets on the capture. The settings used for this test are: 1 minute both for shutdown on AC fail and shutdown on low battery (I don't thing this one has any effect).> If it's not too late for your tests, I committed a v0.03 to the 'atcl' branch, with string matching to avoid confusion with other 0001:0000 devices. > >It wasn't, the output of the new driver: root at lucy:/usr/local/ups/bin# ./nutdrv_atcl_usb -a ups -DDD -u root Network UPS Tools - 'ATCL FOR UPS' USB driver 0.03 (2.7.1-signed-18-g55ef54f) Warning: This is an experimental driver. Some features may not function correctly. 0.000000 debug level is '3' 0.001095 Searching for USB device... 0.528238 Checking USB device [1d6b:0001] (009/001) 0.591280 Checking USB device [1d6b:0001] (008/001) 0.655340 Checking USB device [1d6b:0001] (007/001) 0.719322 Checking USB device [073a:2230] (006/003) 0.719407 Checking USB device [1bcf:0002] (006/002) 0.723383 Checking USB device [1d6b:0001] (006/001) 0.723482 Checking USB device [1d6b:0003] (005/001) 0.723590 Checking USB device [0001:0000] (004/007) 1.388834 read: (8 bytes) => 01 00 00 00 00 00 00 00 1.388919 reply[0] = 0x01 -> OB 1.389236 dstate_init: sock /var/state/ups/nutdrv_atcl_usb-ups open on fd 5 2.436960 read: (8 bytes) => 01 00 00 00 00 00 00 00 2.437100 reply[0] = 0x01 -> OB 3.485059 read: (8 bytes) => 01 00 00 00 00 00 00 00 3.485142 reply[0] = 0x01 -> OB 5.397260 read: (8 bytes) => 01 00 00 00 00 00 00 00 5.397301 reply[0] = 0x01 -> OB 7.397567 read: (8 bytes) => 01 00 00 00 00 00 00 00 7.397609 reply[0] = 0x01 -> OB 9.397750 read: (8 bytes) => 01 00 00 00 00 00 00 00 9.397801 reply[0] = 0x01 -> OB 11.406018 read: (8 bytes) => 01 00 00 00 00 00 00 00 11.406062 reply[0] = 0x01 -> OB 13.406318 read: (8 bytes) => 01 00 00 00 00 -------------- next part -------------- A non-text attachment was scrubbed... Name: 2014-01-12-usbmon-short-timeout.pcapng.gz Type: application/gzip Size: 4346 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140112/97ff5929/attachment.bin>
On Jan 12, 2014, at 11:07 AM, Ariel Wainer wrote:> On 11/01/14 15:27, Charles Lepple wrote: >> On Jan 10, 2014, at 4:46 PM, Ariel Wainer wrote: >> >>> On 10/01/14 01:53, Charles Lepple wrote: >>>> I am curious about why the Interrupt Out packet is sent by the Windows software if it isn't to turn off the UPS. Is it possible to do some more testing with shorter timeouts so that the battery doesn't get depleted? You would need to record the exact time when it shuts down, I think. > > Ok, I did some more testing, with or without load and the observed > result is that te UPS completly powers down arround 30 seconds after the > interrput out packet that is sent during windows shutdown process.Hmm, then the driver should be doing the same thing. What does the debug output look like when you run ./nutdrv_atcl_usb -a ups -DDD -u root -k ?> Strangely, when this happens I don't see any new packets on the capture. > The settings used for this test are: 1 minute both for shutdown on AC > fail and shutdown on low battery (I don't thing this one has any effect).Where do you mean? It looks like the host resets the USB port about 7 seconds after sending the Interrupt Out (packet #221 in the latest capture). If the Windows application doesn't reconnect, that would explain the lack of Interrupt In packets after it is finished enumerating.>> If it's not too late for your tests, I committed a v0.03 to the 'atcl' branch, with string matching to avoid confusion with other 0001:0000 devices. >> >> > > It wasn't, the output of the new driver:If it works for you, then that works for me. Thanks for testing, -- Charles Lepple clepple at gmail