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 [EMAIL PROTECTED] Manager, Sequence Analysis Facility, Biology Division, Caltech _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
