Citeren Roman Mamedov <[email protected]>: > The problem is, the data returned by my UPS is for some reason > sprinkled with these "\r" characters right in the middle of useful > data. Here is a hex dump of what is being returned by get_data_phoenix: > > 28 32 31 37 2e 30 20 32 30 30 31 30 30 31 0d 37 2e 30 20 30 32 32 20 35 > 30 2e 31 20 31 33 2e 38 20 32 35 2e 30 20 30 30 30 30 31 30 30 31 0d 37 > 2e 30 20 30 32 32 20 35 30 2e 31 20 31 33 2e 38 30 2e 31 20 31 33 2e 38 > > As you can see, there is an "\r" after just the first 14 characters, > because of which ser_get_line returns only what is before it, causing a > "short read". However, the complete response from the UPS, with the > "\r" bytes ignored, looks OK: > > (216.6 20010.0 1.0 22.0 50.1 13.8 25.0 00001001
No, this doesn't look OK at all. Although it looks like Megatec/Q1 protocol, the data is damaged. The first three values should be (almost) identical, which clearly isn't the case. I suspect I know what is wrong though. Could you try the 'blazer_usb' driver from the SVN trunk? Run it with debugging enabled (-DDD, not higher!) and post the output here. [...] > The only significant remaining problem is that Output voltage is being > reported as 1.0 volt. I guess the voltage for USB protocol might be > reported as a fraction of input voltage, or maybe that's because I am > mixing an older version of NUT with the newest megatec_usb driver. No, this is because the data is damaged somehow. > Also, get_ups_info (the "I" query) fails with a "short read", but it's > not really a concern, since it does not prevent the driver from starting > and it works fine after that. This is probably due to the same problem. Best regards, Arjen -- Please keep list traffic on the list _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
