[Nut-upsdev] Krauler UP-M500VA investigation

[Peter Selinger]

Hi Alex,

thanks for your detective work! I haven't looked at your detailed log,
but from your description, it seems like the driver ignores the HID
tree and just uses the megatec-like string descriptors that you
discovered. 

With this information (and some fine-tuning), it should be possible to
write a new megatec_usb driver. It will not be a newhidups subdriver,
but a stand-alone driver, similar perhaps to bcmxcp_usb or
tripplite_usb. To decipher the protocol, of course it will be useful
to look at the serial driver megatec.c.

For info on how to write a new NUT driver, see new-drivers.txt. 

Do you feel up to this task? I and the rest of the team can help, but
I can't take the lead in writing such a driver at the moment, because
I don't have enough time.

-- Peter

Alexander I. Gordeev wrote:
> 
> Hi, All,
> 
> Today I tried UPS under Windows with Upsilon 2000 to trace usb io.
> This tool uses get_descriptor call too and it is the only call it uses
> except for quite few requests at initialization time!
> Also, the vendor of this tool is Megatec and it calls communication
> protocol "Mega(USB)". So, this protocol should be megatec in fact (as
> Carlos wrote).
> The usbsnoop log is rather big, so I attached it to the letter.
> 
> That's what it does exactly from the very beginning
> (I'll point to get_descriptor call as "get_descriptor <descr>
> <index>"):
> 
> // at startup with no delay
> get_descriptor 1 0
> get_descriptor 2 0
> get_descriptor 2 0
> some initialization, it sets up a pipe to the device, I guess
> get_descriptor 22 0 (and it returns much data!)
> something strange (for me) again
> 
> // from now delay becomes 2 seconds
> get_descriptor 3 3
> get_descriptor 3 3
> 
> // here infinite loop starts
> get_descriptor 3 13             \
> get_descriptor 3 3              |
> get_descriptor 3 12             | infinite
> get_descriptor 3 3   \          | loop
> .....                | 8 times  |
> get_descriptor 3 3   /          /
> 
> // when I pushed on "Test" button (delay is again about 2 secs):
> get_descriptor 3 3
> get_descriptor 4 3  // after this call UPS disconnects from the line
>                     // and returns back to online state in a second
> get_descriptor 3 3
> get_descriptor 4 3
> get_descriptor 3 3
> get_descriptor 4 3
> get_descriptor 3 3
> 
> 
> This initialization made in startup is important, because when I tried
> to reproduce this sequence with Peter's program, the call
> get_descriptor 22 0 failed because of timeout. But all another things
> are nearly the same. This could be key to understanding timeout
> messages from newhidups.
> 
> -- 
>  Alexander                          mailto:lasaine at lvk.cs.msu.su