[Nut-upsdev] Re: [Nut-upsuser] Ablerex 625L USB version

Peter Selinger selinger at mathstat.dal.ca
Wed Jan 31 07:37:22 CET 2007


I think at this time it is best if you experiment yourself. I don't
have any megatec-over-USB device, and I only have the vaguest idea of
this protocol. Essentially, all I know is that it gets the data in a
similar way to the get_descriptor program that you hacked. Which
individual requests may succeed or fail, or why, is beyond my
knowledge. I am hoping that some of the people who are hacking this
protocol (you, Andrey, Alex) will turn into developers and that one
day we will have a fairly robust driver that is able to handle this
class of devices (and compensate for their various idiosyncracies). 

-- Peter

Jon Gough wrote:
> 
> Peter,
>     I have tried the Serial-over-USB thing and got the following
> 
> [root at neptune etc]# 
> /hd2/Downloads/UPS/Upsilon/NUT/trunk/drivers/megatec_usb -DDDDDD -a 
> eclipse -u nut
> Network UPS Tools - Megatec protocol driver 1.5[usb] (2.1.0)
> Carlos Rodrigues (c) 2003-2007
> 
> debug level is '6'
> comm_usb_open
> Checking device (0000/0000) (002/001)
> - VendorID: 0000
> - ProductID: 0000
> - Manufacturer: unknown
> - Product: unknown
> - Serial Number: unknown
> - Bus: 002
> Trying to match device
> comm_usb_match
> Device does not match - skipping
> Checking device (FFFF/0000) (001/002)
> - VendorID: ffff
> - ProductID: 0000
> - Manufacturer: UIS Ablerex
> - Product: Ablerex USB Interface 049e
> - Serial Number: unknown
> - Bus: 001
> Trying to match device
> comm_usb_match
> Device matches
> HID descriptor, method 1: (9 bytes) => 09 21 00 01 00 01 22 78 02
> i=0, extra[i]=09, extra[i+1]=21
> HID descriptor, method 2: (9 bytes) => 09 21 00 01 00 01 22 78 02
> HID descriptor retrieved (Reportlen = 632)
> Report descriptor retrieved (Reportlen = 632)
> Found HID device
> comm_usb_recv starting
> in get_data_ablerex
> in libusb_get_interrupt
>   none (-2)
> get_data_ablerex: len: -2, error: 2, No such file or directory: buf:
> Leaving get_data_ablerex: len: 0
> len: 0
> doing for loop:
> Starting UPS detection process...
> Attempting to detect the UPS...
> Sending "Q1" command...
> comm_usb_send starting
> calling va_start
> doing vsnprintf
> calling va_end: len: 3, Q1
> doing if test
> about to return
> in set_data_ablerex
> Leaving set_data_ablerex; strlen(str): 3,        Q1
> getting receive stuff
> comm_usb_recv starting
> in get_data_ablerex
> in libusb_get_interrupt
>   none (-2)
> get_data_ablerex: len: -2, error: 2, No such file or directory: buf:
> 
> 
> It would seem to be the
> 
> ret = usb_interrupt_read(udev, 0x81, (char *)buf, bufsize, timeout);
> 
> line that is getting the error 2. Is there any more information on 
> what should be in there? Or is this the time I have to start trying 
> different bits, like putting the usb_get_string_simple in instead?
> 
> Jon
> 
> 
> At 16:52 31/01/2007, Peter Selinger wrote:
> >Jon Gough wrote:
> > >
> > > Peter,
> > >     A bit more info. I have modified your get_descriptor.c program to
> > > give a few more details. I have run it a few times and got the
> > > following information.
> > >
> >...
> > >
> > > [root at neptune trunk]# ./drivers/get_descriptor 001 002 1 0 0 128 0 3
> > > usb_get_string_simple(udev, 3, buf, 2048)
> > >
> > >   28 32 34 38 2e 30 20 31 34 30 2e 30 20 32 34 38 2e 30 20 30 31 32 20 35
> > >   30 2e 30 20 32 37 2e 30 20 32 35 2e 30 20 30 30 30 30 31 30 30 30 0d
> > >
> > >   (248.0 140.0 248.0 012 50.0 27.0 25.0 00001000.
> >
> >This is the megatec protocol. So your device seems indeed to be an
> >instance of the megatec-over-USB protocol that has been discussed on
> >the nut-upsuser list in December and January. I believe I mentioned
> >this last week; here is the excerpt from the relevant email. We are
> >going in circles, it seems.
> >
> >On Fri, 26 Jan 2007, Peter Selinger wrote:
> > > Jon,
> > >
> > > there were some threads in December on the nut-upsdev list, with
> > > subjects such as "megatec over USB". Andrey Lelikov had written a
> > > patch for a "SVEN Pro+" device, and Alexander I. Gordeev is still
> > > continuing to work on it to support his "Krauler" device. But as far
> > > as I know, this has not yet been tested much, and Alexander is still
> > > working on it (see his most recent post on January 23).
> > >
> > > Last time I took inventory, here is the list of devices that *may* use
> > > a similar protocol (dubbed "megatec-over-USB"):
> > >
> > > * Krauler UP-M500VA (see Alexander I. Gordeev's thread on nut-upsdev,
> > >   November 2006)
> > > * Ablerex 625L (see Lau Kim Ping's thread on nut-upsuser, October
> > >   2006)
> > > * Atlantis-Land S1501 (made by Ablerex) (see ngpost1's threads on
> > >   nut-upsuser and nut-upsdev, December 2005)
> > > * Belkin F6H500ukUNV (made by MEC?) (see the thread by meherenow,
> > >   spamwhole, and Robert Kent on nut-upsdev, September 2006)
> > > * SVEN Pro+ USB (see Andrey Lelikov's posts on nut-upsdev, starting
> > >   December 2006)
> > >
> > > I don't have any further information at this point, but you could get
> > > in touch with Alexander to see if he has a tryable version of Andrey's
> > > patch, or you could try Andrey's patch (which was posted on the
> > > mailing list) directly.
> > >
> > > -- Peter
> >
> >So my recommendation still stands: try Andrey's patch, and/or try to
> >get it from Alexander.
> >
> >-- Peter
> 
> 
> 
> 
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 000709-0, 30/01/2007
> Tested on: 31/01/2007 5:26:33 PM
> avast! is copyright (c) 2000-2007 ALWIL Software.
> http://www.avast.com



More information about the Nut-upsdev mailing list