[Nut-upsdev] Maruson power net 1500 support?

[David Mathog]

In the meantime I put some printf(stderr,"DEBUG...") statements in the 
2.2.2. megatec_usb.c and ran it like this:

/usr/local/src/nut-2.2.2/drivers/megatec_usb -a MarusonTop -DDDDDD 2>&1
| tee /tmp/megatec_2.2.2.txt

Looking at just the last Q1 exchange it showed;

DEBUG get_data_agiler length -110 expected 8
get_data_agiler: raw dump: (0 bytes) =>
DEBUG total read 0
 DEBUG raw data: 
 ok
DEBUG get_data_agiler length 8 expected 8
 ok
DEBUG get_data_agiler length 8 expected 8
 ok
DEBUG get_data_agiler length 8 expected 8
 ok
DEBUG get_data_agiler length 8 expected 8
 ok
DEBUG get_data_agiler length 8 expected 8
 ok
DEBUG get_data_agiler length 8 expected 8
DEBUG total read 48
 DEBUG raw data:  28 31 31 33 2e 38 20 31 30 30 31 30 30 30  d 33 2e 38
20 30 33 38 20 36 30 2e 30 20 35 34 2e 31 20 35 30 2e 36 20 30 30 30 30
31 30 30 30  d 33 

Q1 => FAILED [short read]
Q1 detail: (14 bytes) => 28 31 31 33 2e 38 20 31 30 30 31 30 30 30

So here is the first thing I don't understand.  The program read 48
bytes in but then for some reason only retained 14 of them.  It said
this was a short read.  However AGILER_REPORT_SIZE is 8 and
AGILER_REPORT_COUNT is 6, so 48 seems like exactly the expected number.
Perhaps the "detail" routine only shows the first 14 bytes no matter how
long the read was, but 48 was expected, 48 was read, and yet it was "short".

Translating the 48 bytes gives:

(  1  1  3  .  8 sp  1  0  0  1  0  0  0 
  CR  3  .  8 sp  0  3  8 sp  6  0  .  0
  sp  5  4  .  1 sp  5  0  .  6 sp  0  0
  0  0  1  0  0  0  cr 3

Some of those look like expected data:  113.8 is probably the voltage
and 60.0 the line frequency.  038 is likely the load factor.  I have
no idea what 1001000, 3.8, 54.1, 50.6, 00001000, and 3 are though.

Regards,

David Mathog
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech