Communication Lost in a Smart UPS 1500 with USB

[Anonymous user]

We have an APC Smart-UPS SC 1500 for a Windows 2003 Server. We are using the USB/Serial converter cable because the server system only have a single serial port working for another application. The Powershute Business Edition connects and works good for a while, but every 2 or 3 days there is a "Communication Lost" alert in the console and we must to restart the APC services to restore the connection with the UPS.

If you know something that can help me to resolve and correct this, I'll appreciate any help. Thank You!

[BillP]

Hi,

Three dell servers + three Smart UPS, same problem at all. Once a month, 14days, some days period. We solve unplug and plug usb cable, but the problem was reporting before more than half year and till now no solution here. Changing to usb 1.1 - did you mean go back about 5 years? Not possible !!

Really great job from APC :-). We are angry and disapointed.

Message was edited by: alftech

[BillP]

still nothing from APC?

[dslee_apc]

Is APC supplying the cables?

[BillP]

thank you both for your comments. i will make sure this gets passed along to the appropriate people researching the issue. if you are able to, we appreciate any other details you can provide about the setup where you are experiencing the issue to help resolve the issue faster.

[Anonymous user]

I am also seeing this problem on a Dell PowerEdge 2900

[Anonymous user]

We have an APC Smart-UPS SC 1500 for a Windows 2003 Server. We are using the USB/Serial converter cable because the server system only have a single serial port working for another application. The Powershute Business Edition connects and works good for a while, but every 2 or 3 days there is a "Communication Lost" alert in the console and we must to restart the APC services to restore the connection with the UPS.

If you know something that can help me to resolve and correct this, I'll appreciate any help. Thank You!

[Anonymous user]

I too have this issue, i also have many events where windows veto's a power request.

good to see i'm not alone

IBM X3650 with SBS2003 R2 and a 1500 USB connection.

if APC don't fix this i'm going to seek a refund from my vendor for a defective product.

[BillP]

dslee wrote:
Is APC supplying the cables?

They did for me

[BillP]

Can you give more information about how the "workaround" from APC looks like?

[BillP]

Can you give a little more detail on that work around. I have a user who has a UPS setup out of her home and she uses USB connection. It loses connection every few days. I've had to get her to fully reboot it and then other times I've noticed one of the USB ports wasnt functioning so we changed usb slot and it worked. That was 3 days ago, now it lost communication again. If you could give me a more thorough or picture of how the setup should be that would be great. Thanks.

[BillP]

Steps for PCBE 7.0.5

If the agent software has already been installed, best to uninstall it.
If you don't remember your username and password, uninstall the server and console, too.
Then install the driver for the serial-to-usb cable. This is done by running the setup program.
Now plug the serial end of the cable into the serial connector on your UPS.
Now plug the USB end of the cable into the computer. At this stage, the computer will recognise the device.
Then you install the agent software, as you would normally.
If you need the server component and previously uninstalled it, install it now.
If you need the console component and previously uninstalled it, install it now.

Pretty straight-forward, really.

[BillP]

So basically the workaround is to totally re-install the device? We are using the newest software 7.0.5. But I'll try that I guess cant hurt.

[Anonymous user]

Hello,

Have you reinstalled the drivers that come with the UPS? The drivers for the Serial to USB cable should be found on the CD that comes with the UPS.

Thanks.

[BillP]

The user uses a USB to USB cable to connect the UPS to the PC. Should I still try this workaround?

[BillP]

1. the newest version is 8
2. because of the way the agent looks at com ports and usb ports, it's easier to uninstall and reinstall than to try and move the UPS
3. If by "device" you mean UPS, I guess it is partly a reinstall but ...
4. The key to this workaround is the SERIAL-TO-USB cable and its associated driver

[BillP]

the user doesnt have the serial to usb. I guess any serial to usb should work if they were to invest in it?

[BillP]

zwheat wrote:
the user doesnt have the serial to usb. I guess any serial to usb should work if they were to invest in it?

Hmmmm.

APC sent me the cable. In the device manager it comes up as a "Prolific USB-to-Serial Comm Port"
I wouldn't like to comment on whether or not any usb-to-serial cable would work.

[BillP]

interesting........i may have to setup a support session to get some answers. Thanks for all your replies, appreciate it.

[BillP]

i must point out to those who believe a serial-usb converter is the solution to actually read the OP.

He had a serial-usb cable and started this thread!

Am i right to assume that APC will be providing this "new improved" cable to APC owners?

Message was edited by: power

[Anonymous user]

I don't know if it's a fluke, but I've not had the dreaded "lost communication" event since the 8th Jan 2009. Prior to that I would get it every couple of weeks since June 2008.

I've not changed anything on the UPS or its setup... it'd be interesting to find out if it is a fluke or not - I guess I'll only know if I get another one!!!

FWIW mine is USB-USB on a Dell PE1900 with Windows SBS 2003. Powerchut 7.0.5.

If I get another one I'll report back.

[Anonymous user]

I have the identical problem as the original poster, the same UPS unit and O/S, and yes I've installed the drivers that came with the unit and it still loses communication after 2-3 days.

Any help regarding this would be greatly appreciated.

[Anonymous user]

Are you connected to a Hub? Direct to USB port? Have you tried a different port? Any other USB devices losing comm?

[Anonymous user]

The unit is connected directly between the computer (USB) and the UPS unit (serial). PowerChute 7.0.4 (Console, Server, Agent) is installed on the computer. I've tried four USB ports (a total of eight) and they all result in the same error. The mouse and keyboard are also USB and they've never had any connection issues with the ports.

I tried APC Online yesterday and got a quick reply suggesting to update to PowerChute 7.0.5 (doing that as we speak) and make sure there's no applications scanning the USB ports on the system, which I'm rather sure of isn't the case.

"The reasons why this happens can be different. You probably have some Anti Virus software or a Firewall installed. It could even be Windows Updates." - I have no Anti Virus or Firewall enabled. Surely a Windows Update could have caused it but I'd like details if available.
I find it odd that it would the connection would be so extremely sensitive when it comes to the USB port.

Thanks in advance for any further help.

[Anonymous user]

I have the exact same problem. I know that this has to do with the USB/serial cable. I have Version 7.0.5 and I need to restart the services too in order to re-establish the connection. This is getting pretty irritating. Perhaps an APC tech can give me the solution.

[TheNotoriousKMP_apc]

All,

I would recommend using this driver and seeing if it works. This was just put up by Prolific, who manufactures the cable, at the EOY 2007.

Please report back if this solves the problem, that way APC Technical Support can be updated.

http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303HX/Drivers/Generic/wd_pl2303_v20019v2028...

[Anonymous user]

Has anyone found a solution to this issue? I have been following this thread with much interest.

We had (maybe naively) standardized on APC UPSs for our server room, and have several dozen clinic-wide (each server, workstation and switch). Our servers almost all use Smart-UPS 1000 units.

One of the servers, a Dell Poweredge 1800, keeps losing communication with its SUA1000 (Smart-UPS 1000) UPS. It's using the included USB-USB cable. The default in Windows 2000 Server is to pause task scheduler and do some weird things when it thinks it's on battery power, and after losing communication with the UPS many many times over the past couple months, it has paused things and caused severe data corruption on our MSSQL database.

Now admittedly SUA1000's probably shouldn't be "relied on" for mission-critical servers but I certainly didn't expect it to just bring down our SQL service and corrupt data like that (Powerchute 8.0.1).

After multiple support chats with APC, they are finally sending a new SUA1000 to swap out with but cannot guarantee it beyond 5-7 business days (most of our equipment has next-day replacement guarantees).

I am wondering if this is a known issue similar to what others are experiencing. I would love to know if a switch to another brand is in order here.

[Anonymous user]

Spoke too soon. Had a lost communication event last night. Just getting one of the more tech savvy users at the client to do the old unplug/plug back in routine.

Very annoying.

[Anonymous user]

I've had an uptime of over six days now without any issues, hopefully the drivers resolved the issue completely.

Thanks alot for the replies.

[TheNotoriousKMP_apc]

Kott,

Was this due to the Prolific driver update at all? Just curious so I can keep track of issues like these and possible resolutions.

[Anonymous user]

So it would seem, before it lasted a maxium of 2-3 days, now it's up and running for over a week after I installed the drivers. Hopefully more than a coincidence.

[TheNotoriousKMP_apc]

Kott,

Thanks for the information. Let us know how it holds up after another week. That way we can see if the Self-Test plays any part in a possible comm loss. It shouldn't, by any means, but we want to eliminate that from the problem.

Thanks again.

[Anonymous user]

Still holding up after two weeks straight, we can safely assume the drivers did the trick?

[TheNotoriousKMP_apc]

Excellent news. I appreciate the information and feedback. Thank You.

[BillP]

As mentioned previously, we have had success with the serial-to-usb cable and device driver on a number of affected units. It has been 2 months since we installed the cable on the first UPS and we have implemented it on other servers progressively. NONE of the servers using the new cable have lost communication since installing it.

power wrote:
i must point out to those who believe a serial-usb converter is the solution to actually read the OP.
He had a serial-usb cable and started this thread!

I'm not convinced that he had a serial-usb cable. AFAIK, it isn't supplied as a standard so I suspect he really meant he was using the USB cable rather than the serial cable.

blackisle wrote:
Have added a serial port to the server and abandoned the serial-to-usb cable supplied. All running fine with the serial-to-serial cable supplied. Poor show from APC and certainly the last time I'll be buying from them. Good luck to you all with the hunt for a USB solution, from the sounds of things it's the serial controller in the UPS and short of a firmware update or change of controller chip I doubt this will ever be resolved.

Note that Blackisle also talks about a "supplied" serial-to-usb cable which, from the word "supplied" I interpret him to mean the USB cable. He also suggests "it's the serial controller in the UPS" whereas I believe it's the USB controller in the UPS which further supports my theory that he's using the terms interchangably.

To be clear, the APC UPS units typically come with two cables included. One is USB-USB and the other is a special Serial-Serial. If you have a spare serial port on the server, use the serial-serial cable. If you don't have a spare serial port on the server, you're likely to encounter the problem we're all complaining about.

If you don't want to have to install serial cards into the servers (and I didn't want to), the solution provided by our local APC support, although taking much too long to be provided, works well. It consists of a Serial-to-USB cable (serial at the UPS, USB at the server) PLUS a device driver.

If you have an open case with APC and they haven't come back to you with this solution, that's very poor support and just one more thing that APC needs to work on. Call your local support and tell them to send you the cable. Refer them to SR#C1-551495344 (Australia) if they argue. If you haven't yet logged an issue, why not?

To the APC people lurking in this forum (Bart? Jamie?), get someone to run a report across your support issue database (please tell me you have a consolidated, centralised support issue database), identify all the "lost communication" issues and send these poor people their cables and a link to the device driver, unsolicited. You just might retain them as a customer. Time to be proactive, my friends.

DAS

Message was edited by: dastafford.
Typo. It's been 2 months, not 6

[BillP]

2 more months roll by and still no response.....

[Anonymous user]

Smart-UPS 1000XL here.

Yes, I too experience communication agent drops with my Smart-UPS that is resolved by plugging and unplugging the USB cable.

Unfortunately, I live 2000 miles from the server and have to call in a consultant ($75/hour) to stop by the office and do this for me.

This occurs 2-3 times a year.

2-years later...

Any solutions yet?

[Anonymous user]

Just had someone finish the USB cable unplug and plug back in routine at the remote site. Communication restored.

Anyone have any ideas? I have tried everything mentioned to do from this thread focusing on the power management aspects of the issue (not allowing the device to be turned off to conserve power,etc.)

One thing I did that seemed to extend the duration between communication losses was to configure the APC unit via PowerChute to log every 1-minute versus the default. Perhaps this 1-minute zaps the connection and USB cable enough to keep it awake. This does seem to have extended the duration for me.

I also try and log in each day and query the UPS unit. Whether this helps I don't know but I have gone from losing communication once a month to 2-3 times a year recently.

Thanks for trying to get this fixed.

Message was edited by: localhost

[Anonymous user]

Have added a serial port to the server and abandoned the serial-to-usb cable supplied. All running fine with the serial-to-serial cable supplied. Poor show from APC and certainly the last time I'll be buying from them. Good luck to you all with the hunt for a USB solution, from the sounds of things it's the serial controller in the UPS and short of a firmware update or change of controller chip I doubt this will ever be resolved.

[BillP]

well, since this whole thing started i've been patiently waiting for a solution to come up to support you know, the USB - something that's a staple in modern computing.

The end of June sees us updating our Servers and UPS as well. I can say with certainty it will not be an APC solution, enjoy the GFC APC.

[Anonymous user]

localhost wrote:

One thing I did that seemed to extend the duration between communication losses was to configure the APC unit via PowerChute to log every 1-minute versus the default. Perhaps this 1-minute zaps the connection and USB cable enough to keep it awake. This does seem to have extended the duration for me.

I have also set mine to do this. I've had three drops since the beginning of the year... so maybe it does help slightly.

I think like Blackisle I may resort to Serial-Serial as it's just too annoying. When it happens on say a Friday evening, there's no-one on site until Monday morning to do the unplugging routine and I'm 300 miles from the server. As such I'm crossing my fingers that there isn't a prolonged outage during this time, otherwise the server would run down the UPS and just go off when the power fails without a graceful shut down. I'm also going to have to install a serial port on the server.

[Anonymous user]

Thank you for the clarification and summary DAS.

With that summary, everything is pretty much lined up now for APC to finish this off with some grace 🙂

Perhaps APC can supply a link to the device driver and at least give us a part # or description of the serial-to-usb cable so that we can then purchase it?

APC is still my preferred UPS solution, however, this is no doubt testing my loyalty. A device driver link and a part# would likely assist quite a number of customers.

Best, localhost

[Anonymous user]

Also, to add more info for an ultimate solution:

When communication is lost, the USB Root Hub (via device manager) shows an unidentified device attached. With good communication that attached device is labeled correctly in device manager as APC Battery BackUP.

(Power Management is off on that and all USB hubs, and disabling/enabling,remote computer reboot on that USB Root Hub does not help).

[Anonymous user]

Has anyone successfully installed that device driver remotely? I am assuming a reboot will be required. But, does one need to dis and reconnect the Serial-USB cable afterward? One would think a reboot is all that would be required. I ask as I plan on doing this remotely versus flying 2000 miles.

:)

[Anonymous user]

I have connected the Serial-USB cable and the new Prolific driver (PL303_1025) downloaded using the link from this thread on a test workstation. The original Prolific driver that came via APC did not work on Vista x64. Had to uninstall PowerChute Business edition as suggested in earlier post, to have Powerchute locate the device on the new USB serial port which is COM3 for me. Didn't recognize the APC without the uninstall. I will cross my fingers. Thanks DAS for all the technical support on this issue.

local

[BillP · Accepted solution]

in regards to this issue, let me post APC's official response to this. please dont shoot the messenger.

APC has found a small number of Smart-UPS customers experiencing intermittent communications loss when using the USB interface. To correct this issue customers are advised to use Serial Communications. If you are continuing to have communications loss, please contact APC Technical Support for assistance in configuring Serial Communications, or to request assistance in troubleshooting. Please ask the Technical Support Engineer to reference KBASE Document # 9651.+

i am going to lock this thread as far as asking for updates on the situation, etc but if you have an issue like this, please remember that you should be ruling out other things such as too many USB devices connected, faulty USB ports, etc before contacting APC support.

[BillP]

Hi there,

I have the same problem with a SMART UPS SUA100RMI2U connected via USB/USB to a HP Proliant DL385 with Windows Server 2003 x64 SP2.

I had a long discussion with APC service about defective USB cable or defective USV. I have replaced USB cable with no success, I even have replaced the USV, also no success. I tried the USV on a workstation with XP SP3. Here communication was very stable. They confirmed my problem and said that they are working hard on it, at last they gave me a pre-8.00 version of the Power Chute Agent, but that does also not work. Today I have tried the original Powerchute BE 8.00 and installed it, however still no working...

I made some interesting observations on my Windows 2003 x64 server: I could reestablish the connection just by reconfiguring the server, I don't need to unplug and replug the USB cable!

1) Go to the Device Manager
2) Open "Human Interface Devices"
3) Right mouse click on "American Power Conversion USB UPS" and choose "Disable". Acknowledge with "Yes".
4) Right mouse click on "American Power Conversion USB UPS" and choose "Enable". Acknowledge with "Yes".

After that I see eventid 1002 "communications established" from APCBEAGENT in the event log and I could access the UPS with Power Chute BE. This shows me clearly that it is a software and not hardware problem. If I go to Properties of the "American Power Conversion USB UPS" device I see that it uses microsoft drivers:

hidclass.sys -> 5.2.3790.1830
hidparse.sys -> 5.2.3790.3959
hidusb.sys -> 5.2.3790.1830
hid.dll -> 5.2.3790.3959

Any idea why disabling / enabling the device could reestablish the connection (mostly only for some minutes, sometimes for 30min or even hours)?

[TheNotoriousKMP_apc]

Hello Oliver,

I have not seen this issue, most likely in part to the fact that we do not do support for International UPS's here in the U.S.

Unfortunately, we're going to have to rely on other APC customers who're using the SUA1000RMI2U to assist.

But since you provided the information pertaining to how you fixed the problem, I have one follow-up question for you.


Have you been able to reproduce this on another machine using the same software and same USB cable?

[BillP]

Thanks for your reply.

Since I don't have another x64 Server 2003 machine or a second DL385 I could not do this....

On friday I have tried your often mentioned "Braindead" proceedure. I have heard the click after 2-3s pressing the OFF-button, however the LEDs didn't flash (???). The connection was still not stable after this as you can see on the eventlog:

Type Date Time Source Category Event User Computer
Error 20.10.2008 06:20:29 APCPBEAgent None 3000 N/A SERVER3
Information 20.10.2008 06:18:31 APCPBEAgent None 1002 N/A SERVER3
Error 19.10.2008 23:51:02 APCPBEAgent None 3000 N/A SERVER3
Information 19.10.2008 23:41:49 APCPBEAgent None 1002 N/A SERVER3
Error 19.10.2008 20:38:27 APCPBEAgent None 3000 N/A SERVER3
Information 19.10.2008 19:51:20 APCPBEAgent None 1002 N/A SERVER3
Error 19.10.2008 14:08:10 APCPBEAgent None 3000 N/A SERVER3
Information 19.10.2008 14:05:26 APCPBEAgent None 1002 N/A SERVER3
Error 19.10.2008 13:50:16 APCPBEAgent None 3000 N/A SERVER3
Information 19.10.2008 13:34:37 APCPBEAgent None 1002 N/A SERVER3
Error 19.10.2008 12:26:46 APCPBEAgent None 3000 N/A SERVER3
Information 19.10.2008 12:24:49 APCPBEAgent None 1002 N/A SERVER3
Error 19.10.2008 12:02:38 APCPBEAgent None 3000 N/A SERVER3
Information 19.10.2008 12:02:26 APCPBEAgent None 1002 N/A SERVER3
Error 19.10.2008 06:24:36 APCPBEAgent None 3000 N/A SERVER3
Information 19.10.2008 06:21:48 APCPBEAgent None 1002 N/A SERVER3
Error 18.10.2008 23:23:53 APCPBEAgent None 3000 N/A SERVER3
Information 18.10.2008 23:20:55 APCPBEAgent None 1002 N/A SERVER3
Error 18.10.2008 21:41:09 APCPBEAgent None 3000 N/A SERVER3
Information 18.10.2008 21:32:47 APCPBEAgent None 1002 N/A SERVER3
Error 18.10.2008 00:51:52 APCPBEAgent None 3000 N/A SERVER3
Information 18.10.2008 00:50:22 APCPBEAgent None 1002 N/A SERVER3
Error 17.10.2008 15:12:35 APCPBEAgent None 3000 N/A SERVER3
Information 17.10.2008 15:05:05 APCPBEAgent None 1001 N/A SERVER3
Information 17.10.2008 15:05:05 APCPBEAgent None 1002 N/A SERVER3
Information 17.10.2008 14:56:55 APCPBEAgent None 1000 N/A SERVER3

You see that the connection doesn't last long. Mostly only a few minutes, sometimes just seconds...

Another interesting observation on my system: Is it normal, that when I check the properties of the "APC Battery BackUP" device and I go to driver/driver details, then the system says "No driver files are required or have been loaded for this device". Is the driver installation corrupt?


BTW: I have tried other USB-cables with no success. It was an USB cable that I am using heavily on an external hard disk without problems...

Would a USB protocoll help? I have installed Device Monitoring Studion from HHD Software (Testversion runs for 14days). The output look currently like this (Agent says currently "No connection"):

Setup Packet
80 06 02 03 09 04 02 01 ?.......
Recipient: Device
Request Type: Standard
Direction: Device->Host
Request: 0x6 (GET_DESCRIPTOR)
Value: 0x302
Index: 0x409
Length: 0x102
000120: Get Descriptor Request (DOWN), 20.10.2008 10:16:42.181 +4.999
Descriptor Type: String
Descriptor Index: 0x2
Transfer Buffer Size: 0x102 bytes
LanguageId: 0x409

000121: Control Transfer (UP), 20.10.2008 10:16:42.181 +0.0. Status: 0xc0000004
Pipe Handle: 0x978be648

Setup Packet
80 06 02 03 09 04 02 01 ?.......
Recipient: Device
Request Type: Standard
Direction: Device->Host
Request: 0x6 (GET_DESCRIPTOR)
Value: 0x302
Index: 0x409
Length: 0x102
000122: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:42.962 +0.781. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
16 06 ..

000123: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:42.962 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000124: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.025 +0.062. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
36 02 6.

000125: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.025 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000126: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.056 +0.031. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
14 02 ..

000127: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.056 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000128: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.118 +0.062. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
1C 00 ..

000129: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.118 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000130: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.181 +0.062. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
1B 03 ..

000131: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.181 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000132: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.322 +0.140. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
15 56 38 .V8

000133: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.322 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000134: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.384 +0.062. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
22 02 ".

000135: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.384 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000136: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.478 +0.093. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
26 B4 00 &´.

000137: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.478 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000138: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.603 +0.124. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
23 FD 00 #ý.

000139: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.603 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000140: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.697 +0.093. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
25 00 00 %..

000141: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.697 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000142: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.759 +0.062. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
24 D0 00 $Ð.

000143: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.759 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000144: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.821 +0.062. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
2D E6 00 -æ.

000145: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.821 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000146: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.884 +0.062. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
17 0F ..

000147: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.884 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000148: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.946 +0.062. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
1A 78 00 .x.

000149: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.946 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000150: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:43.993 +0.046. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
08 78 00 .x.

000151: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:43.993 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000152: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:44.025 +0.031. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
0D 00 0F ...

000153: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:44.025 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000154: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:44.056 +0.031. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x3 bytes from the device
07 0C 00 ...

000155: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:44.056 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000156: Bulk or Interrupt Transfer (UP), 20.10.2008 10:16:44.087 +0.031. Status: 0x00000000
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
0C 64 .d

000157: Bulk or Interrupt Transfer (DOWN), 20.10.2008 10:16:44.087 +0.0
Pipe Handle: 0x9aaf8468 (Endpoint Address: 0x81)
Get 0x4 bytes from the device
000158: Get Descriptor Request (DOWN), 20.10.2008 10:16:47.181 +3.093
Descriptor Type: String
Descriptor Index: 0x2
Transfer Buffer Size: 0x102 bytes
LanguageId: 0x409

000159: Control Transfer (UP), 20.10.2008 10:16:47.181 +0.0. Status: 0xc0000004
Pipe Handle: 0x978be648

Message was edited by: omerk

[Anonymous user]

We have the same problem here:

We are using three workstations with each of them having their own Smart-UPS 2200. They are connected to the computer with the USB cable that came with the UPS. As an operating system we are using Windows 2000. Although I installed the latest update the UPS still is loosing the connection from time to time.

Today the connection was lost. After disconnecting and reconnecting the cable the connection was fine again.