[Nut-upsdev] USB support for Sweex 1000 VA UPS (was: Help with

[Peter Selinger]

Nice work! 

That value that constantly fluctuates could be a voltage. Since you're
in Europe, perhaps it's a straight decimal conversion? FC = 252, F5 =
245 etc? Seems a bit on the high side, as your nominal voltage is
supposed to be 230V. It could be some other measurement value, or
voltage on some other scale, or only a few of the bits are
significant... In any case, it probably doesn't matter.

What you should try, however, is what happens when the battery gets
(1) low, and (2) empty. Aside from the "on power" flag, these are very
important flags that most UPS's will signal. The idea is that you
start shutting down your computer when the battery gets low. 

Another important thing is to be able to shut off the UPS via a
command. Namely, after your computer shuts down in the case of a power
failure, you want to be able to turn the UPS power off. The idea is
that it should stay off until the line power returns, at which point
your computer reboots (if set to do so in the BIOS). Otherwise, you
might end up in limbo if the power comes back before the battery runs
out, but after your computer has shut down. If the Richcomm software
can do a forced shutdown, you might be able to see what command it
sends. (Perhaps not needless to say: don't plug your computer into the
UPS during these tests. Plug it into the wall). 

Your protocol could be a USB implementation of some known serial
protocol (send a few bytes, receive a few bytes). Perhaps someone on
this list will recognize it as being the protocol from one of NUT's
serial drivers.

Where to go from here? Look at any of the USB, but non-HID drivers in
drivers/*usb*.c. Most of them are serial-over-USB simulators of some
kind. The trouble is that each vendor uses a slightly different
mechanism (=hack) for sending/receiving serial data over a USB
connection. You might need to read the USB specification, which is
long and complex (but freely available on the web from
http://www.usb.org/developers/docs/), to really understand what is
going on. On the other hand, many of us have been hacking USB drivers
without *really* understanding what is going on. 

In short, chapters 9.3 and 9.4 might be useful in deciphering by what
mechanism the software is sending a "class-specific request". The
response seems to be an interrupt transfer.

NUT uses libusb (http://libusb.sourceforge.net/doc/) for all USB
functions. Unfortunately, the interface is badly documented and
underspecified, and impossible to read without the USB specification. 

Good luck! -- Peter

Peter van Valderen wrote:
> 
> Hello!
> 
> > By the time we've figured that out, they have probably switched to
> > another supplier and yet another protocol. I doubt it's worth the effort.
> 
> Well I guess it is to me, I started playing around with an USB
> snooper, I think I found out at least one thing, namely if the power
> is connected to the UPS or not, which I suppose is the most important
> thing...
> 
> When I connect the UPS to the USB and launch the 'PowerManagerLite'
> tool by richcomm, the software that came with it, starts polling
> approximately once a second with a package such as this:
> 
> 000036: Class-Specific Request (DOWN), 21.05.2007 22:38:27.203 +1.250
> Destination: Interface, Index 0
> Reserved Bits: 34
> Request: 0x9
> Value: 0x200
> Send 0x4 bytes to the device
> 
>  01 00 00 30                                       ...0
> 
> This package is always the same, so pretty obviously a status request.
> 
> After this a reply comes back such as:
> 
> 000038: Bulk or Interrupt Transfer (UP), 21.05.2007 22:38:27.203 +0.0.
> Status: 0x00000000
> Pipe Handle: 0x890c8a34 (Endpoint Address: 0x81)
> Get 0x6 bytes from the device
> 
>  01 04 02 FE FC FF                                 ...=FE=FC=FF
> or (next reply)
>  01 04 02 FE F5 FF                                 ...=FE=F5=FF
> or (next reply)
>  01 04 02 FE FD FF                                 ...=FE=FD=FF
> 
> In any case, it looks to be the case that all but 1 bit (the 5th) do
> not change. I haven't really worked out what the 5th bit is for.
> 
> Now for the interesting part, when I unplug the power from the UPS,
> packets now look like this:
> 
>  01 04 02 FA F4 FF                                 ...=FA=F4=FF
> or
>  01 04 02 FA F5 FF                                 ...=FA=F5=FF
> 
> then when I plug it back in
> 
>  01 04 02 FE F4 FF                                 ...=FE=F4=FF
> 
> So I suppose it's pretty obvious that the 4th byte represents the
> power status of the UPS.
> 
> Just thought I'd mention my findings. I'm trying to figure out where
> to go from here, any pointers would be appreciated.
> 
> Thanks,
> Peter
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>