[Nut-upsdev] [Nut-upsuser] Mustek PowerMust 848

Adrian Czerniak adrian.czerniak at becomo.com
Sun Dec 7 11:25:06 UTC 2008


On Sun, 07 Dec 2008 09:31:23 +0100, Arjen de Korte wrote
> Citeren Carlos Rodrigues <cefrodrigues at gmail.com>:
> 
> [...]
> 
> >> Starting UPS detection process...
> >> Asking for UPS information [I]...
> >> I => FAILED [short read]
> >> I detail: (1 bytes) => 49
> 
> This is not uncommon, many UPSes speaking Megatec protocol don't  
> implement this, so I'm not too worried about this reply.
> 
> >> Asking for UPS status [Q1]...
> >> 00]_data_phoenix: got so far [Q1
> >> get_data_phoenix: (8 bytes) => 51 31 0d 2e 30 0d 30 30
> >> Q1 => FAILED [short read]
> >> Q1 detail: (2 bytes) => 51 31
> 
> But this is odd. It echos the Q1 query straight back at us. So the  
> communication seems to be fine, but the UPS doesn't support this  
> command. So either
> 
> 1) The UPS is implementing a *very* old version of the Megatec  
> protocol and uses the 'D' command to query for status information
> 
> (this was obsolete back in 1996 already). Please try if changing 
> line  426 from
> 
> 	ser_send_pace(upsfd, SEND_PACE, "Q1%c", ENDCHAR);
> to
> 	ser_send_pace(upsfd, SEND_PACE, "D%c", ENDCHAR);
> 
> will get us an answer from the UPS. Most likely, we won't be able to 
>  parse the reply, but for the moment we just want it to talk to us.  
> Make sure you run it in -DDDDD debug mode.
> 
> 2) It doesn't use the Megatec protocol. In that case, you'll have to 
>  use 'usbsnoop' (search Google) while running it with the (bundled?) 
>  Windows software to see if we can figure out if this is a familiar  
> protocol or that we need something completely new.
> 
> In any case, we'll take this to the development mailinglist. Please  
> answer there.
> 

Unfortunately, suggested change in source code doen't seem to fix anything:

sudo ./megatec_usb -a mustek -DDDDD
Network UPS Tools 2.3.0-1603M - Megatec protocol driver 1.5.18 [megatec_usb]
Carlos Rodrigues (c) 2003-2008

Serial-over-USB transport layer for Megatec protocol driver [megatec_usb]
Andrey Lelikov (c) 2006, Alexander Gordeev (c) 2006-2007, Jon Gough (c) 2007

debug level is '5'
Checking device (0665/5161) (003/004)
- VendorID: 0665
- ProductID: 5161
- Manufacturer: Cypress Semiconductor
- Product: USB to Serial
- Serial Number: unknown
- Bus: 003
Trying to match device
Device matches
DTR=1, RTS=0
send_to_all: SETINFO driver.version.internal "1.5.18"
Starting UPS detection process...
Asking for UPS information [I]...
I => FAILED [short read]
I detail: (1 bytes) => 49
Asking for UPS status [Q1]...
get_data_phoenix: got so far [f]
get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30
Q1 => FAILED [short read]
Q1 detail: (4 bytes) => 66 1c 2e 30
Asking for UPS status [Q1]...
get_data_phoenix: got so far [f]
get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30
Q1 => FAILED [short read]
Q1 detail: (4 bytes) => 66 1c 2e 30
Asking for UPS status [Q1]...
get_data_phoenix: got so far [f]
get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30
Q1 => FAILED [short read]
Q1 detail: (4 bytes) => 66 1c 2e 30
Asking for UPS status [Q1]...
get_data_phoenix: got so far [f]
get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30
Q1 => FAILED [short read]
Q1 detail: (4 bytes) => 66 1c 2e 30
Asking for UPS status [Q1]...
get_data_phoenix: got so far [f]
get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30
Q1 => FAILED [short read]
Q1 detail: (4 bytes) => 66 1c 2e 30
5 out of 5 detection attempts failed (minimum failures: 2).
Megatec protocol UPS not detected.

--
Regards,
Adrian Czerniak




More information about the Nut-upsdev mailing list